Stuttering Linked with Segment Size and Feed Rate



  • Hello All,

    We recently noticed some vertical banding in our prints and have been able to link a particular case with stuttering during small segments. When trying to isolate where this occurs by moving on a single axis, we noticed a link with feed rate. We have also tried with FW 3.1.1. and the results were worse (M112 showed never used RAM at 5668).

    Does someone know how we might be able to fix this? Does this hint to buffering or processing?

    Our Test

    • Measure the time it takes to complete a 200mm move, at a constant feed rate while varying segment size
    • e.g. g-code for testing a 0.1mm segment size at 3000mm/min looked like this:
      G1 X0.1 F3000,
      G1 X0.2 F3000
      ......
      G1 X200.0 F3000

    Electronics

    • Board: Duet WiFi 1.02 or later + DueX5 (duetwifi102)
    • Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3)
    • Duet WiFi Server Version: 1.23
    • G-code file located on the board board SD card
    • Motor connected to Duet WiFi

    Motor Settings
    M92 X80.00; set steps per mm
    M350 X16; Configure microstepping with interpolation
    M566 X125.00; Set maximum instantaneous speed changes (mm/min)
    M203 X3000.00; set maximum speeds (mm/min)*** (Experiment for Y)
    M201 X500.00; set accelerations (mm/s^2)*** (250 for Y)
    M906 X1840.00; Set motor currents (mA) and motor idle factor in per cent

    Results

    • at a feed rate of 3000mm/min, we noticed a an increase in travel time when segment size dropped below ~0.12mm
    • at a feed rate of 2000mm/min, we noticed an increase in travel time when segment size dropped below ~0.05mm
    • at a feed rate of 1000mm/min, we noticed an increase in travel time when segment size dropped below ~0.016mm
    • as segment sizes decrease below each of the ones mentioned above, stuttering increases and total travel time increase

    Conclusion

    • there appears to be a minimum time per a segment and when you drop below it you see stuttering - from these tests ~0.001 - 0.002 sec/segment (segment size/feed rate)

  • Moderator

    Please update to firmware 3.1.1 and see if you still experience the same issue.

    also please post the entire config.g and M122 report.

    Do you have mesh compensation active?



  • Hi Phaedrux,

    Thanks for the quick response and help!

    • We actually see more stuttering/longer travel times with small segments and FW3.1.1
    • No mesh compensation

    The tests we ran are just using the X motor.

    Config.g
    ; General preferences
    G90 ; send absolute coordinates...
    M83 ; ...but relative extruder moves
    M575 P1 B57600 S0

    ; Bed Leveling Locations
    M669 K0; ; Kinematics defined as Cartesian

    ; Network
    M552 S1 ; enable network
    M586 P0 S1 ; enable HTTP
    M586 P1 S0 ; disable FTP
    M586 P2 S0 ; disable Telnet

    ; Drives
    M584 X0 Y1 Z2 E6 ; create the additional axis and assign stepper drivers to them

    M569 P0 S0 ; Drive 0 goes forwards - X
    M569 P1 S0 ; Drive 1 goes reverse- Y
    M569 P2 S1 ; Drive 2 goes forwards - Z

    M569 P6 S0 ; Drive 6 goes forwards - X EXT

    ; Endstops
    M574 Y0 P"nil" ; Y has no endstop, free up Y endstop input
    M574 Z1 S1 P"zstop" ; Z min, active high endstop switch
    M574 X2 S1 P"e0stop" ; X max, active high endstop switch

    ; Motor Settings
    M92 Y117.777777 Z800.00 X80.00 E492.45 ; set steps per mm
    M350 Y16 Z16 X16 E16 I1 ; Configure microstepping with interpolation
    M566 Y400.00 Z12.00 X125.00 E120.00 ; Set maximum instantaneous speed changes (mm/min)
    M203 Y16000.00 Z450.00 X3000.00 E15000.00 ; set maximum speeds (mm/min)
    M201 Y1200.00 Z20.00 X500.00 E500.00 ; set accelerations (mm/s^2)
    M906 Y1440.00 Z2400.00 X1840.00 E1000.00 I30 ; Set motor currents (mA) and motor idle factor in per cent
    M84 S30 ; Set idle timeout

    ; Axis Limits
    M208 Y-1000000000 Z-30 X0 S1 ; Set axis minima
    M208 Y1000000000 Z600 X300 S0 ; Set axis maxima

    ; Heaters
    M308 S0 P"bed_temp" Y"thermistor" A"Bed" T100000 B3950 ; define bed temperature sensor
    M950 H0 C"bed_heat" T0 ; heater 0 uses the bed_heat pin, sensor 0
    M140 H0
    M143 H0 S80 A2 ; switch off heater 0 temporarily if it exceeds 80°C

    M308 S3 P"duex.e3temp" Y"thermistor" A"X" T100000 B4725 ; define X sensor to sensor 3, thermister pin 3
    M950 H3 C"duex.e3heat" T3 ; heater 3 uses the bed_heat pin, sensor 3
    M143 H3 S285 A0 ; raise a heater fault if it exceeds 285°C

    ; Fans

    M950 F3 C"duex.fan3" Q100 ; Fan 3 is connected to fan pin 3, PWM at 100Hz

    M106 P3 S1 H3 T45 ; Set fan 3 (X) to 100% when it reaches 45°C, thermister sensor 3

    M950 H1 C"nil" ; Unassociate heater 1 (pin e0)
    M950 H2 C"nil" ; Unassociate heater 1 (pin e1)

    M950 F1 C"e1heat" Q100 ; Fan 1 is connected to heater 2 pin, PWM at 100Hz
    M106 P1 S1 ; Set fan 1 (Duet Driver Fan) to 100%
    M950 F2 C"e0heat" Q100 ; Fan 2 is connected to heater 2 pin, PWM at 100Hz
    M106 P2 S1 ; Set fan 2 (Duex Driver Fan) to 100%

    ; Tools

    M563 P0 S"X Axis" D0 H3 ; Define tool 0
    G10 P0 X0 Z0 ; Set tool 0 axis offsets
    G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    M501

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DGM-917NK-F23T0-6JTDL-3S46S-KDA4F
    Used output buffers: 6 of 24 (22 max)
    === RTOS ===
    Static ram: 27980
    Dynamic ram: 94424 of which 24 recycled
    Exception stack ram used: 504
    Never used ram: 8140
    Tasks: NETWORK(ready,424) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1824) IDLE(ready,80)
    Owned mutexes: WiFi(NETWORK)
    === Platform ===
    Last reset 00:05:00 ago, cause: power up
    Last software reset at 2020-06-01 13:33, reason: User, spinning module GCodes, available RAM 5860 bytes (slot 1)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
    Error status: 8
    MCU temperature: min 34.5, current 34.9, max 35.4
    Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: ok, SG min/max 0/34
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: standstill, SG min/max not available
    Driver 9: standstill, SG min/max not available
    Date/time: 2020-06-01 13:39:35
    Cache data hit count 520404793
    Slowest loop: 42.60ms; fastest: 0.12ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Storage ===
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest read time 3.4ms, write time 2.3ms, max retries 0
    === Move ===
    Hiccups: 0(0), FreeDm: 165, MinFreeDm: 164, MaxWait: 59518ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 188, completed moves: 148, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
    === GCodes ===
    Segments left: 1
    Movement lock held by null
    HTTP is idle in state(s) 0
    Telnet is idle in state(s) 0
    File is ready with "M122" in state(s) 0
    USB is idle in state(s) 0
    Aux is idle in state(s) 0
    Trigger is idle in state(s) 0
    Queue is idle in state(s) 0
    Daemon is idle in state(s) 0
    Autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 201.89ms; fastest: 0.09ms
    Responder states


  • Moderator

    @gantri_hw said in Stuttering Linked with Segment Size and Feed Rate:

    Our Test

    Measure the time it takes to complete a 200mm move, at a constant feed rate while varying segment size
    e.g. g-code for testing a 0.1mm segment size at 3000mm/min looked like this:
    G1 X0.1 F3000,
    G1 X0.2 F3000
    ......
    G1 X200.0 F3000

    How are you sending the gcode? Can you share the gcode file?

    Sending a string of small 0.1mm moves is not the same as sending a single long move.


  • administrators

    There are two possible issues here:

    1. You may have hit the limit on how many GCode commands RRF can process per second. That limit depends to some extent on where the GCode commands are coming from. The maximum speed is when the commands are read from a file on the SD card, and the SD card is formatted with a large cluster size.

    2. You may have hit the limit on how many moved can be buffered in the queue. That limit is 40 moves for the Duet 2 series. The planner needs to be able to decelerate the machine to zero speed after the last move in the queue, because it doesn't know what (if anything) will come next. When you have a lot of small segments, this in turn limits the top speed that can be reached. You can calculate this limit using the standard motion formula v^2 = u^2 + 2as (in this case, v=0 and u is the top speed that can be reached). For example, with your acceleration setting and a segment length of 0.1mm:

    u^2 = 2 * 500 * 40 * 0.1 = 4000

    giving a top speed of sqrt(4000) = 20mm/sec. So it's not surprising that you don't reach 50mm/sec (F3000). In practice the top speed is a little higher than this because of allowed jerk.

    Your X and Y accelerations are low for a 3D printer, and this is contributing to getting a low top speed.



  • @Phaedrux, the code is on SD card 0 on the Duet. Code: X_2000FR_pt1S.gcode

    @dc42 Thank you!

    1. Let me double check how it is formatted and if not at the largest cluster size, I'll re-try our tests.
    2. Is there a way to confirm we might be hitting the 40 move buffered queue?
      The M122 was placed in the middle of the gcode test file, so is this telling us that?

    === MainDDARing ===
    Scheduled moves: 188, completed moves: 148, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3

    Thank you both for your help!


  • administrators

    @gantri_hw said in Stuttering Linked with Segment Size and Feed Rate:

    Is there a way to confirm we might be hitting the 40 move buffered queue?

    You can calculate whether that is likely to be limiting, as I demonstrated in my previous reply.



  • OK, got it. We'll try to adjust our acceleration settings to see if the buffer is limiting us. Thank you @dc42.



  • @dc42 said in Stuttering Linked with Segment Size and Feed Rate:

    There are two possible issues here:

    1. You may have hit the limit on how many GCode commands RRF can process per second. That limit depends to some extent on where the GCode commands are coming from. The maximum speed is when the commands are read from a file on the SD card, and the SD card is formatted with a large cluster size.

    2. You may have hit the limit on how many moved can be buffered in the queue. That limit is 40 moves for the Duet 2 series. The planner needs to be able to decelerate the machine to zero speed after the last move in the queue, because it doesn't know what (if anything) will come next. When you have a lot of small segments, this in turn limits the top speed that can be reached. You can calculate this limit using the standard motion formula v^2 = u^2 + 2as (in this case, v=0 and u is the top speed that can be reached). For example, with your acceleration setting and a segment length of 0.1mm:

    u^2 = 2 * 500 * 40 * 0.1 = 4000

    giving a top speed of sqrt(4000) = 20mm/sec. So it's not surprising that you don't reach 50mm/sec (F3000). In practice the top speed is a little higher than this because of allowed jerk.

    Your X and Y accelerations are low for a 3D printer, and this is contributing to getting a low top speed.

    It be nice to have a calculator where you could plug in board type, acceleration, jerk and segment size and get the max speed. There's one out there by @wilriker that calculates acceleration but not speed.



  • @gtj0 I'd be happy enough with a page in the dozuki with all these formulae listed in one spot. Though, to be fair, it's hard to remember how many formulae there are and what exactly they are and why they'd be relevant.



  • @dc42 said in Stuttering Linked with Segment Size and Feed Rate:

    [...]

    1. You may have hit the limit on how many GCode commands RRF can process per second. That limit depends to some extent on where the GCode commands are coming from. The maximum speed is when the commands are read from a file on the SD card, and the SD card is formatted with a large cluster size.

    [...]

    What is your best guest at an approximation of the GCode rate limit for different boards? I'm most interested in Duet 2 on RRF 2, but interested in the other combos as well.


Log in to reply