PrusaSlicer with enhanced precision and removal of odd flow math

bot

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.

Win64 release is here on GitHub

chas2706

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".

bot

@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

chas2706

@bot Yes I have the latest version of PS already installed but it still doesn't work.

chas2706

Forgot to mention, I also already have the Microsoft 2015 redistributable update installed on my system.

bot

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?

chas2706

Windows 10 version 1909.

bot

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.

chas2706

I can only find vcruntime140.dll, windows is looking for vcruntime140_1.dll.

vcruntime140.dll is in my prusaslicer folder!

bot

Here is the copy of the DLL from my computer.

Rename this from .stl to .dll

vcruntime140_1.STL

chas2706

@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!

NickNonsense

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?

bot

That’s odd. What version of windows do you have?

bot

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->spacing

I'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.]

matt3o

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

bot

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!

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.