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.

@kmanstudios What is OP? At least I don't know the firmware of my 3D printer. It is not Marlin but a closed source one. By blindly using whatever it defines or provides in slicing engine, we end up suffering from the sub optimal settings. Now I kind of understood why GPLv3 requires firmware need to open source as well.

@amagro This seem to be related a specific brand 3D printer's firmware. It makes my stomach sick to learn this.

@gr5 Is that 7/8 UM brand nozzle kind of magic number?

@kmanstudios Another option ‘shortest’ is problematic as well. When you define Euclidean distance, you must provide two points. But you have no clue nor control where the starting point of next layer or the exit point of previous layer. In fact, the help options doesn’t even specify what two points are. 3.31 Cura parallelize slicing per layer. So you really have no control on two points at all. Another option ‘random’ is horrible, either. Instead to try(not using the word ‘attempt’ here) to solve z seam, you introduced stringy. You always want more control from settings but in reality you control nothing. I’m always a believer of Occam’s razor principles. I hope you know why now.

@ianpaschal Fair enough. I will work on the improvement on my way.

@ianpaschal I already proposed a development model in Github to resolve my concern. But it was rejected by @ghostkeeper I did read two blogs he linked. But the counter argument in the 2nd blog is weak and naive. One of the argument point even said master branch is not a default development branch. Thus, branching is not a good idea. Such logic is silly. To your 'Politics out'. Sorry. No more politics.

Please put yourself in my shoes. In my spare time, I contribute my brain power to some other open source projects which I'm interested in. You can check my Github account. Pull request history didn't lie. By contributing back, everyone get benefits. But those projects I worked on are not endorsed or back by any profit driven hardware company like UM, whose sole interest is to promote their hardware sales. If anyone tries to undermine others' interest to take other's hard work for free, I don't think it is ethical thing to start with. My point is that such open source model is not a win-win situation to UM and any outside contributors. If they completely overlook the interest of others, they should make the slicing software closed source. Once they start to take in other's PR, they should have some decent human conscious (if they have). If you check Cura engine license in Github, it is under AGPL. If you are familiar with licensing, AGPL is more restrictive than GPL. If you distribute slicing engine as online service, you must open source under AGPL. GPL doesn't need to. So you must know that UM's legal team must have protect their IP well. That being said. I'm not against anything what UM does. It is a smart business strategy. I just want that they can steer back to right course. Just my 2 cents. Not my whining.

@kmanstudios Well, that's how they did in reality -- improving slicing and generating GCode optimal to their 3D printer firmware. That's I feel disgust it the most. Do you recall in the couple threads or the UM's people reply from Github. They did do 3 round of QA test before release Cura. But that test must be done in their brand of printer. So please advise me why anyone should contribute to Cura if Cura is not in line of their own interest. We didn't get paid by UM. I'm a American. I'm a rebel and love the quote 'We the people'. So if they don't accept my plan. I will do it by myself in my own way on my own repo. It is GPL after all.

@kmanstudios I'm totally with you that slicing engine needs to be flexible enough. For people like you, you can still override the setting and input them directly to slicing engine. But my point is that UI should hide the complexity and make a optimal settings based on STL model so that majority people don't need to tweak hundred of settings to get a good print. That's also the idea behind Cura split Engine and UI. To make FDM printing accessible to ordinary people, slicing engine is a technical barrier not the high price. Chinese manufacture has pushed the price down to the level everyone can afford in US. In fact, Ultimaker company want to promote the sales of their hardware. Making slicing engine ease of use is also in line of their interest as well. But making your brand FDM printer works great is **NEVER** their goal. Thus, I made my proposal to change the development model and its course so that everyone even those who don't pay for Ultimaker can still enjoy the fun of 3D printing. That sounds very altruism but that's my plan. I personally forked 15.04 branch on my repo https://github.com/rickyzhang82/CuraEngine/tree/dev-15.04.6 and started to make it better. My recent goal is to optimize path planning with ATSP solver. @ahoeben You mistook the assumption from the information provided from slicer. When slicer do slicing, ie cutting the triangle mesh from plane and connect all line segment into closed polygons, it knows the geometry of your STL model better than anyone. Such information in fact feed back to UI through a socket. But fo now it just visualize in UI. There is no and no whatsoever analysis to make a better setting decision for users. That is not assumption at all.

I apologized for my rudeness. I'm not a native English speaker. I was not educated the way like kids in US did use the political correct term or way to express the idea. I felt frustrated sometimes when my point didn't get fully understood even though you don't have to agree with mine. The discussion about intelligent deducing settings is exactly good example. Cura recommended mode indeed is a simplify version of my ideas. But there is no intelligence built-in at all except some rule-based check on settings. My rudimentary thinking is that it should analyze the STL model file by slicer and make that intelligent decision for normal users based on the feed back from slicer. For example, when slicing layers (not reach to path planning yet), if you find that the object is a spiral one, UI setting should use spirals print path automatically without human intervention. No slicers has been there yet. That's why FDM based printing is still not as easy as printing paper. Thanks for pointing it out @kmanstudios. My comment is harsh but no means to insulation or trolling.