Zig-Zag'ing bug again.. :(

[AndersE]

I got this weird zigzaging again today. I can't see anything in the preview as to why it does it. In the preview there is no visible "dotting" as it does.
This bug makes it take MUCH longer to print. And it gets UGLY.

The wheel : After the top 3 layers in the middle, when it begins to print the edge, it starts.
Seems to be an infill gone bad. In two edges it seems to do a normal infill or something.

I attach factoryfile (running on k8200)

(i have 2 processes, the first is the wheel).

I have sliced and printed it once before without problems (single object on table).

[AndersE]

Same zig-zag'ing in 2.1.1 which makes it take forever to print. About 70% into print it starts.

It is just dotting back and forth.. instead of doing it one whole side and then going to the next side, which would make shorter movements and quicker to print..

[jimc]

anders, i downloaded your factory file and took a real close look at what was going on. the first problem is that you are printing the gear twice in the same point in space. in that factory file you have 2 processes. you have both processes applied to the same model of that gear. goto the bottom of the process panel and hit the select models button and sort out which process needs to be applied to which model. ok that takes care of about 50% of the jumps however they are still there. what is going on with the gear and all the jumps is your extrusion width is at this perfect width where its just a hair narrow and leaving microscopic gaps that s3d sees as needing infill so its jumping all over infilling all these spots. take that gt2-120 gear and turn your width to manual and change it from .48 to .49 and watch what happens in the preview.

usually when you see a ton of rapids on something like your gear that has many repeating areas this is whats happening and can all be adjusted with your extrusion width. my extrusion width is always set on manual and i adjust it for each model so widths and gaps are all correct.

there is a setting for minimum infill length that is supposed to stop that but i have never seen that work or have any function in any of the s3d versions since i have been using it which has been since 1.1.5, they really should fix that BUT for nice strong and correctly printed model the best way is to tweak the width for the model itself so you dont end up with gaps anywhere.

[AndersE]

Then there is a bug in the save process, because i had only the gear in the first process and the 2 other objects in the second.

But even if only run one process and the gear single it does the same thing more or less even if i try different extrusion witdhs.

Why trying to infill anyway in this case? In other cases where i thought it would do infill it does not.

Look at my other example. I try different extrusionwidths with same result. zig-zag when printing. It does not seem to be so smart about in which order to print things.
I think it would be smarter to print all flanges on one side, then moving to the next side and print the rest instead of zig-zag'in on every layer.

Nope, minimum infill lenght does still now work it seems in 2.1.1

[AndersE]

I have done some more testing now, and when it start to xig-zag, i look at the preview and just look at only the layer it is printing. Even looking at just the line it is supposed to print.
It prints NOTHING in the places it jumps to. Nothing visible in the preview either.
By looking at the layers there is NO reason to do any plotting.

This bug makes my extruder run out of filament, and that is because:
I have 4mm retraction and -0.20 restart. This makes the filament going back a little every retraction, and when it does this much retractions i go out of filament.

Test my code... and look at when it starts to print the cogs in the upper part.

I get failed prints every time this happens.

[AndersE]

Hmm, i renderd the code again, and this time it shows tiny dots where it zig-zags.. a bug in the rendering code? or the gcode generator?

[jimc]

it prints nothing in the places it jumps to because the length it needs to print is less than your coast and restart value. really its jumping to do the infill between each tooth and thats alot of teeth lol. coasting and a neg restart distance is great but when you have a model with alot of small detailed areas like this it doesnt work because the nozzle never reaches any kind of normal pressure and filament doesnt get extruded. anytime i print something with alot of detailed areas i always turn those off or down as much as possible. so in the case of this gear model, here is what i would do. print this with 2 processes. use your current process up to the top layer of the outer gear teeth. make a second process for the rest using 1 shell or perimeter and 100% infill. turn the coast and restart down as minimal as you can. if the top is printed with 1 shell and 100% infill then you get next to no jumping. again, with 2-3 shells those areas between the teeth are so small to infill its going to cause you issues. those little areas between the gear teeth are killing you. 1 shell makes them bigger

[AndersE]

Hmm ok, i will try that. But isn't this to be considered a bug or lack of function in the sw?
I should not have to check or think about this everytime i want to print something with details.

Some inbuilt warning that this will happen?

Next q: WHERE do i set which layers should be printed by which process??

Don't bother, i found it on the homepage how to do it.
But even if i set no retractions and single perimeter on second process it zig zags..

But if i use the second process (delete the first) then there is no zigzaging..

[jimc]

really its not a bug. its actually just that the part has a ton of repeating, identical small areas like that. that gear in general with the design of it just needs extra care as far as making a process correct for it. no matter what slicer you use those tiny areas will need an infill so the extruder is going to have to jump from one to the other.

[AndersE]

I dont mind the small infills, just the way it's done. Why go from one side to the oppsite?
Why not go clock or antiklockwise instead?