Underruns, ways to reduce?

Urban

Does anyone know a way to quantify improvements? For example, is it possible to simulate a print and measure the time for completion?

T3P3Tony

@urban comments are stripped out so should have no effect unless you have huge amounts of them.

dc42

@urban said in Underruns, ways to reduce?:

1 -I guess that PreparedUnderruns will cause the movement to stop?

Yes, and may also cause print quality issues. They shouldn't happen in normal use. When you run M122 and find that some have occurred, please check the "Longest main loop time" and report here.

2 - What is the consequence of a lookaheadUnderrun?

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.

Two questions:

From other information you posted, I deduce that your X and Y steps/mm is about 158.7. Is that correct? Please check by running M92, in case a change in microstepping has amended it.
Do you have logging enabled? If so, is anything written to the log file during a print in which underruns occur, other than the usual start and end print messages?

Urban

OK. I have turned on logging. The steps/mm=160 as reported by M92. I will do the tests next week since I need help from my college to assemble it after mounting a new vacuum bed and chamber heater.

Urban

I have done some tests and studies:

1 - I changed the SD card to a 32GB Samsung Evo plus with 95MB/s read and 20MB write speed that I verified on my computer. The card is formated to get max speed using SD Card Formater 5.0 that should give aligned blocks for maximum speed, actually 32kb sectors. No improvement on the underRuns or or lookAheadUnderruns.

2 - I turned on logging, but it looks ok.

3 - I am testing on a scaled Benchy, approx 180mm long. In the g-code there are 2964 xy-moves shorter than 0.05mm. Could those moves cause a problem?

4 - Longest main loop time - I can not find that entry in the reply from M122. Could it be this?:

Date/time: 2018-10-16 15:32:10
Slowest loop: 18.64ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 214, MinFreeDm: 150, MaxWait: 0ms, Underruns: 35, 1
Scheduled moves: 5225, completed moves: 5215

Any Ideas?

dc42

Yes that's the longest loop time, around 18ms. What I think is happening is that the model contains a sequence of very short moves and this means that the move queue isn't long enough to hold 0.5 seconds worth of frozen moves plus enough moves for the lookahead to work in that case. The move queue on the Duet 2 series is 30 moves long AFAIR.

Increasing XY acceleration may reduce the underruns, but may itself reduce print quality.

Urban

OK, Thank you!

Data reduction: I think there are two solutions for the input data (I think), one is to reduce the number of triangles and the other is to filter the contour after the slicing (the G-code file). If the triangles are reduced the file will be optimised for one size and the reduction itself can produce errors. Doing the reduction on the G-code file can be optimised for a specific machine and would not be to complicated if segments that are lined up in a strait line within a tolerance is removed.

Acceleration: I have a modest acceleration(1500mm/s/s) for the print move but can have a higher for travel moves (5000-10000mm/s/s). The rapid travel moves reduce ooze from the nozzle but due to the trapezoidal movement profile there can be ringing. An S-curve or similar movement profile would be beneficial.

T3P3Tony

@urban from memory some slicers have a setting to do this for you, minimum length or something like that.

RCarlyle

The Smoothie guys had issues with S3D gcode generating very small segments a while back. They made a segment reduction tool, you may be able to find that online somewhere.

An S3D update 1-2 years ago also included a minimum segment size too, I think? Are you running a recent version?

Urban

I will check slic3r for short segment removal. I have the latest version of Simplify3D, and I have not found such filter there, except to avoid generating shorter infills and similar. I will try to find the Smoothie program.

There would be som other benefits of filtering G-code since:

Many short segments on a strait line could be removed
Circular polygons could be transformed to G2 (my servo controller would like that)
Elliptical curves (tilted circular cylinders) could be optimised by 4 radii or special G-command

I am now running with lower accelerations and that removed overruns. The alternative solution is to improve the throughput is to use the M572 Pressure Advanced and a higher top speed.

Phaedrux

@urban Slic3r has an option under Print Settings>Advanced for resolution. It claims to simplify high resolution models. I'm not sure how it works though.

Urban

OK, thank you, I will check that.

Topher

@dc42 Looks like I am having the same Issue as Urban. Running on a wifi 2

Slowest loop: 80.30ms; fastest: 0.06ms
Scheduled moves: 22256, completed moves: 22216, StepErrors: 0, LaErrors: 0, Underruns: 0, 1
SD card in slot 0: capacity 15.93Gb, free space 15.90Gb, speed 20.00MBytes/sec, cluster size 32kb (sandisk ultra)

The machine stopped in the middle of the print. Fans and heaters still going as well as the job clock and file progress etc, just no movement or movement in the status window xyz.

Phaedrux

@LeckieTech Firmware version?

Topher

@Phaedrux it is 2.05.1 Im seeing after running the part again, several times actually. The print keeps freezing but not in the same spot though, in the same area however. I noticed just before it freezes that the extruder jittering back and forth something beyond normal. Its changing directions so fast its probably losing steps. I never heard it the first time around because its mounted on fan noise isolators since all of our printers are running pressure advance of 0.42 so its normal for them to be jittering but not like this. I tried to adjust my X Y acceleration and jerk values and found that lowering the acceleration seems to ease the extruder chaos. I read that DC42 said to increase it. Maybe its not the same issue after all

bot

@LeckieTech Are you using cura 4.6 by any chance?

Topher

@bot No, I'm using S3D. I've narrowed it down to exactly what is causing this now. When pressure advance is on (mine is set to .42) I'm finding some of the radii in my model are getting broken down into what appears to be way too many moves. So I reduced my model mesh to not allow any triangles larger than 0.08mm without losing too much resolution. That made no difference at all. Its 100% only inside perimeters and infill that causes the crashing, the outside perimeters print without any hesitation. I reduced the infill speed and it seemed to fix the crashes during infill. To stop the crashing on the perimeters I have to reduce my speeds substantially, from 90mm/s down to 40!

Topher

well, that's one way to do it. Had a spare feeder sitting on the bench plugged in so I'm not wasting precious filament during this pandemic. I started a print and walked away and when I came back it was unplugged on the floor with a short to ground message from DUET! So I guess it's true, you can short a driver, don't hotplug your motors kids.

dc42

@LeckieTech said in Underruns, ways to reduce?:

I started a print and walked away and when I came back it was unplugged on the floor with a short to ground message from DUET! So I guess it's true, you can short a driver, don't hotplug your motors kids.

As that motor has a removable cable, it's quite likely that the phases were not paired correctly, and that is what caused the driver to fail.