-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Comments
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. |
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. |
Thanks. We will likely need to fix the "Avoid perimeters" feature for our
multi-material bowden setup.
…On Mon, May 8, 2017 at 3:41 PM, BirkBinnard ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#287 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I0DcJ3Wl_0IbW8UJ0WZtclTFrjCxks5r3xuZgaJpZM4NS4zj>
.
|
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. |
I am certainly interested to hear where the competition failed :-)
I know the single extruder multi-material setup is tricky and I will
appreciate, if you share your experience with us.
…On Mon, May 8, 2017 at 3:54 PM, BirkBinnard ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#287 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFj5Iycg8fnNuBY140D_jcNFpKaSFc_aks5r3x6cgaJpZM4NS4zj>
.
|
Take a look at this - I just found it: 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:
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. |
Thanks, Birk for your findings. They reflect our experience and we are
developing methods to fight these issues. Our Multi Material is currently
at a group of beta testers and the first batch of pre-orders will be
shipped soon.
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.
Would you please share your design? How did you affix the teflon tube? I
know it is tricky as teflon is slippery.
Thanks,
Vojtech
…On Mon, May 8, 2017 at 4:48 PM, BirkBinnard ***@***.***> wrote:
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, #2
<#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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#287 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I7XGyf9QFXDqwgREjcUIBvS2uqDNks5r3ytEgaJpZM4NS4zj>
.
|
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 |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: