Stuttering Linked with Segment Size and Feed Rate

gantri_hw

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)

Phaedrux

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?

gantri_hw

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

Phaedrux

@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.

dc42

There are two possible issues here:

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.
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.

gantri_hw

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

@dc42 Thank you!

Let me double check how it is formatted and if not at the largest cluster size, I'll re-try our tests.
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!

dc42

@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.

gantri_hw

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

gtj0

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

There are two possible issues here:

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.

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.

bot

@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.

bot

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

[...]

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.

CCS86

Did anyone find more clarity on the board limitations for this?

I want to tune my slicer min segment length to get the most round circles I can, at the speeds I print, without underunning the buffer. It will probably need some real world testing, but estimates are helpful in reducing the iterations needed.

T3P3Tony

recent RRF (3.2) has improvements and 3.3 will have further improvements ( how much depends on which boards you are using)

There are some benchmarks here

https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY

3.2 also includes more reporting on bus speed, hiccups etc.

If you send M122 (and M122 Bn for any CAN connected expansion boards with drivers involved in the move) you will see "hiccups" and/ or "underruns" start to be reported for very short segments with a high step rate. you can use those to determine when your step rate is too high/segment length is too short.

Note that for circles I have seen other printing artefacts become apparent before I hit underruns using short segments on circles but of course YMMV.