PrusaSlicer with enhanced precision and removal of odd flow math
-
I can only find vcruntime140.dll, windows is looking for vcruntime140_1.dll.
vcruntime140.dll is in my prusaslicer folder!
-
-
@bot said in PrusaSlicer with enhanced precision and removal of odd flow math:
Here is the copy of the DLL from my computer.
Cheers, it is now working!
-
Weird but when i open "prusa-slicer.exe" it opens but hangs immediately. As soon as i try and click anything i have a (Not Responding) error.
Anyone else have this issue?
-
That’s odd. What version of windows do you have?
-
Okay, so I might have got ahead of myself when I said increasing the X/Y precision of GCode decimal output "completely alleviated" the inconsistent extrusion rate. It did that for many of the paths, especially the perimeters. However, parts of the infill are still erroneously inconsistent (to a fairly small degree).
So, I will seek to fix this. All of the different types of infill, and infill in general, have their own sections of code which seem to mess about with the flow rate and spacing as they see fit.
// calculate actual flow from spacing (which might have been adjusted by the infill // pattern generator) //[...] // if we used the internal flow we're not doing a solid infill // so we can safely ignore the slight variation that might have // been applied to f->spacingI'll need to go through them all and see how I can ensure the same consistency in the flow rate calculation as the other paths.
[Edit: well, I got ahead of myself again! The error was in my spreadsheet, not the infill output! The infill extrusion rates are not quite as consistent as the perimeters, but they are definitely close enough! Teaches me to debug using manual calculations and crude spreadsheets rather than unit tests.]
-
this is very interesting, following this thread.
I'll have a look at your code soon and possibly compile it on Linux.
Keep up with the good work
-
Cool! Let me know how it goes with Linux. I've only tested this on Windows. There shouldn't be any changes that would interfere with a linux build, but who knows!
-
@bot have you ran this by Merill on github regarding merging it to SuperSlicer ?
-
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.
*not actually a robot
-
@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).
-
@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.
*not actually a robot
-
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...
-
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.
-
@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!
-
@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!
-
@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.]
-
@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.
Isolate, substitute, verify.
-
@theruttmeister
Isn't precise and accurate more or less synonyms?
EDIT: forget what i just said, googled the definisions and disproved myself
️
-
@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?
