"complete individual objects" freezes slic3r

[Tinchus2009]

Version

1.3 DEV (latest) but git describe --tag gives me this: 1.2.9-364-g3700950, is this ok?

Use About->About Slic3r for release versions

For -dev versions, use git describe --tag or get the hash value for the version you downloaded or git rev-parse HEAD

Operating system type + version

Win 10 64b

Behavior

• Describe the problem

It happens a lot of time to me, not only with the 2 object I uploaded as example. When I try to use this option, slic3r freezes. My guess is that is not handling the situation of not being able to print those object in secuence, and instead of showing a warning, it freezes.

• Steps needed to reproduce the problem
  I load activation_plate.stl and place it on the back of the ronting plate, then I load base.stl and right there slic3r freezes.
  • If this is a command-line slicing issue, include the options used
• Expected Results
• Actual Results
  • Screenshots from Slic3r preview are preferred

Is this a new feature request?
No
Documents.zip

STL/Config (.ZIP) where problem occurs

Upload a zipped copy of an STL and your config (File -> Export Config)

[lordofhyphens]

Can you disable background slicing and see if it still freezes for you?

[Tinchus2009]

Yes!!!! Disableing background slicing produces no freezing. So the
solution would be disable background slicing.

Works for me :)

El 20/09/2016 a las 10:31 a.m., Joseph Lenox escribió:

Can you disable background slicing and see if it still freezes for you?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3499 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANox0o5Sla_zDS0LF6GuZuUXGSI5mrrcks5qr-AhgaJpZM4J35mW.

[Tinchus2009]

This leads me to a question I coudnt find in documentation: If I disable
background slicing, once Im ready to slice, is there any way to see the
simlation as always or I need to export the gcode in order to see the
sliced simulation?

El 20/09/2016 a las 10:31 a.m., Joseph Lenox escribió:

Can you disable background slicing and see if it still freezes for you?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3499 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANox0o5Sla_zDS0LF6GuZuUXGSI5mrrcks5qr-AhgaJpZM4J35mW.

[lordofhyphens]

I have a branch for that :) See #3501

[lordofhyphens]

The root cause probably has something to do with starting/stopping the worker threads on plating change. Still something that probably needs to be fixed though.

I haven't tried to reproduce your issue locally yet (no time -.-), but I knew that there's all sorts of scheduling 'fun' around the background processing.

Personally, I think that background processing should default to OFF with my PR in place.

[bubnikv]

From my point of view (limited development resources), I would fix the
thread starting / stopping once I have all the Slic3r computing core
switched to C++, then I would get rid of the perl threads.

On Tue, Sep 20, 2016 at 7:10 PM, Joseph Lenox [email protected]
wrote:

The root cause probably has something to do with starting/stopping the
worker threads on plating change. Still something that probably needs to be
fixed though.

I haven't tried to reproduce your issue locally yet (no time -.-), but I
knew that there's all sorts of scheduling 'fun' around the background
processing.

Personally, I think that background processing should default to OFF with
my PR in place.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3499 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5IzO3744qT-_a2R4IHubVZUtBblXTks5qsBOCgaJpZM4J35mW
.

[alranel]

Background processing is now disabled by default. I'm closing this one as we are aware of some instability with it, and the porting work is ongoing.