PrusaSlicer with enhanced precision and removal of odd flow math

[Exerqtor]

@bot have you ran this by Merill on github regarding merging it to SuperSlicer ?

[bot]

I know for sure he is against removing the flow math. He seemed quite angry at my first suggestion of it.

The other changes I have mentioned to him in passing. He says he has played with the RESOLUTION setting (the one I changed from 0.0125 to 0.001 -- thanks to @Edgars-Batna for tipping me off about that change. He is what started this rabbit hole I'm digging!) But I guess he says he "changed too much" and was having stability issues. He may try changing that again. That single change is good enough for most people.

The decimal precision of GCode output isn't exactly necessary, except to "extract" the maximum accuracy and precision from the calculations. If slic3r was just modified to calculate extrusion based off the rounded X/Y points, the added decimal output would not be useful at all.

But yeah, the flow math? I doubt he will remove that. I don't know if it has much effect except for the nagging feeling in the back of some people's minds that they can't directly control extrusion width.

[zapta]

@Exerqtor said in PrusaSlicer with enhanced precision and removal of odd flow math:

have you ran this by Merill on github regarding merging it to SuperSlicer ?

Or the Super Slicer Plus.

BTW, if you increase the resolution in the gcode file, don't you hit the resolution limits of the printer? (discrete steps, play/backlash, etc).

[bot]

@zapta said in [PrusaSlicer with enhanced precision

[...]
BTW, if you increase the resolution in the gcode file, don't you hit the limits of the resolution of the printer? (discrete steps, play/backlash, etc).

I think even without increasing resolution, we already reach the limits of the printer. The purpose of the increased resolution is really only for testing purposes, to see if having more consistent calculations helps certain hiccups I'm seeing in certain prints.

Basically, I believe RRF and most other firmwares will calculate the extrusion rate based off the gcode. If the gcode is not providing consistent results of those calculations, due to limited precision of values (and some of the values being calculated from higher precision numbers) there may be an issue. I might be entirely wrong, but this is what I'm testing.

I don't really care about increased precison, per se, beyond 3 decimal digits for X/Y and 6 decimal digits for E. I just increased them in order to extract that higher calculated precision.

[UnderDoneSushi]

Hey bot, would this odd flow math be the cause for my problem?

When changing layer heights from 0.2mm to 0.1mm, the first layer extrusion width doesn't stay the same. For example, I have the first layer set to 275% for 0.2mm but when I change to 0.1mm I have to bump it up to 400% to get a "large" first layer. I hope that makes sense...

[bot]

Yes, that is exactly the type of thing this flow math changed.

It literally sets the width of an extrusion based on the height of the layer. If the layer height changes, the extrusion width changes.

[UnderDoneSushi]

@bot I literally was so confused when I first started using PrusaSlicer. You can clearly see the extrusion width change when you re-slice a model. I will read your entire thread and try your branch/edit of the software and report back!

[engikeneer]

@UnderDoneSushi @bot am I missing something? You can set extrusion width explicitly in mm (instead of the default % layer height) In Prusa Slicer. Not sure if that impacts the flow maths work youve been doing, but it does help regain a bit more control when slicing

edit: I stand corrected!

[bot]

@engikeneer the value you set there is not the value that is used. The extrusion width and spacing is modified to be that width minus Layer height times 1 minus PI / 4

[edit: but now I see what you're asking about engikeneer. @UnderDoneSushi if you allow slicer to automatically set the extrusion widths, it will indeed inflate the width based on the layer height no matter what. Normally, it also changes the width (to a much smaller degree) when you set the extrusion width manually, too. The latter is the only part my code changes. With my build, if you allow PrusaSlicer to auto select extrusion width, it will still be calculated over layer height with a different formula. I think it's just 1.25 * layer height or something I forget. Just to clarify! The change from 275% to 400% seems to indicate you were using auto extrusion width, not manual I missed that at first.] [Edit 2: Now that I investigate, the auto extrusion width seems to be calculated over only nozzle width, not layer height -- in latest PrusaSlicer. I think SuperSlicer differs for this behaviour.]

[theruttmeister]

@bot said in PrusaSlicer with enhanced precision and removal of odd flow math:

I know for sure he is against removing the flow math. He seemed quite angry at my first suggestion of it.

But yeah, the flow math? I doubt he will remove that. I don't know if it has much effect except for the nagging feeling in the back of some people's minds that they can't directly control extrusion width.

After going to the trouble of writing code that correctly computes the volume of extrusion... I can imagine that he doesn't want to go back to using the wrong math, no.

I don't quite understand what you are trying to achieve? Because it seems like you are re-writing Slic3r, to make it more precise, but less accurate.

[Exerqtor]

@theruttmeister
Isn't precise and accurate more or less synonyms?

EDIT: forget what i just said, googled the definisions and disproved myself ‍️

[bot]

@theruttmeister Merill (the author of SuperSlicer) did not write the code that I removed. Neither did Prusa. This is legacy Slic3r code.

The people who wrote it clearly had no intention of calling it perfect and done. In the documentation of the feature, they state such:

From Slic3r flow math:

Documenting it serves as reference and as request for comments since better models might be worth to try.

I'm trying to accomplish several things with what I'm doing to PrusaSlicer. Mainly, I'm testing different scenarios I have wondered about and am troubleshooting small errors I am seeing in prints (both small visual defects and hiccups/underruns).

I do not think I'm making anything less accurate. I understand the idea of the flow math, but I think the methodology is flawed. It is only useful at very low resolution: e.g., large layer heights. At smaller layer heights, the effect and usefulness quickly diminish.

There are many reasons I think the flow math is unnecessary and potentially detrimental, most significantly is that it is always trying to modify paths to a degree that is smaller than the baseline (noise floor) accuracy of the system. The fluctuation of the filament diameter, while small these days, is in the order of magnitude that the flow math is trying to adjust. It gets lost in noise.

Anywho... sorry to have ruffled feathers I guess?

[theruttmeister]

@bot

If no-one ever sticks their oar in and says people are doing it wrong and it should be done differently, we never get any improvement. Don't stop!

And for all my grumbling about using the correct flow math, I use Cura, which as far as I know, still just uses the simple math.

I'm going to try printing stuff with your version, to see what sort of results I get. Its many years since I last used Slic3r.

[dc42]

@bot said in PrusaSlicer with enhanced precision and removal of odd flow math:

Basically, I believe RRF and most other firmwares will calculate the extrusion rate based off the gcode. If the gcode is not providing consistent results of those calculations, due to limited precision of values (and some of the values being calculated from higher precision numbers) there may be an issue. I might be entirely wrong, but this is what I'm testing.

That is correct. I have observed in the past that when slicers generate very short moves (which may be due to bugs in the slicer), the extrusion rate often varies considerably, probably due to rounding error.

[bot]

@dc42 thank you for the clarification/confirmation.

I'm starting to get frustrated! I have the infill extrusion rate very consistent, except for some weird spots where the rate suddenly drops for one segment.

The odd thing is, it's dropping to the excact extrusion rate that was required from a previous slice in a previous build. The current settings all request a 0.2 mm extrusion width -- suddenly, it's dropping down to 0.16 mm -- the exact value I was testing before.

Something really wonky is going on. It's possible that the 0.16 mm value was present at startup, and is retained in memory somewhere and mistakenly referenced.

It causes the extrusion rate to suddenly drop by ~300 microsteps per second. Yikes!

[Edit: well, I'm an idiot. The wonky thing that was going on was that my spreadsheet was messed up. Some of the formulas -- where the odd values appear, were erased and somehow a fixed value was in its place.

I fixed it and now the extrusion rate is perfectly consistent. lol. Ooops. move along, nothing to see here!]

[Edit again to clarify: my original assertion, that increasing X/Y gcode decimal precision "completely alleviated" the extrusion rate inconsistency, was basically correct. The problem in my spreadsheet came about at approximately the same time that I implemented the increased precision change.

The end result is that my last build does indeed solve the extrusion rate inconsistency, sort of. Infill (and perhaps other non-perimeter path types) have slightly worse consistency than perimeter paths, but it's still accurate enough so that tiny 0.16 mm * 0.04 mm extrusion paths have extrusion amounts that produce extrusion rates consistent to within ~0.01 microsteps per second at 100 mm/s. Without adjusting the precision, the infill can vary by up to ~20 microsteps per second with the same settings. This is because the rounded vector, having a much different length than the precise length, due to having an absolutely tiny length to begin with, is not used to calculate the extrusion rate -- the precise vector is. I'm referring to vector here to mean the literal vector described by two subsequent G1 lines of code. The underlying math is a vector norm on the set of points before they are rounded for Gcode output.

BUT, there is a feature in solid infill to "adjust spacing to fill the space evenly," which in turn adjusts the flow for some segments of solid infill to be slightly different than other areas. I.e., it's not a fluctuation anymore, the infill (solid only?) is sometimes calculated at a slightly different flow rate. I'm experimenting with new builds that disable this feature, but now extra-large gaps are left -- where there is enough space to fit a whole extra line of infill, so I'm not keen on forcing that change in the experimental builds.]