Duet 2 is freezing during operation

[goury]

Board: Duet Ethernet 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05 (2019-12-13b1)

Tried few times, rebooted few times.
It freezes at the same exact spot in this gcode file, around line 2413
Dice tray fast.gcode
I then cut its head and guess what — it freezes at the same spot, line 24 this time
Dice tray fast resume from 0.675.gcode

Motors stop (but are still powered), web intefrace disconnects, panel due seems to be able to read temperatures but machine doesn't react to anything but cutting off its power.
It doesn't seem to be overheating, thankfully.

What should I do?
How do I diagnose this deeper and further?
How do I avoid this in future?
Do you need any extra information from me?

PS: dice tray model of this gcode is under GNU GPL v3, sources are provided on request

[matt3o]

not sure about your issue and I don't know much about your printer, but are you sure about 300mm/s speed on the Z?

[JamesM]

Main thing people on here need to see with something like this would be your config.g file and possibly run an M122 command and post that up right before the print freezes. I also agree with the previous statement, 300mm/s speed for Z? I sure hope it's not set that fast in the config.

[Danal]

Yes, please post your config.g

Regarding the F18000.00 (300 sec) on the Z moves, there were 19 moves at that speed those before line 2413. Some Z only; some XY only. Anyway, seems unlikely that is the cause when 18 of them worked. Of course, there are thousands of G1s before the one that locked... It is interesting to note that the next 'upstream' feedrate for XYE moves was 5400. There are other sections that have XYE at 7200, sections that worked. Also, there are some XY only moves (that look like wipes) at F14400 (240 sec)

Anyway, the speeds don't seem to directly cause any lockup. I don't see anything else odd about that Gcode.

Last line is 2413:

G1 Z0.675 F18000.000
G1 X-76.392 Y-2.207
G1 F7200
G1 X-76.392 Y-55.495 E1.83982

[Danal]

I think I'd debug from this point by slightly changing slicer parameters and re-slicing.

And/or

Take out the failing line (which will cause a tiny gap in the print).

[bot]

I would upgrade to the latest 2.x firmware.

Also, can you get a M122 dump when this happens?

[goury]

@bot upgraded to 2.05.1, same thing is happening during different prints.

@matt3o my top speed is set to 400mm/s and this machine can do this.
Not very precisely on XY plane, but its Z is driven by three beefy motors, so there is no problems.
Also, since it homes at top, it otherwise takes too much time for head to move all the way down to the bed.
Time that I don't like wasting.

@Danal config.g
I like it moving fast during retraction. Ringing won't happen in those phases, but any extra delay can cause thermoplastic to dip out of the nozzle.
Machine doesn't skip any steps at 400mm/s unless there's something in its way.
Whenever there's a possibility of something to be in its way it moves under 150mm/s.
If only I knew what parameters to change.
To me it looks like regular G1 moves.
My goal is not to take lines from gcode but to fix firmware so it won't freeze ever.
Having a freeze or two per every new design (yes, this is how often this is happening per 50 grams of material) is very frustrating and counterproductive.

[goury]

@JamesM it's 400mm/s in config and it works reliably.
Should I put m122 on every second line or is there a shortcut?

[Phaedrux]

M350 X256 Y256 Z256 E256 I1 ; Configure microstepping with interpolation
M92 X1280 Y1280 Z1280 E1552 ; Set steps per mm

Reduce your microstepping to x16 with interpolation and adjust your steps per mm to match.

Similar stalls have been reported and it's always been traced back to using x256 microstepping. This can be exacerbated by high speed moves, which cause the step generation limit to be exceeded, causing hiccups.

Usually in the M122 report there would be a number of hiccups shown. However, yours shows none. Every time the M122 is run, the counters are reset, so I'm not confident to say you have no hiccups without more testing.

so if you want to test, drop the microstepping and see if the stalls go away. Or keep using x256 and run m122 immediately after the stall to see if there are any hiccups reported.

[goury]

@Phaedrux
Right now M122 says Hiccups: 128302, FreeDm: 156, MinFreeDm: 116, MaxWait: 2417589ms
It this a lot or not enough to worry?

I don't think I can run it right after the stall as it doesn't respond to anything.

[Phaedrux]

@goury said in Duet 2 is freezing during operation:

It this a lot or not enough to worry?

That's quite a lot, and likely growing, to the point where it's locking up.

x16 with interpolation to x256 is your answer. There's really no downsides. Less CPU load, motors are still quite and smooth, no difference to positional accuracy.

[goury]

@Phaedrux
So I did M350 X16 Y16 Z16 E256 I1
And now I have Hiccups: 0, FreeDm: 156, MinFreeDm: 104, MaxWait: 405246ms

Though It is very sad that 256 microstepping isn't really usable =(

[dc42]

@goury said in Duet 2 is freezing during operation:

Though It is very sad that 256 microstepping isn't really usable =(

You are getting interpolation to x256 microstepping, that's what the I1 parameter does.

[goury]

@dc42 interpolation isn't real stepping.
It's better than not having it, but it's 0,0125 mm accuracy versus 0,00078125 mm accuracy.
I sure don't need 0,001 mm accuracy for my application because material itself can't be this much accurate, but 0,01 can some times be visible (this is why I switched to full 256 microsteps.
I've tried 1/64 before switching to 1/256, it did improved some surfaces but not as much as 1/256 did.

What's about Duet 3?
Does it have the same issue or should I start saving for an upgrade?