Skip to content
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

"Avoid perimeters" extremely slow. Sicing completes OK but GCode never saves. #287

Closed
BirkBinnard opened this issue May 6, 2017 · 10 comments

Comments

@BirkBinnard
Copy link

Running Ver. 1.34.1.3-prusa3d-win64 on Win10-64 Creator Update. i7 CPU with 16 GB RAM.
STL file loads & slices OK, but slic3r loops when trying to export GCode. Attached ZIP file contains INI & STL file.

bbinnard.zip

I tried fixing STL, slicing with/without variable layers, and got same result. All layers look OK in Preview mode, lamp2.gcode.tmp gets created ok, but program never ends after Export Gcode and when cancelled the gcode file is empty.

@bubnikv
Copy link
Collaborator

bubnikv commented May 8, 2017

You have the "Avoid perimeters" feature enabled, which is extremely computationally intensive. With the feature disabled, Slic3r exports the G-code just fine.

I am currently looking into the feature. I patched some of the pot holes (rewrote the shortest path algorithm to use an optimized Dijkstra algorithm, added some bounding box tests to accelerate things). I will try this patched code with your data, let's hope for the best. Anyway, the "Avoid perimters" feature does not work very well and it is ripe for rewrite, with the inspiration of Cura.

@BirkBinnard
Copy link
Author

BirkBinnard commented May 8, 2017

AHA! You are correct - many thanks. I turned off that parameter and sliced a newer version of the STL I sent you and it saved the GCode A-OK. What a relief. I really appreciate you taking the time to figure this out and I am happy I could provide a good test case for you to use.

I guess you can mark this one closed for now; here's hoping the new code works the way you want.

@bubnikv
Copy link
Collaborator

bubnikv commented May 8, 2017 via email

@BirkBinnard
Copy link
Author

I was a beta-tester for dual extruder/single nozzle printing for my printer manufacturer (I have an Atom 2, which is a pretty high quality delta machine) and I know a fair amount about how this type of system works. I finally came to the conclusion that to reliably print 2 or more colors/filaments you need a separate nozzle for each one. I'd be happy to share my experiences if you wish.

@bubnikv
Copy link
Collaborator

bubnikv commented May 8, 2017 via email

@BirkBinnard
Copy link
Author

Take a look at this - I just found it:
https://3dprint.com/74984/autodesk-patent-multi-color/

The fundamental problem with multi extruder/single nozzle is clogs just above the hotend heat chamber. This happens because, in order to switch filaments with a single nozzle, you have to retract one and feed another. There are 2 problems with this:

  1. Figuring out the length and speed of filament to retract and feed is a trial and error process. The actual length to retract/feed can change with a given printer setup due to changes in filament viscosity, hotend temperature, and filament type. Even after you have figured out what length and speed works for a given setup, 'only overhang layer has more than one speed' test failed #2 is a problem for which I think no valid solution yet exists.

  2. Because of the viscosity melted filament has there is always a thin strand of melted filament left behind when you completely retract one filament before feeding the other. With a large print that takes many hours to print this results in a buildup inside the hotend just above the melt zone that ends up cause a hotend jam. Needless to say this stops the print(even though the printer keeps printing) and also jams the hotend in a way that is difficult to clear. (What I did was disassemble the hotend and use a propane torch to heat the nozzle to the point of vaporizing everything inside it.)

There are other problems too: In a Bowden printer you have to find a way to attach 2 (or more) PTFE tubes to the end effector. This means there will be a curved path the filament has to take to get to the hotend. If the hotend assembly uses standard quick connectors to secure the Bowden tubes to the hotend, it turns out the small notches put into the filament by the extruder gear can get caught on the inside fingers of the quick connectors and stop either/both feeding and retraction.

My printer mfg. (and me too) went through several designs of "Y connectors" before finally settling on one that did not use any quick connectors at all.

Finally, there is the issue of just how the slicing program expects to find the whole filament/hotend configured when it first starts. Which filament is actually in the hotend and ready for printing? How far away from the hotend is the other filament? If the filaments are different, is there a way to deal with different nozzle temperatures, prime/retract speeds, etc.?

I hope this info is helpful - feel free to let me know if you have any questions or comments.

@bubnikv
Copy link
Collaborator

bubnikv commented May 8, 2017 via email

@bubnikv bubnikv changed the title Sicing completes OK but GCode never saves "Avoid perimeters" extremely slow. Sicing completes OK but GCode never saves. May 12, 2017
@DominikPalo
Copy link

I don't really understand why the "Avoid perimeters" option affects only exporting of the G-code, not the slicing process. As I know, all algorithms are applied during the slicing process - to generate a realistic preview, or are traces in the preview mode somehow simplified, e.g. "Avoid perimeters" is not applied? Also, why this problem occurs only in Prusa Edition, not in the original Slic3r? Could you please explain it a little bit? There should be some in-app warning (that it can cause extremely slow exports on complex models) on that feature until it will be fixed. Thanks

@spiff123
Copy link

Got this one today - simply try a OmNom printed 6 times - slice it and wait until it gets exported - takes very long time and printed says file is incomplete - as the print looks good in preview i try to print this... keep the fingers crossed ;-)

Would be nice to get this one fixed.

wavexx pushed a commit to wavexx/PrusaSlicer that referenced this issue Sep 21, 2020
wavexx pushed a commit to wavexx/PrusaSlicer that referenced this issue Sep 21, 2020
@rtyr
Copy link
Collaborator

rtyr commented Mar 14, 2022

I believe this issue can be closed, "avoid crossing perimeters" feature was completely reworked and I don't have any issues slicing provided data with current 2.4.1.

@rtyr rtyr closed this as completed Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants