prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.65k stars 1.92k forks source link

Invalid spacing supplied to Flow::with_spacing() #7335

Open ss89 opened 2 years ago

ss89 commented 2 years ago

Version

2.4.0 beta 1 (bad) 2.4.0 alpha 3 (bad) 2.4.0 alpha 2 (bad) 2.4.0 alpha 1 (bad) 2.3.3 (works)

Operating system type + version

MacOS 12.0.1 (Apple M1 Max)

3D printer brand / version + firmware version (if known)

Ender-3 Marlin Firmware (https://git.x2d2.de/3D-Printing/Marlin-Firmware/-/commits/ender-3-2.0.9.2-skr-e3-dip)

Behavior

Brigintine_New_Jersey_Outdoor_SailboatSculpture-_shortened_with_pedestal.zip

Expected Result: File gets sliced and output visible in preview

Actual Result: File gets sliced partially and spits out "Invalid spacing supplied to Flow::with_spacing()" (stuck at filling layers) and only perimeters seem sliced

Is this a new feature request? No

Project File (.3MF) where problem occurs

Here's the project file which contains my settings (priorly used and imported from PrusaSlicer 2.3.3). SailboatSculpture-shortened_with_pedestal.3mf.zip

cloud30000 commented 2 years ago

I can confirm this issue occurs in the attached 3mf file when the nozzle is set to 0.4mm but all extrusion widths are set to 0.2mm.

If I set the Extrusion Width above 0.279mm, the issue no longer occurs.

There seems to be some internal conflict with an extrusion width set below 0.28mm and a 0.4mm nozzle; if the extrusion width is intended to be unsupported at that width, then a dialog or notification should instead be displayed when the conflicting value is entered into the extrusion width fields.

bubnikv commented 2 years ago

Extrusions with height higher than width are considered non-printable. This project has an excessive first layer height (0.28mm) versus narrow extrusion lines (0.2mm).

We shall improve the error reporting.

ss89 commented 2 years ago

As a developer i do see that you need to know about this issue, but as a user i don't see any value of reporting this. As a slicer user i would assume unprintable extrusions aren't done at all - as i assume the 2.3.3 version is behaving. If this helps, maybe you can ask the user for project file submission if this happens in a non-GA-release version?

bubnikv commented 2 years ago

As a slicer user i would assume unprintable extrusions aren't done at all

I am not sure that would be a good solution. Missing extrusions without any warning would just cause another crop of issues.

as i assume the 2.3.3 version is behaving.

I don't think anything changed here. The only thing changed is the "thick bridges" checkbox, enabled by default to match the 2.3.3 behavior.

If this helps, maybe you can ask the user for project file submission if this happens in a non-GA-release version?

You mean in the error box?

I personally think that improving the diagnostics would help a lot, explaining which type of extrusion with which parameters cannot be extruded and why. I was sitting on my hands yesterday to not implement it for 2.4 as we need to release and I don't want to break anything.

ss89 commented 2 years ago

I don't think anything changed here. The only thing changed is the "thick bridges" checkbox, enabled by default to match the 2.3.3 behavior.

That is where you are wrong šŸ™ˆ Have you tried it with both versions? 2.4.0 gives me just the outer shell and that's it. 2.3.3 is giving me the whole model sliced.

You mean in the error box?

Either that or as a program setting that gets asked for when you start the slicer the first time (ask for automatic error submission permission).

I personally think that improving the diagnostics would help a lot, explaining which type of extrusion with which parameters cannot be extruded and why.

Agreed :-) šŸ‘

bubnikv commented 2 years ago

Either that or as a program setting that gets asked for when you start the slicer the first time (ask for automatic error submission permission).

Some extrusion path parameters may not be known until the slicing process runs.

bubnikv commented 2 years ago

You are right PrusaSlicer 2.3.3 sliced your model without any complaints.

I have also verified that we have a check before slicing for the extrusion width vs. layer height ratio, but not for the first layer height. If I copy your excessive first layer height to layer height, I get the following error at the start of slicing. We should duplicate this logic for the 1st layer height as well.

image

ss89 commented 2 years ago

Either that or as a program setting that gets asked for when you start the slicer the first time (ask for automatic error submission permission).

Some extrusion path parameters may not be known until the slicing process runs.

I mean more something like a dialog when the app starts.

"[x]You are using an alpha/beta version of $ProductName, would you agree to share error reports with us as they occur?"

That being asked once when that slicer version starts the first time would be good, i think. A) The user would know that they (accidentally?) downloaded a non-release version. B) The user is helping the devs to fix issues that the devs might not have been aware of. C) Because it is opt-in, the user can keep his privacy if they want to.

ss89 commented 2 years ago

You are right PrusaSlicer 2.3.3 sliced your model without any complaints.

I have also verified that we have a check before slicing for the extrusion width vs. layer height ratio, but not for the first layer height. If I copy your excessive first layer height to layer height, I get the following error at the start of slicing. We should duplicate this logic for the 1st layer height as well.

image

With looking at your attached picture, i realize that the extrusion width should be 0.4-0.45. i will check the project file once i get back to my pc.

ss89 commented 2 years ago

Ok, yeah i just realized that i had chosen the wrong print profile and that caused an issue. Might also have gotten confused with similar filenames. Eventually that resulted in finding this interesting quirk.

@bubnikv should i close this issue or do you want to keep it open for the suggested features?

d-divita commented 2 years ago

I've run into this issue also on version 2.4.1 stable (Windows 10)

akash1769 commented 2 years ago

And I just did too in 2.4.2. Accidentally set layer height to 1.5 instead of .15. From then on the error came up even after changing the layer height correctly. Had to close that instance of Slicer to continue forward

bj97301 commented 2 years ago

I just got this to happen when using adaptive layer heights and switching settings from another printer. Suggestion, ask to remove adaptive layer settings when changing or to reapply settings.

d-divita commented 2 years ago

I still get the error on 2.5.0-rc1, both on Ubuntu and Windows.

risototh commented 1 year ago

Getting this error with the 2.5.0+MacOS-x64. I have 0.4 nozzle, 0.24 layer height (0.3 first layer height), and width 0.46. It will not generate the infill and skirt. Any idea, what's wrong?

antalkrisz commented 1 year ago

Same here as ss89 wrote in the first comment. Prusaslicer 2.5.0+MacOS 10.15.7 Intel CPU Solution: I switched to "mm" instead of "%" by Extrusion width...

ovelux commented 1 year ago

i come back to say that in 2.6.0-alpha4+win64 that this issue still persists, will try to set all parameters to % or mm/s

CobraA1 commented 1 year ago

This can still happen with variable layer height, when the saved heights do not match the current settings. Would like to see a proper error message nudging the user in the right direction, rather than a cryptic error message that is not helpful.

theLEDwheel commented 11 months ago

Ok I know this is fairly old and CobraA1 stated the same issue and resolve but I ran into this issue today, It turns out that the variable layer height was interfering with the ironing settings. I guess variable layers and ironing are not compatible.