PrusaSlicer with enhanced precision and removal of odd flow math
-
Oh hey, I should have pointed out that this is the alpha version of PrusaSlicer. So, it has all the fancy new features like collapsible sidebar, paintable support structures, shiny environment reflection in plater and preview window (lol it's cool!), the ability to UNDOCK the settings tabs, etc..
(Note: the SLA support icon is a placeholder for the paintable supports -- these are very much FDM supports.) -
I just made a breakthrough! I've been chasing my tail trying to fix the inconsistency in the extrusion rate produced by the E values in combination with the X/Y values in GCode.
I spent weeks debugging, tracing values, determining that everything was working basically perfectly. What was going wrong!?!?
The X/Y vectors were being rounded AFTER the calculation of extrusion amount. Therefore, the calculated extrusion amounts were no longer valid. Funnily enough, the fact that there was excess precision to begin with WAS the problem. The solution, for this build, is simply to increase the X/Y GCode decimal precision to 6 places. Now, by far, the most consistent extrusion rates I've seen! No more random infill segments with sudden rising extrusion rates.
-
Just downloaded your latest version and it does not work.
When I go to open it Windows comes up with error message "VCRUNTIME 140_1.dll not found".
-
@chas2706 My bad, sorry. It's probably something in a Visual Studio C++ Redistributable package.
Do you have PrusaSlicer installed already on your computer? If not, try installing the latest version of PS from their install package, and hopefully it installs any dependencies which are not included in my zip package.
Edit: I think this should fix it for that file: https://www.microsoft.com/en-us/download/details.aspx?id=52685
-
@bot Yes I have the latest version of PS already installed but it still doesn't work.
-
Forgot to mention, I also already have the Microsoft 2015 redistributable update installed on my system.
-
I wish I could help more but I do not have any idea why there is an issue.
What version of windows are you using?
-
Windows 10 version 1909.
-
I just tested on my laptop with Windows 1903 and it worked. Can you try just putting that file into the directory? Search your computer for the missing dll file and drop it into the directory if you find it.
-
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).
