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

Slicing stops at trivial STL, C++ exception of type #2537

Closed
Patola opened this Issue Jan 13, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@Patola

Patola commented Jan 13, 2015

When I try to slice even the simplest STLs, slic3r stops the slicing with this message:

Caugh C++ exception of type or derived from 'std::exception': vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 25) at /dados

@Patola

This comment has been minimized.

Show comment
Hide comment
@Patola

Patola Jan 13, 2015

Please tell me how I can add any further debug information.

Patola commented Jan 13, 2015

Please tell me how I can add any further debug information.

@lordofhyphens

This comment has been minimized.

Show comment
Hide comment
@lordofhyphens

lordofhyphens Jan 13, 2015

Member

Well, you could run "gdb perl /path/to/corefile" and then type "back" to get the backtrace. It might be useful if you compiled from source.

Of course, you'd need gdb installed (which is the packaged gdb on debian and ubuntu).

Member

lordofhyphens commented Jan 13, 2015

Well, you could run "gdb perl /path/to/corefile" and then type "back" to get the backtrace. It might be useful if you compiled from source.

Of course, you'd need gdb installed (which is the packaged gdb on debian and ubuntu).

@Patola

This comment has been minimized.

Show comment
Hide comment
@Patola

Patola Jan 13, 2015

It is not dumping core, it is showing the message on the bottom window border...

Patola commented Jan 13, 2015

It is not dumping core, it is showing the message on the bottom window border...

@Patola

This comment has been minimized.

Show comment
Hide comment
@Patola

Patola commented Jan 13, 2015

slic3r_203

@Patola

This comment has been minimized.

Show comment
Hide comment
@Patola

Patola Jan 13, 2015

I even found out a way to avoid this problem. I don't know how, but using my settings:

  • Select Graber i3 for print settings and Graber i3 for Printer.
  • Let is slice and finish.
  • Select Sethi3D_no_support for print settings and Sethi3D_Printer_Settings for printer.

Voilà. I don't know why but the slicing error stops. From now on, every stl is sliced correctly.

Using diff to compare the settings:
print settings -
most notable differences between sethi3d (1) and graber i3 (2):

  • (1) no support, (2) with support
  • (1) seam position random, (2) neareest

Others are numeric differences which I reckon are not likely to be the cause.

For printer settings:
Sethi3D has these codes, graber i3 does not:
octoprint_apikey =
octoprint_host =
pressure_advance = 0

Patola commented Jan 13, 2015

I even found out a way to avoid this problem. I don't know how, but using my settings:

  • Select Graber i3 for print settings and Graber i3 for Printer.
  • Let is slice and finish.
  • Select Sethi3D_no_support for print settings and Sethi3D_Printer_Settings for printer.

Voilà. I don't know why but the slicing error stops. From now on, every stl is sliced correctly.

Using diff to compare the settings:
print settings -
most notable differences between sethi3d (1) and graber i3 (2):

  • (1) no support, (2) with support
  • (1) seam position random, (2) neareest

Others are numeric differences which I reckon are not likely to be the cause.

For printer settings:
Sethi3D has these codes, graber i3 does not:
octoprint_apikey =
octoprint_host =
pressure_advance = 0

@alexrj alexrj added this to the 1.2.6 milestone Jan 13, 2015

@alexrj

This comment has been minimized.

Show comment
Hide comment
@alexrj

alexrj Jan 18, 2015

Member

Thank you, I was able to reproduce and fix this. It was caused by skirts being > 0 but skirt_height being 0. I also included a regression test.

Member

alexrj commented Jan 18, 2015

Thank you, I was able to reproduce and fix this. It was caused by skirts being > 0 but skirt_height being 0. I also included a regression test.

@alexrj alexrj closed this Jan 18, 2015

@alexrj alexrj added the Fixed label Jan 18, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment