2.4.58.2 Nightly Perimeter Segmentation Causing Slowdowns

[CCS86]

What happened?

I sliced this print with 2.4.58.1, but the issue with many M73's causes bad motion. So, I downloaded the 2.4.58.2 nightly. The code looked good, so I put it on the printer, but I am seeing some odd slowdowns.

In this region of the print (Z4.65 in the video), the inner walls (coming from the outside) are producing slowdowns. The walls which print from the inner portion of the model do so flawlessly.

Video: https://photos.app.goo.gl/7Zi8vDvSz4c4muNW8

I believe the cause is that the segmentation is really sporadic. For a nice continuous circular arc, the segment lengths are all over the place: (look at the extrusion amounts)

Compare those to the perimeters generated from the inner surface: (nicely uniform)

Project file & How to reproduce

OP10-Fix.3mf.txt

Version

2.4.58.2

Operating system

Windows 10 x64

Printer model

i3 MK3

[CCS86]

Behavior is not there in 2.4.58.1:

[CCS86]

Worth mentioning, this issue is causing 2.4.58.2 code to be 170% # of lines, compared to 2.4.58.1 with same settings.

[supermerill]

that's because there was a merge error in the 2.4.58.1, where it still has a mandatory 0.0125 resolution applied.
If you prefer that, then use a 0.0125 resolution instead of the unlimited you have now.
If you prefer hte unlimited resolution, then the current behavior is expected. just reduce the processing limits if the printer stall.

[supermerill]

Also, in Prusaslicer, when resolution is set to 0, it means it's set to 0.0125.
I just checked and I forgot to change the value from 0 to 0.0125 when converting a prusa file. will fix that.

[CCS86]

that's because there was a merge error in the 2.4.58.1, where it still has a mandatory 0.0125 resolution applied. If you prefer that, then use a 0.0125 resolution instead of the unlimited you have now. If you prefer hte unlimited resolution, then the current behavior is expected. just reduce the processing limits if the printer stall.

If it is truly a global issue from the resolution setting, why are the walls generated from the inner surface perfect (E0.01504 for every segment), while the walls from the outer surface keep toggling between E0.017, E.010, E.006, E0.004, etc? Why so much variation on a circular arc?

[supermerill]

because of threshold and lengths from different radius.

[CCS86]

That is surprising.

Will the implementation of this help to even out the segment lengths? #2319

[CCS86]

My thought is that I want my actual STL and the slicer's resolution of the STL to be as high as practical (slicing time being the biggest limiter). That way the slicer is using the most accurate data, avoiding the stacking of positional error. This should provide the most consistency in alignment of segments (as you move vertically), in seam placement, and in segment length.

Am I correct in this thinking?

[CCS86]

Sort of a cool visualization:

I made a test part to watch how segment length changes with radius. It prints starting with the outer wall and moves inwards:

Here are all the segment lengths in 2.4.58.2:

Here is the same chart, with forced 0.0125 resolution:

Here is the same chart in 2.4.58.1:

It seems like there is something else going on causing the small segments in the large radius areas.

[supermerill]

Am I correct in this thinking?

it's ok

It seems like there is something else going on causing the small segments in the large radius areas.

Like I said, I removed the calls for simplifying with the 'gcode resolution' from gcode writer that were added by the merge, to recover the 2.3 behaviour. I guess I may have removed a bit too many simplify() from the codebase, as it can still remove some points at the gcode step before the 'max_gcode_per_second'.

[CCS86]

I'll check again on the next release, but the 2.4.58.2 nightly seems to be violating the max G1/sec with these tiny moves.

With a commanded speed of 65mm/s, max G1/s = 200, min ext. length = 0.25mm, I can see segments that are 0.25mm long. This would be ~260 G1/sec (if they were continuous.

Unless you are looking at a rolling average of segments, rather than per segment extrapolation. In that case, no rules are likely broken.

[supermerill]

it's looking to remove less useful points, and then delete the ones that are still not far away enough.
It allow some point to be a bit below the limit, as it allow some other to be a bit higher the limit.
There is a hard limit on 2 times too much points in worst case scenario.

I may have to refine the algo to use a buffer size, to ensure the firmware one is never full.

[qwewer0]

@CCS86 Could you repeat the visualization for the latest version? (as you did before?)

Thanks!

[CCS86]

It definitely looks better than 2.4.58.2, more concise in the segment lengths... maybe not quite as good as 2.4.58.1 (because of the two lower lines of short segments in the large radius area:

For this same one layer test cylinder with all walls 2.4.58.3 is producing about double the overall segments (60389 vs 314953 in 2.4.58.1).

2.4.58.3

2.4.58.2

2.4.58.1

[CCS86]

Some more cool data that uses histogram charts to show the distribution of segments lengths.

Complete layer (all radii):

These charts are from the first 50% of the code, so only the larger radii:

These charts are from the first 10% of the code, so only the largest radii: