PrusaSlicer with enhanced precision and removal of odd flow math

droftarts

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

Ian

fcwilt

Hi,

I'm not familiar with github.

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

Thanks.

Frederick

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

@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

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

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