New hybrid (old and new) moveplan ?

dc42

Thank you for your interesting analysis.

A question: why do you think that ringing is caused only by braking, and not also by acceleration? I would expect both to cause it equally, although where the ringing is caused by a long travel move then the ringing caused by acceleration will have died down somewhat by the start of the next printing move, so the ringing caused by braking will be more significant.

One thing the firmware has to contend with is that when printing small circles, as well as moves with the standard trapezoidal profile there are acceleration-only and deceration-only moves. So I don't think it's possible to keep the existing trapezoidal planner and implement S-curve acceleration just when generating the steps. For example, if a move starts from standstill (zero acceleration) and ends with finite acceleration because the target speed has not yet been reached, then the move time will need to be lengthened to allow for S-curve acceleration.

My current thinking is to have a high level and a low level planner. The high level one will work much as now but work in Cartesian space only, split moves to make each one constant acceleration or constant speed, and not compute the exact move time. So the moves will be RISC-like. The low level planner will operate after moves have been frozen. It will modify the constant acceleration moves where necessary to eliminate discontinuous acceleration, calculate the actual move time, and perform the mapping from Cartesian space to motor movement.

vp

Ringing:
I assume, that as long as we don´t notice ringing, we don´t care about it.

With the old move plan when increasing speed at the start of the ramp, when the acceleration is increased stepwise, this will generate a bump and oscillations - but these oscillations are in the "line of the path" (at least for cartesian printers). So all they do is to vary the amount of extrusion per length, which is compared to the overall extrusion error nothing.

If e.g. the x&y axes would become dynamically "out of sync" it could create some fancy patterns in the some 1/16 step scale dimension. But so far i never saw ringing/ghosting at the start of a move when speed is ramping up. If i see fancy patterns in the web, they are everywhere and not limited to start or end of move. In general these patterns are more "missing dynamically steps" (or too low real resolution) related.

Let’s say when braking the ringing artifacts will always be much more visible as compared to accelerating. When braking the oscillation direction is e.g. 90 °to the moving direction (at e.g. 90° corner). So any overshoot will deviate out of the target line path - this is what we see. I did simple tests with cube prints and split the lines into 2 segments, start and end. Then i limited the accelerations for these segments to different values. As expected the (visible) ringing is only influenced by the braking acceleration.

Moves without constant speed phase:
I am sorry but i didn´t get the point. It makes CPU-wise effort to get zero acceleration at the end of the move because it adds one constraint. If you don´t want to get zero da/dt at the end or start of the move it just makes it more easy to compute. It is no problem at all to adjust above formulas to get da/dt <> 0 at start/end.

Or do you mean the total time for the ramp move will need to be increased ? As shown above, it is no problem to choose the constants to match the total ramp time exactly (that is a built in feature). It doesn´t matter if there is no constant speed phase.

High and low level planner:
To split the problem is what is the way to go (at least in my opinion). But if you plan in x/y(/z) and afterwards map it to deltas, scaras etc., how do you limit the speeds and accelerations without adding a second iterative loop ? Doesn't this lead to 2 iterative loops in series (which won´t improve stability/robustness and speed) ?

Questions:

Will the new move plan allow jerk ? Will it reduce the disadvantages of jerk ?
Will the new move plan reduce acceleration for higher speeds (to be able to make travel moves with > 500 mm/s without bottlenecking the shorter/slower moves) ?
Will the new move plan allow to adjust the different tuning factors ?

I don’t care how it is done, as long as it gets done;)
If we don´t use this chance to improve the move-planner really (and not only to implement features we don´t need like 6th order zero jerk) we wont get a chance again for a very long time.

vp

I did the same for a move without constant speed phase, see below. I still don´t see the problem. The ramp up as well as the ramp down takes exactly the same time as the old moveplan - why should it get longer ?

0_1530591925916_mp_new_pf_0 0_0 0_2 2_up_down.png

The same for the end/start condition, that a_end of the up ramp and a_start of the down ramp equals exactly a_old (nobody would do that if s-shape moves are possible, but to show the method works without problems).

0_1530592369949_mp_new_pf_0 0_0 0_2 2_up_down_sharp.png

What´s the problem ?

[EDIT: a [mm/s^2] in the figures is the absolute value of a]

Catalin_RO

@dc42 Wouldn't it be better to have 3 move commands (G0/G1, G2 and G3) sent to the low level planner instead of just one? There could be a default implementation for G2 and G3 splitting them in small lines and for some low level planners there might be better alternatives (like specific arcs in a SCARA).

