[Bug]: High acceleration can cause a very large number of hiccups

[gloomyandy]

Duet Forum Discussion Thread

From a PM with DC42

Which Duet products are you using?

• Duet2-Wifi
• Duet2-Ethernet
• Duet Expansion Breakout Board
• Duex2
• Duex5
• Duet2-Maestro
• Maestro Dual Driver Expansion
• Duet3-6HC
• Duet3-3HC
• Duet3-1XD
• Duet3-1LC
• Duet3-Tool Distribution Board
• Duet3-Mini5+
• Duet3-Mini2+
• Raspberry Pi or other SBC
• SmartEffector
• Magnetic Filament Sensor
• Laser Filament Sensor
• PT100 Daughterboard
• Thermocouple Daughterboard
• PanelDue
• Other
• None

Firmware Version

RepRapFirmware 3.5.1 (problem probably exists from rc.4 onwards)

Duet Web Control Version

3.5.1

Are you using a Single Board Computer (RaspberryPi) with your Duet?

• Yes I use a SBC.
• No I do not use a SBC.

Please upload the results of sending M122 in the gcode console.

M122 Report

Please upload the content of your config.g file.

Config.g

Please upload the content of any other releveant macro files.

No response

Details specific to your printer.

No response

Links to additional info.

No response

What happened?

As reported via PM to DC42:
If you have very high extruder acceleration (in this case M201 E300000) and then do an extruder only move that is relatively slow (in this case G1 E-2 F200) then that will trigger this code:
https://github.com/Duet3D/RepRapFirmware/blob/3.5-dev/src/Movement/DDA.cpp#L1177
which will then set topSpeed to 0 (since this move has a start speed of 0) this in turn will mean that this code: https://github.com/Duet3D/RepRapFirmware/blob/3.5-dev/src/Movement/DDA.cpp#L1269
will perform a division by zero and the resulting clocksNeeded will be ridiculously high which will then cause problems in the step generation code and trigger lots of hiccups and generally use a lot of cpu.

The obvious solution is not to set such a high acceleration, but I suspect there may be a few folks out there with this sort of setting because there has been various posts on the forum that recommend setting a very high extruder acceleration. I'm not sure what other options we have though (I don't really understand what problem this code is there to fix), but obviously in this case we should really do the E movement.
While tracking down this problem I've also observed something else that is a little odd, the original test case for this was...

G1 Z200 F1000
which actually worked fine. However:
G1 E-2 F200
M400
G1 Z200 F1000

does trigger the problem. Digging into it a little it seems that in the first case the extrusion move is being sorted of merged with the Z move by DoLookahead, in this case then endspeed of the extrusion move was being adjusted upwards from 0 which in turn avoided the problem described above. I'm not sure if it actually makes sense to allow moves on Z to impact the end speed of an extrusion move or not?

Looks like the code that is forcing topSpeed to 0 was new in rc.4, so I guess that explains why we had not seen this problem before now.

Comment from DC42:
I think something like this would be a reasonable fix to 1175:

    if (startSpeed + acceleration * MinimumAccelOrDecelClocks > requestedSpeed && startSpeed >= requestedSpeed * 0.95)

and similarly using endSpeed in line 1187.

[dc42]

This issue had the same cause as #994. Fixed in 3.5-dev.