Firmware issue: forced stop between print and non-printing moves

DigitalVision

An issue I found is that RRF (2.02rc3) doesn't allow the printhead to move continuously across extrusion and non-extrusion moves. I noticed it when experimenting with manual pressure advance – but I believe this causes slicer features such as "coasting", "wiping" and "wipe during retract" to not behave optimally. Here's an example of gcode that causes problems:

G1 X105.000 Y100.000 E0.4963 F2250
G1 X105.078 Y100.000 E0.1039 F2250 ; advance
G1 X145.000 Y100.000 E2.6556 F2250
G1 X145.078 Y100.000 E-0.1039 F2250 ; retract
G1 X185.000 Y100.000 E1.3278 F2250
G1 X185.078 Y100.000 E0.1039 F2250 ; advance
G1 X225.000 Y100.000 E2.6556 F2250

Here, the printhead is supposed to be moving at a continuous speed (37.5 mm/s) along the x axis, while switching between two different extrusion widths – but when printing the print head decelerates down to zero at the retract move – causing a huge blob in the print.

Modifying the firmware like this

+++ b/src/Movement/DDA.cpp
@@ -330,7 +330,7 @@ bool DDA::Init(GCodes::RawMove &nextMove, bool doMotorMapping)
                else
                {
                        directionVector[drive] = (float)delta/reprap.GetPlatform().DriveStepsPerUnit(drive);
-                       if (drive >= numTotalAxes && nextMove.coords[drive] > 0.0)
+                       if (drive >= numTotalAxes && nextMove.coords[drive] != 0.0)
                        {
                                extruding = true;                                               // flag this move as extruding even if the number of extruder microsteps is zero
                        }

makes it treat the retraction just like any print move and eliminates the glitch in the print:

What is the reason for forcing the printhead to come to a complete stop between printing and non-printing moves?

dc42

What the firmware actually does is to apply jerk only between printing moves, because the purpose of allowing jerk is to permit the printing speed to be maintained when there is a small change in printing direction, such as when printing a curve. When jerk is not allowed, if one of the motors is stopping then they must all stop in order to remain synchronised.

I can see that this will cause a problem if you use coast-to-end. I guess this hasn't been raised before because pressure advance is a better solution than cost to end, so Duet users rarely use coast to end.

I have made a note to review this in time for the next major release after 2.02.

DigitalVision

@dc42 said in Firmware issue: forced stop between print and non-printing moves:

What the firmware actually does is to apply jerk only between printing moves, because the purpose of allowing jerk is to permit the printing speed to be maintained when there is a small change in printing direction, such as when printing a curve. When jerk is not allowed, if one of the motors is stopping then they must all stop in order to remain synchronised.

I can see that this will cause a problem if you use coast-to-end. I guess this hasn't been raised before because pressure advance is a better solution than cost to end, so Duet users rarely use coast to end.

I have made a note to review this in time for the next major release after 2.02.

Thanks. Agree re. coast specifically but other variants are useful. I feel extruder jerk should probably always be enabled – at least I don't see a downside with that.

dc42

The downside of using extruder jerk is that it is not possible to apply pressure advance properly when there is extruder jerk.

I have attempted a fix in 2.02RC4 specifically to cover the case of using coast-to-end.