vp

... the question is where do the G2 & G3 commands come from ? Before this is not solved and "everything" in fdm is based on stls, it doesn´t make sense (for me) to base something on G2 & G3 commands. There are good reasons why (fdm) slicers don´t provide G2 & G3 moves and that won´t change too soon. Or did i miss something ?

wilriker

@vp I already talked about it at https://forum.duet3d.com/topic/4802/6th-order-jerk-controlled-motion-planning/110 that after a lot of swinging back and forth on this topic I really find that G2/3 commands do make sense. Even (or especially?!) in what you are describing here because if the slicer hands over the control over how an(y) arc is actually performed by the printer to the firmware there will be less problems to worry about when implementing new or adjusted moveplans because the firmware will have total control over the motion.

As of right now there is still the need to consider a possibly sub-optimal GCode created by the slicer that could prevent fluid motion. If the slicer just says "do this arc starting here with that radius around there and extrude this many material - I don't care how you do it, just make it good" that would help a lot IMHO.

dc42

In fact there is a way to execute arc moves natively on a Cartesian or CoreXY printer with reasonable accuracy. Bresenham's algorithm (see https://en.m.wikipedia.org/wiki/Midpoint_circle_algorithm) can be used to calculate the order in which microsteps should be taken. For each microstep, the arctangent of the position can be computed to see how far around the arc we are, and from that the step pulse time can be calculated. But the arctangent would be slow to calculate. Maybe there is some successive approximation technique that can be used to speed it up, given that we know the arctangent of the previous position.

But this doesn't help if the printer is a delta or SCARA.

T3P3Tony

@vp said in New hybrid (old and new) moveplan ?:

... the question is where do the G2 & G3 commands come from ? Before this is not solved and "everything" in fdm is based on stls, it doesn´t make sense (for me) to base something on G2 & G3 commands. There are good reasons why (fdm) slicers don´t provide G2 & G3 moves and that won´t change too soon. Or did i miss something ?

This should also take into account other forms of CNC which am lead to believe use G2/G3 more frequently .

wilriker

@vp said in New hybrid (old and new) moveplan ?:

There are good reasons why (fdm) slicers don´t provide G2 & G3 moves and that won´t change too soon.

Oh, I forgot earlier: This is currently in development at least for (original) Slic3r: https://github.com/slic3r/Slic3r/issues/23#issuecomment-385288531

And when Slic3r has it public it is just a question of time until other slicers follow.

alranel created this issue in slic3r/Slic3r

open Detect arcs and generate G2/G3 #23

vp

G2/G3 is only a small issue, i don´t want t spend too much time with it and most is already said.

@T3P3Tony that is why i used fdm in brackets. CNC doesn´t use stls (that much). E.g. when milling a hole and using line segments the whole would become too small... but this can also be solved by using many line segments. Especially in the DIY environment and the DUET won´t be used for professional CNC milling.

@wilriker thanks, what i miss in the discussion is the fact that G2/G3 can only be used for arc moves - that means perfect circles. Unfortunately there are not many perfect circles in a 3D print and the amount will drop in future more and more because nowadays CAD software is not limited to circles. You won´t find many real circles in many models because nowadays CAD software blend the curvature of different faces into each other.

If a model contains a part of a sphere, this will always be sliced as a circle. But any other "circle" based object like cylinders and cones will only be sliced to circles if the orientation is perfect. That means the cross section base circle of a cylinder or cone has to line up perfectly with the x/y plane. If one rotates a standing cylinder by 1 degree, there are no circles in the x/y plane anymore. So in total, even if the final model was built up using some "circle" based features, it doesn´t mean at all, that after slicing there is only one single circle left. So why spend so much effort for something which effects maybe < 1-5% of the total printed filament length ? I think that the development resources can be used more efficiently - that doesn´t mean G2&G3 has no potential.

Slic3r has been working on this for years. S3D had it in the very beginning and it was removed. So there is nothing new about it, the problems have not changed. A circle has to come from the model and not be interpolated afterwards, it will just create other artifacts and disk space is no real limitation. A stl doesn´t contain circles, that is why CNC doesn´t use stls (if it has to be accurate). If a slicer has to process the more intelligent file types (including curvature) everything is shifted to a complete different level.... maybe e.g. autodesk starts with it some when. People only think in one layer, but all layers together have to build up a 3D object. If the model is a mesh, that is easy to process and slice, but if the model is a 3D curvature this becomes a non linear optimization in at least 3 dimensions....

