PrusaSlicer with enhanced precision and removal of odd flow math

bot · 8 Mar 2020, 16:49

I just finished modifying PrusaSlicer to have more precision and remove some silly flow math that was just adding noise to the GCode. Check it out, let me know what you think!

The main benefits are that toolpaths won't be simplified as much, which results in the complete elimination of misaligned ~~layers~~ segments, E values in GCode will be output to 6 decimal digits of precision instead of 5, and the aforementioned removal of Slic3r flow math.

[Edit: Update! Fixed extrusion rate inconsistency in latest version, link below updated to newest release. See my post here.]

Release (Win64 binaries only, sorry) (updated link to fix for changed tag/updated release)

Github Repo (default branch).

droftarts · 23 Jul 2020, 21:05

@bot Do you think they're likely to pull your changes into the official version?

Ian

fcwilt · 23 Jul 2020, 21:14

Hi,

I'm not familiar with github.

I don't see any installation files, either .EXE or .MSI.

Thanks.

Frederick

A Former User · 23 Jul 2020, 21:17

the releases page is usually the best bet (op probaby posted the wrong link?)

https://github.com/n8bot/PrusaSlicer/releases the link on the front lage is sort of inconspicious hidden to the right under the "about" section.

bot · 23 Jul 2020, 21:56

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

the releases page is usually the best bet (op probaby posted the wrong link?)

https://github.com/n8bot/PrusaSlicer/releases the link on the front lage is sort of inconspicious hidden to the right under the "about" section.

Oops, yeah. I posted the correct link, but then modified the release. I didn't know it would break the link. Silly ~~GitHub~~ me. Silly me. I linked to the TAG, then changed the tag!! I updated the two releases I have last night to include the latest fixes from Prusa3d/master.

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

@bot Do you think they're likely to pull your changes into the official version?

Ian

Hmm, probably not. The only changes they might consider would be the changing of RESOLUTION and E_NUM, for increased resolution/precision.

The removal of the flow/spacing math seems like a contentious issue among Slic3r purists. It seems this flow math was the element of Slic3r that everyone was most proud of -- yet it might have been one of the single worst additions to the software ever. So, it's doubtful that it would be merged. Then again, they aren't Slic3r's original devs, so they might not be so attached to the "very smart" needless math complications. I don't even know how aware they are of these releases.

Also, the way I removed it was VERY crude. A better approach would be to refactor all the different places that asked for that math, because there are remnants that are redundant now. I.e., areas where it used to say something like flow.width = float(w) - flow.height * (1 - PI / 4) now say only flow.width = float(w), which is likely setting flow.width to an approximation of the value that it already is. I don't know enough about the codebase to know how to refactor it, though.

bot · 23 Jul 2020, 22:50

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

bot · 3 Aug 2020, 16:38

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 · 3 Aug 2020, 18:28

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 · 8 Mar 2020, 18:33

@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 · 3 Aug 2020, 18:34

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

chas2706 · 3 Aug 2020, 18:36

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

bot · 3 Aug 2020, 18:40

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 · 3 Aug 2020, 18:43

Windows 10 version 1909.

bot · 3 Aug 2020, 18:50

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 · 3 Aug 2020, 19:07

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

vcruntime140.dll is in my prusaslicer folder!

bot · 3 Aug 2020, 19:30

Here is the copy of the DLL from my computer.

Rename this from .stl to .dll

vcruntime140_1.STL

chas2706 · 3 Aug 2020, 20:26

@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 · 3 Aug 2020, 21:26

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 · 3 Aug 2020, 22:06

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

bot · 5 Aug 2020, 14:16

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