Underrun interpretation and corrective actions?

Phaedrux

I can't answer your deeper question, but I believe the first type is less critical than the second, and you have no hiccups, which is even more important.

@dc42 would have to give you the nitty gritty.

Kolbi

Thanks @Phaedrux. It's not a major problem, the print came out perfect - but I would like to know the what, why, and how to make it better.

Cheers,
Kolbi

Phaedrux

You may find some posts from DC42 in the search results that give you more info in the meantime. Basically waiting for data.

https://forum.duet3d.com/search?term=underruns&in=titlesposts

I haven't parsed your gcode file, but would it be possible to find many small segments in it?

Kolbi

@Phaedrux I did see in a previous statement that underruns as I have exampled above, look-aheads I believe, "means that there was a series of very short deceleration-only moves in the movement queue, which could potentially be amended because of a new incoming move; but the first one was already being executed so only the later ones could be amended."

So does this mean that the number exhibited (52) corresponds to the number of times that RRF has streamlined the processed g-code, ridding it of groupings of 'very short deceleration-only moves' that are deemed not essential and of no concern?

~~AFAIK, ideaMaker doesn't have a setting to rid the generated g-code of small segments - I looked but don't see such.~~ Additionally, I do not know the clear definition of 'small segments'-what am I looking for in the g-code exactly?

Kolbi

@Phaedrux, Ug... Placing dunce cone on now!
Found this:
Screen Shot 2020-08-23 at 4.23.56 PM.png

What is the recommended minimal segment length?

bot

It depends how fast you want to print them. DC42 describes the calculation here.

Kolbi

Thanks for the assist @bot. I do admit that the formula is confusing me a bit. Given the below example from @dc42 response in the thread:

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.

Working the numbers in the example, sqrt(4000) gives me 63, is setting my mind adrift at the moment - not clear how 20mm/sec is derived from that. I'll work on that some more once I wake up fully.

Even with numbers crunched, once I figure them out that is, it still leaves me with the question, "does this mean that the number exhibited (52) corresponds to the number of times that RRF has streamlined the processed g-code, ridding it of groupings of 'very short deceleration-only moves' that are deemed not essential and of no concern?" and also what is a general recommendation for minimal segment length? I have never had any considerations of these aspects before as I never knew them to be an issue - so I'm definitely in a new territory.

Many thanks,
Kolbi

bot

In regards to the meaning of the underrun:

DC42 said, in this post

[...]
A lookahead underrun means that there was a series of very short deceleration-only moves in the movement queue, which could potentially be amended because of a new incoming move; but the first one was already being executed so only the later ones could be amended.
[...]

In regards to the formula:

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

We want to determine what is u, the top speed we can reach, given the acceleration, length of the move queue on a duet 2, and segment length.

For the segment length, 0.1 is a very good "worst-case-scenario" value to use. Seldom will you have many moves in succession that are smaller than this. But, sometimes you might have weird moves that are shorter than this pop up. If you tend to not have very small segments in G-Code, adjust this a bit higher if you'd like.

So, the formula without any values plugged in is:

u^2 = 2 * a * m * s where a is acceleration, m is the length of the move queue, and s is the segment length for the calculation.

In your case, it seems it should be:

u^2 = 2 * 2500 * 40 * 0.1
u^2 = 20000
u = ~141.4

Note the square root at the end.

[Edit: oh, I see what you mean about 20 mm/sec. I don't know about that.]

Kolbi

Thanks for taking the time to explain that @bot, I very much appreciate it.

Before I left my house this morning, I read this and then changed minimum segment length to .1mm and re-sliced the stl files. I still got ~60 look-ahead underruns but again, the parts turned out absolutely fine.
Then, I decided to see what prusaslicer would give... That gave me 6 look-ahead underruns.

So, now I'm regretting ever looking at M122 output
I'm wondering if is this a problem with my ~~settings in config.g somehow,~~ slicer settings, slicer choice, ~~sd-card throughput~~, or the generated stl file (from SolidWorks)?
Or actually is this a problem at all? Just because this particular part is turning out fine, will this underrun issue bite me in 6 at a later point?

Kolbi

Verified sd-card / reformatted via tool from https://www.sdcard.org/downloads/formatter/
M39: SD card in slot 0: capacity 31.72Gb, free space 31.55Gb, speed 20.00MBytes/sec, cluster size 32kb

From ideaMaker settings I have changed minimum segment length from .01mm to .1mm, yielding no appreciable change in look_ahead underruns.

Sliced the same part in PrusaSlicer, yielding no to ~5 look_ahead underruns whereas ideaMaker yielding 50-60.

All the while, the part is coming out absolutely fine - no defects.

My conclusion can only be that look_ahead underruns are not critical. Simply a number representing the number of times that RRF has 'optimized' the gcode, amending unneeded deceleration-only moves, before the physical planning process.

@dc42, Please correct me if I am wrong.

Cheers,
Kolbi