dc42

So here are my curre t thoughts about new movement code.

The high level planner will work much as now with the following changes:

Mapping to motor endpoints will not be done.
Instead of using instantaneous velocity change aka jerk to decide whether one move can follow another without deceleration/acceleration, it will use a speed change calculated from configured junction deviation, acceleration and true jerk.
Moves that are segments of G2/G3 moves will include the location of the centre or equivalent information.

When moves are frozen in preparation for being executed they will be split into RISC moves (rmoves). Each rmove will be cubic, either a simple cubic polynomial in time or possibly a Bezier curve or a B-spline. A trapezoidal move would be split into 7 rmoves where each rmove has constant true jerk. Where there is a discontinuity between the end of one move and the start of another, for example when straight line segments approximate a circular arc, a single joining rmove will be inserted between them. The location of the join between them will deviate from the original position by no more than the configured junction deviation. When the original move was a segment of a G2 or G3 move, the centre information will be used to approximate the arc by a cubic or perhaps quadratic move, so on that case there will be no discontinuity. This will produce more accurate G2/G3 moves and/or allow longer segments to be used.

Calculating step times for cubic moves involves solving cubic equations. This is time consuming because solving a cubic typically involves taking the square root of a complex number, which involves trig functions. To avoid this I considered switching to constant step tick frequency as most other firmwares do, but that has high overheads especially when many motors are moving. So I propose to use a binary search to solve the cubic. It will take up to about 12 iterations in the worst case to get a solution accurate to within 10us. But the calculations done for the first step will mostly relate to times in the future, so they can be re-used in subsequent steps, and so on. Alternatively some sort of Newton-Raphson iteration can be done, using the time of the previous step as the initial guess. Many rmoves will have no cubic term and those can be solved more simply.

Pressure advance becomes easier, because the derivative of a cubic move with no discontinuities in jerk between moves is a quadratic move, which when added to the original cubic move is still a cubic move. I will implement a filter so that pressure advance ignores short term changes in extrusion rate caused by slicer rounding.

The main disadvantages I can for this scheme are that the rmoves need potentially a lot of storage because there will be more of them, and the time taken to solve the cubic equations may be excessive. OTOH the high level moves will need less storage than before.

JoergS5

@vp You wrote about a constant speed being the optimal solution, esp. against ringing. Instead of speed corrections in the firmware, another solution came to my mind: what if you start extrusion when you reached your constant speed and stop extrusion before you brake and produce ringing? If you find a technical solution for a correct extrusion start and stop and accelerate/brake without extrusion some of your described problems are solved. You accelerate and brake outside the region you want to print.

You can accelerate at maximum speed then, maybe s-curve approximated to lower vibrations of the printer. The overall print duration could be similar.

JoergS5

My opinion in respect to G2/G3: sometimes you wish you can print a good circle, for objects you need for gears, good holes or other mechanical parts. I agree that it's only 1 % or less of all use cases, but in those cases I wish I have it.

vp

@dc42 thanks for the sneak preview. Wow, that sounds like a lot of work and the need for a lot of ram and CPU ressources. Hope that works out stable and robust. Will this also work for UVWXYZ ?

Junction deviation is the best "jerk" i know

If after the high level move planner the xyz moves are frozen, but not the stepper moves, how is it possible to limit speeds and accelerations of the steppers at non xyz printers (deltas, scaras etc.) ? In my opinion it is a must have to limit this to steppers and not to xyz moves. Otherwise on e.g. deltas this would bottleneck everything, because the worst case accelerations/speeds would have to be chosen as limit in the high level planner, by that not utilizing by a far amount the real possibilities. Limiting acc and speed to xyz moves just cares about the limitations of the "load" side (print head), but not about the possibilities of the "drive" side.

Do you have any plans to adjust the maximum allowed acceleration according to speed ?

In my opinion, using the old moveplan and spreading the moves over time, it could do the same and more, but with much lower efforts and need for ressources - which should be in general much more stable. If you allow a junction deviation, it "solves" the old jerk problem.

Do you have any comments why spreading moves over time won´t work ?

@JoergS5, i am sorry for confusing you, but i do not mean that a constant speed will be good for ringing. The extrusion would be as good as possible, if the extrusion rate (== speed) would never change. The hot end is like a low pass filter (spring damper system). It cannot follow quick changes. If the extruder stepper would produce e.g. a reasonable fast PWM signal, the nozzle would filter it and extrude a constant extrusion rate. Therefore any slow change in speed leads to a deviation between target and setpoint extrusion rate. Using high acceleration and jerk values gives in average a more constant speed profile and by that a more constant==better extrusion. This is why jerk was invented.

