Concept: Deaccelerated fast stop

[AnHardt]

what are your thoughts on saving the buffered commands so the detection is immediate? Is it possible to inject a command into the buffer on the fly? Is this a bigger task to tackle?

The detection is already close to imediat - it's the reaction on the detection what is delayed. It's impossible to inject a movement command 'on the fly'. It needs a good amount of preparation to do so. It's not impossible to improve the reaction time, but it's a job for the 'big boys'.

Currently we have two ways to stop a print.

• Stop planing new planner buffer lines and wait until the buffer is empty. This is what is currently used with filament runout and can last for a while.
• Stop planing new planer buffer lines, stop stepping immediately and delete the planer buffer content. This is used as a emergency stop and with power failure detection. This is not recoverable without homing because the sudden stop may lose steps because it is not deaccelerated. The content of the buffer is lost forever. (In the example above the layer change would be lost!)

What Marlin is missing is a coordinated deaccelerated fast stop. A concept for that could be:

• When detecting 'filament runout' or 'power failure' or any other situation we want to stop fast (endstop ?) - set a flag as fast as possible (maybe in a interrupt).

• If the flag is set in the stepper IRQ go into deacceleration mode. In the planner buffer we already have all needed information. We have the maximum allowed deacceleration for every line and we have a point from where in the line we have to deaccelerate. If the complete line as accelerating or at target speed this point is the end of that line. However for the complete buffer content its warranted the final speed is zero. If we ignore the precalculated point from where on to deaccelerate but do it when the 'flag' is set we can reach the stop much faster (at least in the cases when the buffer is full of long lasting lines). We can stop stepping when the speed is at or below jerk-speed, or at zero. Meanwhile the planner stopped accepting new moves, finalised planing the last accepted move and optimized the buffer for highest possible speed (as always). So planner buffer state is consistent. The stepper ISR did not rewrite the planner buffer, just ignored the instructions from where to deaccelerate. We can now save the machine state outside the planer/stepper.

• Now, when the planer does not plan anymore, the speed is zero and no further steps are done, we can save the stepperISR state (position and where in the last line we stopped) and ether save the entire planer buffer, reset it and use it for injecting new moves (for now to bring the nozzle away from the part), or if we just want to inject some lines we can simply use an other (maybe much shorter) line-buffer. Now reset the flag and resume stepping.

• Now we can do the filament change or whatever

• When we want to resume at first we have to restore the machine physical state (position, nozzles priming state, temperatures, etc) than the machines outer logical state than the blanner buffer state. For that we stop the stepper IRQ again and copy in the saved contend (or switch to the original buffer). Now we have to replan the buffer content**. Parts of the first move are already done and current speed is zero. Most of the work is already done, we just have to shift the points for end of acceleration and begin of deaccelerations, what usually the 'optimizer' does. Now we can enable stepping an accepting new moves from the original queue. Done.

Remarks: Deaccelerated coordinated fast break could have less 'break-way' than just stopping to step. When steps are skipped the movement is accelerated again on the 'backside' of the 'dents'. Moving 'the field' 'right' means keeping the 'magnet' on the frontside of the 'dent'.

In systems sub-segmenting moves (deltas) we need to save and recover the sub-move number we stopped.

[AnHardt]

You could try to minimize the 'gap' by minimizing the segment length. But that's a contradiction to the god old rule: "If you want 'smooth' printing - use big segments."

[Gornerrrrr]

May I ask if the quick pause/resume feature has been implemented? I checked the feature branches and found the FREEZE_FEATUREand REALTIME_REPORTING_COMMANDSfunctionalities, but they seem to only immediately stop pulse sending and cannot achieve stopping with deceleration and resuming with acceleration.

[AnHardt]

As far as i know neither this concept nor something similar is implemented. The stops are still immediate.

[Gornerrrrr]

As far as i know neither this concept nor something similar is implemented. The stops are still immediate.

Thank you for your response. This is not an easy feature to implement in the Marlin.