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

Avoid Crossing Perimeters not working as expected #1919

Closed c-born closed 10 years ago

c-born commented 10 years ago

I'm still using 0.9.10b because none of the versions since then have given me clean prints. I reported the problem in issue #1531 and it was supposed to be fixed, but it has never worked as well. I've just tried release 1.0.0 and the latest from the "stable" branch, but they are no better. I can't test with 1.1.0 because it runs for a bit and then "perl has stopped working".

Now I'm wondering if my expectations for the behaviour of "avoid crossing perimeters" might be wrong. In 0.9.10b the head does its best to stay within the object area on the layer being printed, while in later versions it often seems to jump outside the area and track around the outside. I guess this is avoiding crossing the perimeter, but it isn't what I want, as it makes much messier prints.

If "avoid crossing perimeters" doesn't mean "stay within perimeters as far as possible", as it did in 0.9.10b, can we have another option to get this functionality back?

To see what I'm getting at, the following zip has the stl and gcode generated by 0.9.10b and 1.1.0 with the same settings. (Details in the gcode). Comparing layer by layer you can see the more recent version spends a lot more time outside the object.

https://dl.dropboxusercontent.com/u/7955521/Object.7z

c-born commented 10 years ago

These images illustrate what I'm asking about, the top is the output using 1.0.0, the bottom with 0.9.10b. You can see that the more recent one doesn't do much of a job of avoiding crossing the perimeters.

image

qharley commented 10 years ago

I can confirm this. I thought that i possibly disabled that option, but after checking I found that it was still supposed to be active.

I know there were some concerns about slic3r being slow on the export in the old versions, but I think this could be elevated if the export process actually had a progress indicator for that section of the action. Seeing the software doing something is always better, and waiting for something good is better than getting something substandard quicker.

My 2c

Sent from my iPad

On 16 Apr 2014, at 1:10, c-born notifications@github.com wrote:

These images illustrate what I'm asking about, the top is the output using 1.0.0, the bottom with 0.9.10b. You can see that the more recent one doesn't do much of a job of avoiding crossing the perimeters.

[image: image]https://cloud.githubusercontent.com/assets/2059837/2714207/72b45c8a-c4f2-11e3-93c0-453f429899b7.png

— Reply to this email directly or view it on GitHubhttps://github.com/alexrj/Slic3r/issues/1919#issuecomment-40545655 .

kefir- commented 10 years ago

Check out issue #1907, do you think that would help?

c-born commented 10 years ago

@kefir- There are no islands at this level, but I tried varying CROSSING_PENALTY from its default 20 up to 200000 and down to 0 (in 1.0.0), and the higher values actually made it worse. The image below is with a value of 200000, and you can see it spends slightly more time outside the object than with the default 20.

image

ledvinap commented 10 years ago

Could you please include exported settings with reports? It does take unnecessary time to generate settings that reproduce your problem ...

c-born commented 10 years ago

@ledvinap -

https://dl.dropboxusercontent.com/u/7955521/configs.7z

c-born commented 10 years ago

Alex has confirmed via IRC that "it means exactly that whenever a travel move needs to be performed, it tries to find a path that doesn't cross perimeters too much".

So the operation, if not the intent, has changed since 0.9.10b. I'll close this issue and start another requesting the previous operation be restored, perhaps as an additional option if there is a good reason it should not be the default.