Stuttering Linked with Segment Size and Feed Rate

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.