Pressure advance takes care of the spring part and without filament slippage/missing steps and so on it indeed would help a lot. If the acceleration doesn´t jump anymore pressure advance will get much more valuable. So extrusion will get better with the new moveplan.

I print a lot and for sure i did print also circles, but all you need to do is to save the stl with a high resolution.... you won´t be able to see a difference to a circle. If you use parts with changing curvature (which is normal using SolidWorks, Fusion, OnShape etc.) you need anyhow high resolution, G2/G3 won´t help you there...

JoergS5

@vp Thank you for clarifying your thoughts, it helps me understanding your physical model.

But one point is still unclear: you say the hot end is a low pass filter and cannot react fast enought to changes. But in 3d printing you know all movements and extruding in advance, because you plan it, so you can change extruding in advance if you want, there is no unexpected change.
ok reread your comment, understood

But I agree that the hotend is a bottleneck in respect of flexibility, so innovative ideas would be nice like variable nozzle size (like an iris in a camera), preheated filament etc to speed up and have flexibility in line width etc.

RCarlyle

@vp I am with you for the most part, but have to point out some errors:

1) "if the power is constant, the max possible acceleration has to drop with 1/v."

Stepper power is not constant. Back-emf makes current and thus torque drop much faster at high speeds than the typical "constant current region, constant voltage region" simplified motor model would suggest. When the magnitude of back-emf approaches supply voltage, typical open-loop stepper drivers can no longer reliably control coil current, you run into various phase-shift feedback instabilities, and practically-usable torque drops to zero. For a reasonable rule of thumb, typical NEMA 17 steppers have about 0.02 VAC-RMS back-emf per motor RPM, so when PSU_V / RPM >= 0.02, the stepper is maxed out.

More practically, if you actually run the numbers on nominal acceleration force demands versus motor torque capacity, most 3D printers have 10-50x torque safety factors. (Jerk takes a lot more torque than acceleration but that's unpleasant to calculate.)

Then there is mid-band resonance to worry about. This occurs right around or shortly past the peak of the motor power curve. For reliable operation, steppers should only be operated in or near the constant-current range for the motor. This is how the vast majority of 3d printers are actually built, although largely by accident. (Deltas at high arm extension angles are the main exception, but that arm angle provides a mechanical advantage that largely self-corrects the loss of torque.)

So there's minimal value in dropping acceleration magnitude at higher speeds -- you already have huge safety factors to allow for quite a bit of loss of torque, and in general, you shouldn't be running steppers at high enough speeds for reduced aggressiveness to be necessary, because they risk unstable electromechanical resonance regardless of torque capacity.

2) Ringing only occurs when braking (at the end of a move) and not when the speed increases!
Acceleration ringing DOES occur, but you don't see it because it happens along the path rather than across the path.

3) Therefore, it would be optimal to reduce the current at the beginning of the jerk, wait for a e.g. the time that < 1/2 step takes and increase it afterwards for a small time (e.g. 0.1-0.2s) to its maximum (the real current maximum until is saturates, will be much higher than the normally used value). By that, we would "soften" the jerk as much as possible and reduce the overshoot/ringing.

This will decrease torque safety factor during the most violent motions the printer executes, thereby risking lost steps, and it will INCREASE ringing. Ringing is the sum of overshoot due to drivetrain compliance and rotor overshoot due to the stepper's torque/error relationship. Dropping current at corners will increase rotor overshoot. You don't get less oscillation by making the system more elastic.

RCarlyle

Meant to write PSU_V / RPM <= 0.02, sorry.

vp

Hi RCarlyle,

thanks for your comments, as with all longer threads it gets difficult to catch up.

ad 1) I have described the problem, as short as possible writing above:
The steppers can only provide a certain power, which in the end decreases with speed. Because of power = force * velocity = mass * acceleration * velocity --> if the power is constant, the max possible acceleration has to drop with 1/v. This gets more and more important when moving at higher speeds (e.g. > 150 mm/s), because there the stepper power falls off significantly - but we would need more.

This is relevant for quick printers when printing and especially for travel moves. The problem as with nearby all new improvements is, that people have problems to stop thinking the old way. We should not care how things are done now, if we can do it better in future.

