-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slic3r freezes during the brim calculation #4654
Comments
Traceback:
Interesting, the coordinate is strongly negative. |
The negative coordinate isn't anything interesting. However, the spacing is, in this case, 0. I'm not sure why currently. |
the stl is generated in freecad, i can post the project file tomorrow if it can help debugging |
@hariseldon78 no, the model as posted is enough to trigger the crash and I found at least one of the pieces. So it looks like the trigger was the 125% first layer setting. That, plus the brim connections, is causing the brim code to bug out and try to produce a 0 spacing path (which is normally illegal). We have some asserts in the code but they aren't triggering in this situation (and I'm not sure why right now). |
@hariseldon78 With that model, a current workaround is to either set the brim connections to 0mm or set the first layer width to 200% (the default). There's something going on with I think the flow code (remember, % width is relative to the layer height) that when Slic3r is trying to place that brim connector, the spacing is 0. The spacing value (which is the width-to-width) is being set incorrectly with that brim connection with and the math happens to work out that it comes out to be 0 on that model and a line width of ~0.5mm. |
Well, I know why it's tripping the assert: the build didn't have SLIC3R_DEBUG set, which automatically turns off asserts. |
…ed a regression test to ensure that the spacing can't be 0 with otherwise valid inputs.
@hariseldon78 in about 30-40 minutes you can check https://dl.slic3r.org/dev/linux/branches/ for a build of PR4662 that should sort out the crash. Please let me know if it fixes it for you (it does when I was testing it with your provided config and model). What was happening is that even with the 0.5 fudge factor, with a 125% and 0.4 first layer height it happens to not reach the threshold for the math and gets rounded down to 0; 0 spacing breaks almost all of the assumptions in the slicer. I've patched a backup approach into the flow calculation that tries to choose an "okay" flow calculation in these situations (which I'm fairly certain only occur with brims). |
I confirm that this build slices correctly with 2mm brim, 1mm brim connections, 125% first layer thickness and 0.4mm first layer height. Thanks for the very quick fix, and happy new year! |
…ed a regression test to ensure that the spacing can't be 0 with otherwise valid inputs.
Fixing model import of models with nearly degenerate triangles, which degenerate after transformation (translation or rotation). There was certainly a bug in PrusaSlicer, however this bug was triggered mostly by the ASCII STL files generated by OpenSCAD, likely due to insufficient number of decimal digits when saving an ASCII STL, see [openscad/openscad] STL export should contain single precision floats (#2651)
Describe the bug
Slic3r freezes during the brim calculation of this model:
pulley.zip
, and the interface become irresponsive, even after cancelling the calculation. It happens with the object non rotated or rotated 90 on x axis. It slices fine without brim.
To Reproduce
Steps to reproduce the behavior:
3D Model and Slic3r Configuration Export
config.zip
pulley.zip
Expected behavior
correct slicing, the model is manifold and I didn't find any problem with it.
Desktop (please complete the following information):
Linux (Linux 4.15.0-43-generic Infill gets sparse when it's not printed every layer #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux)
Version 1.3.0
The text was updated successfully, but these errors were encountered: