resume redundant extrusion

droftarts

@bugpwr Thanks, I've asked @dc42 to have a look, see if he can see what's going on, as I'm not sure how to read the 'move' output.

Ian

dc42

@bugpwr I've taken a look at your debug output and I don't see anything abnormal in it. I can see the 10mm reprime move being generated correctly. After that I see some small extruder movements in combination with XYZ movements as commanded by the file.

Are you certain that the 10mm retract operation is being performed correctly? It might be helpful to try the pause/resume with the nozzle removed so that you can see whether the correct amount of filament is being retracted. If the retraction is not being fully performed, that would account for the reprime move ending up with the extruder skipping that we can hear. Perhaps you should try reducing the speed of that retraction in pause.g.

If that doesn't resolve it, please can you try putting a G1 G4 S2 command at the end of resume.g to add a 2 second delay. Then see whether the uncommanded extrusion follows on immediately from the 10mm reprime move (before the delay), or after the delay.

jay_s_uk

@bugpwr dc42 means G4 S2 and not G1 S2

bugpwr

@dc42 hi dc42, first - thanks for stepping in, this is much appreciated.
I have performed the experiments. Starting from the end - after adding the G4 delay, it's seen clearly that this extra E move happens after the whole file. (should I try adding M400 before the wait?)
The "redundant extrusion" happens very fast, unaffected by the F parameter in "G1 E10 F300" from resume.g, while the priming move is indeed affected by the F setting (with F300 for example, it is fairly slow and completed just fine, but then comes that extra move which is ultra fast and causes extruder skips). By the way, the F300 speed would not cause the skips, it would just extrude the filament. I tried making this even slower and I see the change in the normal priming move.

So, the source of the move is elsewhere (my honest guess would be that it has something to do with the "confinement" of relative move coordinates between the macro and the job file and switching between the two, but I have no evidence). Also, judging by the speed of this, it does not seem to come from any "actual" gcode in any of the files.

Here's another strange observation that is probably unrelated but may provide some useful evidence: the print head does not decend to the model before the G4 wait I have inserted; instead, it remains 5mm above the model, then the wait, then the failed extrusion, and then the print proceeds with print head descending to the last move. Thanks again, P

Notepad

It might be just coincidence, but I remember having a similar issues all the way back in 3.5.0 and never found a fix for it
https://forum.duet3d.com/topic/35544/resume-g-activating-twice-with-fw3-5

droftarts

@Notepad Thanks, I knew there was another report of something similar, couldn't find it! Do you still have this problem?

Ian

Notepad

@droftarts unfortunately so. My only solution was to half the de-retraction amount knowing it would double itself

bugpwr

@Notepad okay, reading the word 'double' sent me to do more tests. Indeed - the overextruded amount seems to depend on what's written oin resume.g, but not exactly double - it seems like tripple to me. That is, changing "G1 E10 F300" to E1 (1mm) makes the additional extrusion something like 2mm. If this command is completely removed, there's no extrusion before or after the G4. Hope this could give some insight.

dc42

@bugpwr I'm looking at your debug trace again and now I can see the extra extrusion. Following the G1 E10 command there are 7830 microsteps of extrusion at a top speed of 3915 microsteps/sec (5mm/sec) with acceleration at the start and deceleration at the end. Then there are another 7830 microsteps of extrusion at a top speed of 15660 microsteps/sec (20mm/sec), again with acceleration at the start and deceleration at the end.

I will take a look at the 3.5.4 source code to identify the reason for this. Meanwhile, please can you try upgrading to 3.6.0-beta.3. There have been fairly substantial changes to the movement code in that version since beta 2.

bugpwr

@dc42 this is not 3.5.4, this was actually the latest beta2 (I will try with beta3 later today).

dc42

@bugpwr I think I found the problem. It only affects Duet 2 and Duet Maestro. Please try the 3.5.4+1 firmware binary at https://www.dropbox.com/scl/fo/xx7tpppxwbirz4zm9yr0o/AEb98egoCKGGVfCydwsFit8?rlkey=q1eg5g59zt1rbr9wqam80zygx&dl=0.

Edit: the same bug is present in the Duet 3 builds of 3.6.0-beta.3.

bugpwr

@dc42 looks like it is completely solved in this fix.

dc42

@bugpwr thanks for confirming. I will generate a new 3.6beta3+1 for Duet 2 when I have fixed another bug.

dc42

@bugpwr I've put a 3.6.0-beta.3+1 build that includes this fix at https://www.dropbox.com/scl/fo/bx70c7u0bshq79ez83mnn/AKMj4UCEimtQuGYxRj_d0ew?rlkey=7yiq3x5fcae3v2ogslfocx1op&dl=0.

bugpwr

@dc42 many thanks, the beta3+1 update works like a charm!!
(completely unrelated: speaking of 2.85mm systems, I don't want to bother you with a minor thing, but it would be awesome if M404 would upate move.extruders[].filamentDiameter. As of now, DWC always shows incorrect volumetric rate for 2.85 machines)

bugpwr

by the way, I am having some (unrelated) motion troubles with the beta3+1. On a couple of incidents homing commands got stuck (e.g. G1 H1 Y480 F5000) I did not investigate further.
The screenshot attached popped up mid printing.

oliof

@bugpwr best to open a separate thread for the separate issue so this can be marked solved.

dc42

@bugpwr said in resume redundant extrusion:

@dc42 many thanks, the beta3+1 update works like a charm!!
(completely unrelated: speaking of 2.85mm systems, I don't want to bother you with a minor thing, but it would be awesome if M404 would upate move.extruders[].filamentDiameter. As of now, DWC always shows incorrect volumetric rate for 2.85 machines)

You can use M200 S0 D### to set the filament diameter to ###. Unlike M404, M200 allows you to set per-extruder filament diameters.

dc42

@bugpwr said in resume redundant extrusion:

by the way, I am having some (unrelated) motion troubles with the beta3+1. On a couple of incidents homing commands got stuck (e.g. G1 H1 Y480 F5000) I did not investigate further.

That is the second line of a 2-line error message. The first line includes a single-digit error code, which I need to know to investigate this further.