You claim:
More practically, if you actually run the numbers on nominal acceleration force demands versus motor torque capacity, most 3D printers have 10-50x torque safety factors

What is your base/reference torque ? The given numbers are just not correct, for a somehow efficient printer, they are far too high and i assume you just judging by "how much torque is needed in theory to accelerate the inertias compared to not losing a 1/16th micro step". If one compares the needed torque at 1/16 micro stepping to accelerate with 0.1g at 100 % stepper current (nobody uses), it might look that way - but why should we bottleneck us artificially ? For sure, one can buy a Ferrari and limit the 500 kW engine to 50 kW - but why should we ? And would we buy a DUET ? For sure you could build a printer only using 1% of its possible torque - but we should make it as good and not as bad as possible.
Yet, the only way to avoid ringing with "old school jerk" (without using low jerk values) is adding damping by friction. I use e.g. pre tensioned igus tribo tapes and if you measure the force needed to slide them and not losing 1/16th micro step, you will notice that there is no 10-50x factor at all. In the end increasing damping (and jerking the old way) gives more or less "junction deviation" results in terms of print quality.
Also, we don´t talk only about fdm, tell a CNC guy that he has 10-50x more torque as he needs at higher speeds....
There are not only printing moves. 1/16th micro doesn´t matter at all when traveling. Deltas may need to z-hop, but especially xy/z printers can utilize their full potential. The only way i know to avoid stringing with TPU/TPE etc. are damn fast travel moves. If you accelerate with 10g up to 400-500 mm/s, there is not much stringing left. But it would still decrease if i could use 20g and 1000 mm/s. Also, decreasing travel time can dramatically reduce printing time - depending on the model. These values are for my printer, but you can adjust them to any other printer.
You talk about safety factors - i want to increase them when it is needed (at higher speeds) and not to choose them completely inefficient and still not having enough safety when we would need it.
Don´t forget the new move plan. When the negative side of jerk is reduced, people will utilize this potential and use "the new jerk tuning parameter (junction deviation)" to increase speeds and accelerations. Not to forget, that the new move plan - if it should not slow down printing speed - needs to use higher acceleration values. By that everybody will dig dipper into the area where torque drops with speed although we would need more torque.
People want G2/G3 - although as shown above - G2/G3 influences a very small percentage of the total printed filament length. If G2/G3 is included but not acceleration = f(speed), than this is not efficient at all.

I did design my printer from the very beginning to be able to print at max. possible acceleration to get constant extrusion. My fine printing acceleration is 1g and for draft prints i use up to 5g. Travel moves are done with 10-20g. Because of travel moves i have to do gcode processing and split large moves into more segments with different allowed max speeds, or i have to limit the max. speed to avoid coming into the "torque drop zone".

The problem nowadays is not to build a stiff printer, the problem is the hotend/extrusion part. Why should we artificially bottleneck us ?

ad 2) Ringing only occurs when braking (at the end of a move) and not when the speed increases!
I have written above:
I assume, that as long as we don´t notice ringing, we don´t care about it.

With the old move plan when increasing speed at the start of the ramp, when the acceleration is increased stepwise, this will generate a bump and oscillations - but these oscillations are in the "line of the path" (at least for cartesian printers). So all they do is to vary the amount of extrusion per length, which is compared to the overall extrusion error nothing.

ad 3) With junction deviation coming there is no need to talk about that. But i disagree, in short terms, if what you say would be correct, all adaptive car suspension systems would not work;) In general the cheaper ones of these systems work only by adjusting the damping factor and not the spring stiffness, but it doesn´t matter how you reduce/increase the force at the right point in time as long as you adjust it properly.

The point is to start with a lower spring stiffness (beginning jerk) and end with a higher spring stiffness (when oscillation would start) compared to normal. If you think in a step response way, the low stiffness at the beginning would lead to a later and slower crossing of set point and actual value. After crossing the set point value the overshoot would start and than (or just before) the spring stiffness is increased. This would lead to a bigger "junction deviation". Without reducing the stiffness at the beginning, the speed - when the overshoot occurs - would we much higher and by that the kinetic energy the system has to absorb also --> more ringing.
Low stiffness at start (--> low speed when overshooting) and high stiffness at the end (nail it down) would definitely reduce the negative side of jerk. As you and i have written, the torque stiffness (stepper) is also only one part of the game. But the stiffer the printer, the more important it gets.

The potential of the above is small and it is obsolete with the new move plan including junction deviation.