search

slic3r / Slic3r

Open Source toolpath generator for 3D printers
https://slic3r.org/
GNU Affero General Public License v3.0
3.35k stars 1.29k forks source link

Slic3r throws an _M_range_check exception causing gcode export to fail when there is a very short object. #4954

Open Poikilos opened 4 years ago

Poikilos commented 4 years ago

Describe the bug When an object is too short, such as significantly thinner than one layer, Slic3r crashes. The purpose of the short object is to arrange the printable object, because Slic3r won't let me move objects otherwise.

To Reproduce Steps to reproduce the behavior:

  1. Add any object.
  2. Add the attached 1x1x1mm cube.
  3. Select the cube.
  4. Scale to size: .15mm or less on the z axis (the issue seems to occur when the cube is less than half of the layer height, .32 in this case).
  5. Move the first object to the part of the bed where you want it to print.
  6. Export gcode.
  7. Slic3r catches an exception, such as when the progress bar is at or near the end.
    • The "Export G-code" button stays disable until the program is closed and re-opened.
    • The exception will not occur if the object is higher, such as .16mm (becomes 0.160000026226044).

3D Model and Slic3r Configuration Export Please upload a ZIP archive containing a copy of the 3D model you are seeing this bug with and a CTRL-E export of the configuration used.

Expected behavior Objects that are too short should be ignored in slicing, or perhaps counted as one layer if higher than 1/2 of 1 layer or whatever the rule is for tops of surfaces.

A possible solution to prevent the range check exception is to perform a range check for very small floats before dividing by them--such a range check could prevent exceptions that could otherwise occur due to the division producing extremely large numbers.

Screenshots The following occurs if the cube's height is 0.1mm, and the output (even the number) is identical if the cube is 0.15mm high. The large number suggests a division issue (dividing by a very small number), but the nature of it is unclear since the large number doesn't vary with these two object heights.

Caught C++ exception of type or derived from 'std::exception': vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 0) at /tmp/.mount_Slic3rAhJSUs/usr/lib/local-lib/lib/perl5/Slic3r/Print.pm line 54.

Desktop (please complete the following information):

config.ini, cube.zip

lordofhyphens commented 4 years ago

Workaround:

Turn off auto arrange and auto center.

If that doesn't do what you want, set the perimeters, top layers, bottom layers, and infill to 0 for just that object.

On Tue, Apr 7, 2020, 7:04 AM Jacob Gustafson notifications@github.com wrote:

Describe the bug When an object is too short, such as significantly thinner than one layer, Slic3r crashes. The purpose of the short object is to arrange the printable object, because Slic3r won't let me move objects otherwise.

To Reproduce Steps to reproduce the behavior:

  1. Add any object.
  2. Add the attached 1x1x1mm cube.
  3. Select the cube. Scale to size: .15mm or less on the z axis (the issue seems to occur when the cube is less than half of the layer height, .32 in this case).
  4. Move the first object to the part of the bed where you want it to print.
  5. Export gcode.

  6. Slic3r catches an exception, such as when the progress bar is at or near the end.

    • The "Export G-code" button stays disable until the program is closed and re-opened.
    • The exception will not occur if the object is higher, such as .16mm (becomes 0.160000026226044).

3D Model and Slic3r Configuration Export Please upload a ZIP archive containing a copy of the 3D model you are seeing this bug with and a CTRL-E export of the configuration used.

Expected behavior Objects that are too short should be ignored in slicing, or perhaps counted as one layer if higher than 1/2 of 1 layer or whatever the rule is for tops of surfaces.

  • The short object should also affect the adaptive layer height, so that the object prints at its exact height (if that height is at or above the minimum adaptive layer height).

A possible solution to prevent the range check exception is to perform a range check for very small floats before dividing by them--such a range check could prevent exceptions that could otherwise occur due to the division producing extremely large numbers.

Screenshots The following occurs if the cube's height is 0.1mm, and the output (even the number) is identical if the cube is 0.15mm high. The large number suggests a division issue.

Caught C++ exception of type or derived from 'std::exception': vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 0) at /tmp/.mount_Slic3rAhJSUs/usr/lib/local-lib/lib/perl5/Slic3r/Print.pm line 54.

Desktop (please complete the following information):

config.ini, cube.zip https://github.com/slic3r/Slic3r/files/4443935/config.ini.cube.zip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/slic3r/Slic3r/issues/4954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAHYCRVY2VXJKAV2EK4VJLRLMJF5ANCNFSM4MDBZQAQ .

Poikilos commented 4 years ago

@lordofhyphens Thanks, the first workaround works (Turning off "Auto-center" was enough--I prefer to keep the other setting, "Auto-align parts (z=0)" checked, and it does not interfere.). Also, I'll keep the second workaround regarding settings in mind for the future.

The crash and request to match the adaptive layer height to a thin object still remain, of course. Fixing that main issue would assist people making gaskets, stencils, and other things.