Ricky

I don't see such option in 15.04 UI. Perhaps I should add that UI code. In any case, thanks for your advice!

I posted a question in Cura Github issue. https://github.com/Ultimaker/CuraEngine/issues/790 I apologized to post it twice. Because I don't know where is the place to ask the question.

When you say the print result is the same, does the z-seam problem is gone? If possible, could you share GCode of latest Cura and 15.04. Thanks!

@mastory Thanks for your explanation. That make much sense now. Filament acts like spring. Thus the time lag. But the pressure might be the same between these two. So back to my coasting problem in Cura (might be a little bit off-topic, pardon me),it is the timing difference between direct style and Bowden style during stop extrusion earlier in coasting. However the coasting setting parameters in Cura only exposed the coasting volume and print speed during coasting. It doesn't seem to capture the crux of the problem which is the time of controlling melted filament movement.

I got the part direct style cause the momentum of moving part (hot end and nozzle) higher due to the fact that the extruder add more mass. Thus, direct style is no good for controlling the whole part for motion compared to Bowden style. But the pressure part is still not clear to me. The only difference between Bowden style and direct style is the distance between extruder and hot end. Let's imagine this: you try to push a 100 meter long train (Bowden style) vs 1 meter long train (direct style) into a tunnel (hot end). Assuming the mass of the train (the mass of filament) is not a big factor, the force that you exert (the pressure built up in the nozzle) to make your train (filament) to pass through tunnel (hot end) should NOT be any dramatic difference. There might a time lag. But the pressure built up in the nozzle should be more or less the same.

@nallath This seems counter-intuitive that direct extruder has less pressure built in the nozzle than Bowden extruder. The reason that Bowden extruder is farther away from hot end than direct one doesn't seem to be the right answer to explain the pressure difference. Do you know more details in why? Just curious.

I'm not a fluid dynamic physicist. So I wonder how do you know it needs 10 seconds to "equalize" the pressure inside nozzle. In my limited knowledge, I think the melted filament inside the nozzle should always drip due to the gravity. But in the absence of extrusion, the volume of melted filament should only include from nozzle to hot end. To be more precise, this also depends on the physical design of hot end and nozzle as well. I sincerely doubt there is a universal value or a formula to capture this. Thus, I doubt the coasting parameters in Cura 3.31 may not be well designed as far as I have seen from the physical print I got. (A little bit off topic But since @gr5 bring this up) In the absence of a sound theoretical guidance, printing slow is and will be always a good choice compared to all sort of premature optimizations we did in latest Cura, like stop extrusion earlier in coasting or changing starting point in z-seam. However, we can't stop finding the good solution by lowering print speed all the time. I think that's beauty of fail fast fail often approach.

@smartavionics In the blog, there are two approaches: one control extrusion in firmware, while another is to generate intelligent tool path in slicer. I don't get it why it is allowed to be patented. It sounds like if I patent using right hand to slice apple, nobody should use the same way.

@smartavionics The firmware can't use Z axis movement to deuce the next layer is coming because we use Z hop. So how does firmware know we move on to the next layer? For sure, firmware knows the physic motion better than slicing engine. But slicing engine has more time and more hints to figure out the plan path. So do you think we can do something about it on the slicing side? At least, we can try and see if it failed.

@gr5 Slowing down the speed for quality is a reasonable choice if it works. But I already print at 40mm/s. I feel clock is slow. Life is short after all. I came across a blog mentioned an advance technique called linear advance to avoid z-seam problem see https://mattshub.com/2017/07/19/layer-seams/ The idea requires slicer to know in advance that extruder approach the end of layer. Thus, gradually reduce pressure on extrusion intelligently ahead. But how to model the fluid dynamic of melted filament is not as easy as it sounds. But the approach above is quite different from what Cura did where it repositions the exit point of layer. But I sincerely doubt Cura's approach is good one. For the thin wall, hiding it in inner wall doesn't work, either. Let alone the sub par path you saw. Perhaps, changing extrusion may finally lead us to see the light at the end of the tunnel. Any thoughts?

Obviously, it is not only me who have this problem in latest Cura. Even in your UM brand printer, the z-seam option didn't yield a good print result, either. The feature that determines the starting point by shortest distance, sharpest corner and random should be removed completely. A better approach of avoiding z-seam needs to some further investigation.

It is Cura's fault. Tweak z-seam option in Cura and check the planned path for the spiral object. Check out my bench test: https://www.thingiverse.com/thing:2890860

@mastory I'm reading Cura 15.04 source code and try to get some understanding of how path generation works. I already figure out how to extract the closed polygon of the parts (a.k.a the islands) on each layer. Now I focus on how to get the starting point of each types like inset and infill in the parts. In 3.31 source code, the starting point of each layer is a mess. The z-seam setting determine this. If you are interested in discussing the starting point of path planning, I will open a separate thread. Just let me know.

Note that 7/8 might not work well for non-UM brand 3D printer. But we incorporate that by UI logic. That scares me the conspiracy that Cura is dedicated or optimized only for UM.

Well,7/8 is absolutely a magic number from UM brand firmware test. I once wrote a BPMN file generator, where I need to lay down BPMN element in UI with coordinate. (It is a bad design in BPMN specs coupling logic and presentation). Anyway, the code I wrote has several magic number that can't be explained by science, but it makes the layout way much better. I strongly believe 7/8 is such thing as well.