Prints slowing down and pausing in between moves
-
@sourteig I don't know, if this is relevant, but I also tried turning off input shaper, pressure advance and linear advance. No difference without them.
-
@sourteig And of course my first task was to check the wiring and the crimps. Everything is ok here.
-
@sourteig two possibilities come to mind:
- Is it doing very short zigzag movements? Such movements are intrinsically slow, because the print head has to accelerate, decelerate and reverse direction each time.
- Another user reported an issue with long sequences of very short GCode segments slowing down. This was a new issue in firmware 3.3 and is believed fixed in 3.4beta2, although I am still waiting for confirmation from the original user. With firmware 3.3 I suggested increasing the length of the movement queue as a workaround (see https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M595_Set_movement_queue_length) but this should not be necessary with 3.4beta2.
-
@dc42 Thank you for your quick reply. In fact it's about very short zigzag moves. What's irritating to me is, that the speed drops to 0mm/sec for 1 or 2 seconds and then it raises up again. It's doing that many times in each layer, for each gap it has to fill. That's stretching the printing time in an enormous way and the remaining on one point of the object is making that one spot hotter and hotter, what you will see afterwards in the print.
Should I try to extend the movement queue? How much should I try?
And what's that strange message with the motors may beeing disconnected. -
@dc42 And one other detail (don't know if it's relevant) With every speed change (2 times a second) the progress bar under Printing Status is jumping like crazy between 0.6% complete and 78.8% complete and many values in between.
-
@sourteig that definitely isn't right. Please share the GCode file.
-
@dc42 Sorry it's too big to upload it here.
I uploaded it here:
https://www.file-upload.net/download-14653438/VoronTeileNeuerVersuch.gcode.html -
@sourteig please can you upload it to a site that does not require a login. For example, Dropbox, or Google Drive.
-
@dc42 Hi, sorry now it's uploaded to google drive:
https://drive.google.com/file/d/152xQRM__zzOg7v84xMwgyW9Tk7V_hUEt/view?usp=sharing
-
@dc42 Any idea why this could happen? In the meanwhile I tried different slicers, also a different toolboard and a different extruder motor, but I have no idea, why it does slow do that much. I checked all of the mechanics and wiring and everything seems to be right.
-
Are you using 3.4 beta2 on both the mainboard and toolboard now?
Can you tell if it's only gap fill that is behaving like that?
What speeds do you have set in this macro?
; Accelerations and speed
M98 P"/macros/print_scripts/setup_printing.g"What do you have in M98 P"/sys/print_start.g"?
I note from your gcode file that the gap fill sections have very small extrusion amounts.
;TYPE:Gap fill ;WIDTH:0.237375 G1 F4800 M204 P1000 G1 X211.402 Y165.503 E0.00282 G1 X211.393 Y165.494 E0.00018 G1 X211.122 Y165.228 E0.00559 G1 X210.850 Y164.963 E0.00559 G1 X210.842 Y164.955 E0.00017 G1 X210.587 Y164.674 E0.00558
Have you tried a different slicer to rule that out?
And finally, have you tried firmware 3.3 to see if it's the same there?