Slow and weird at 140mm/s on curvy/circular path

  • Hi,

    I need help to figure out what's happen…
    my printer is a core XY with 0.9 motors 20 teeths pulley i tested motion without extruding and i can go to 300 mm/s without any problem (accel is 5000mm/s² can go to 8000), extruder is a E3D titan.
    I don't understand what happen now (Have i test with the previous firmware?), when i launch a print with straight line everythings is ok (cube calibration) but when it have to follow a curvy or a circle path i get a weird result (jerky and lot of blobs), the print slow down and seem to move segment by segment by jerky move. It was setup to 140mm/s, 0.2 mm layer height with a 0.4 nozzle (nothing exceptional...).
    This is a short video it's not easier to see but you can heard a "tac" (it's not coming from extruder) and see how many blob are comming from this weird jerk
    Fullspeed from 0" to 16"s
    70% speed from 16"
    When i decrease the speed to 70% movement become smooth again.

    The file was sliced with S3D, no special functionality on it.

    Thanks for your feedback !

  • administrators

    Please run M122 to clear the stats, then run your test print for a little while at full speed. Then run M122 again and look for for the count of Underruns in the Move diagnostics. Repeat using 70% speed. Then report the underrun counts here.

  • Ok, i will do this tomorrow morning.
    Thanks !

  • Hi,

    At full speed :
    Move Diagnostics:
    MaxReps: 8, StepErrors: 0. Underruns: 2475

    At 70% :
    MaxReps: 5, StepErrors: 0. Underruns: 2869

  • administrators

    That's the first time I have seen an underrun count higher than a few tens, and is almost certainly the cause of the problem. Can you confirm that you are printing from SD card?

  • Yes printing from SD card, the file is uploaded by the web interface and launching with it.
    I also tried with the 1.13 firmware and same issue.

    Now i will try with an other slicer.

  • administrators

    Thanks. The results with another slicer - or with the latest version of S3D - will be interesting.

    I have some work scheduled that should allow a greater throughput of gcodes before underruns occur. If it goes smoothly then this will be in release 1,15.

  • The file was sliced with S3D last version.
    I made a quick try with kisslicer and Slic3r this last give me the same problem (visual) and MaxReps: 8, StepErrors: 0. Underruns: 1225, more i increase speed (either by the web interface) it also increase the underruns.

    Hope it's helping you

  • If you need specific test, don't hesitate to send me them !

  • Just finished printing this model: (small one), using Slic3r 1.2.9, layer height is 0.2 mm.
    Got the following results: MaxReps: 5, StepErrors: 0. Underruns: 443

    I can provide gcode file or settings used if this can help.

  • Can you send me a Gcode for this one : .There are more curvy path on it and i will compare the gcode with mine…

  • I was worried about a mechanical problem so i did a quick test at 200mm/s with a low polygon model :

    Really happy of it even i didn't finish the print (children never can wait…). The sound is really different from what i encounter with curve. For reference this is a cylinder printed at 70mm/s and i push the speed to 150 % after 10mm. You can see how many blobs are coming...

  • Are you running a 12v supply? Seems like you're simply commanding too fast of a feedrate. 0.9 degree steppers require double the number of steps as 1.8. CoreXY requires another doubling of steps compared to cartesian. You're losing a lot of speed to resolution that you may not be using in terms of additional accuracy. I'd suggest going back to 1.8 degree steppers, or upping the power supply to 24v (if not already), or both.

  • I'm still in 24v and i will do a test with a 1.8 motor for extruder but i think that's not the problem cause it work well (previous video) when extruding a straight line. And blods seem to come cause extruder is overextruding compare to the motion

  • administrators

    cubexupgrade, I have put an experimental firmware binary at You may find that it allows higher speeds before the quality deteriorates. Or not.

  • It's not the extruder motor per se that needs to be 1.8, it's simply that you are requesting too many steps in too little time. Try the new firmware, see how it works, and then either dial down speed or resolution. These are your only choices really.

  • @DC42. This isn't something that could be cured by changing the value for M566 is it? I don't really understand how it works except that it is most noticeable when printing cylinders. Just a thought….....

  • administrators

    If it's a regular speed up/slow down when printing "cylinders" with small numbers of facets, then higher M566 values do help to achieve higher print speeds. However, the blobbing in the image suggests something else, which is that the cylinder has a very large number of facets (therefore many gcode commands per perimeter). and the gcode processing and lookahead system isn't filling the pipeline as fast as the motion generation system can empty it when it runs at the requested speed. This is confirmed by the high underrun count. The underrun count is incremented every time the lookahead system finds that in trying to achieve the requested speed for one move, it needs to adjust then profile of some earlier move, that move has already been frozen because it is due to be executed soon.

  • administrators

    In effect, as bot says, the resolution is too high. This used to be a problem with S3D but using Cura or Slic3r did not have the same issues. If you have tried these and still the same issue maybe try reducing the number of facets of the model?

  • Sorry soccer evening (and we won !! ) !
    Thanks for your feedback i will try the experimental firmware tomorow, and it's sure exchanging the 0.9 motor by a 1.8 and if not enough going to a direct extruder, the e3d titan combine to 0.9 motor need lot of signal… I design this bot to be speed but this extruder combo were just here cause my own design are still in work in progress (1.8 motor and geared drive 1 : 2).

    I experimented this issue with lot of model, astrobot, morena treefrog... Always when curve or and loop are sharp and short.
    I tried kisslicer and it seem to work because the oversampling was set really low but i 've the same issue with slic3r on the same cylinder.

    Is there a way to calculate the limit the duetwifi can achieve per configuration ?

  • dc42 has been making improvements in just that area recently, so the numbers are liable to improve. He has mentioned the latest speeds here:

    I'm not sure that you can directly calculate the exact speeds you can move, as they depend on the number of individual commands that makeup the steps, how many motors are moving, etc.

    You could also try lowering the microstepping to 8x instead of 16x, but I'm not sure the results will be excellent.

  • Hi,

    So i tested the experimental firmware, i didn't see lot of difference, each time i go upper than 100 mm/s i see and heard this jerky motion and it's not going to the speed asked. I also replace my extruder motor by a 1.8° and the issue is the same.
    Is it only me who get this problem when going over 100mm/s in curve ?

    I will try your suggestion to lower microstepping and see what's happen. I'm here to test !

  • administrators

    I really don't think lower microstepping will help (just as using a 1.8deg motor didn't), because the problem isn't the step generation rate. Can you tell me the length of each line segment in the gcode for the cylinder that gets jerky above 100mm/sec?

  • I don't know if it can help, this is a cut and past from my gcode file :

    ; inner perimeter
    G1 X100.300 Y114.322 F6000
    G1 X99.700 Y114.322 E0.0104 F4650
    G1 X99.100 Y114.297 E0.0104
    G1 X98.503 Y114.246 E0.0104
    G1 X97.907 Y114.171 E0.0105
    G1 X97.316 Y114.071 E0.0104
    G1 X96.729 Y113.946 E0.0104

    Segment are really small…

  • administrators

    So the segments are 0.6mm long. At 100mm/sec that's 167 segments per second. The current firmware tries to freeze moves 1/8 sec before they are needed, so it wants to freeze 20 moves. But the length of the move queue is only 20 moves in firmware 1.14 and earlier, and 30 in 1.15beta1. That explains the underruns.

    I've changed the code to freeze at most half of the queue capacity, and increased the queue capacity further to 40 moves. Please try the new beta at Let me know if it improves the quality at high speed and/or decreases the underrun count.

Log in to reply