Ricky

@ahoeben You missed the whole picture. I'm talking about the intelligent deduce all the settings based on limited number of human understandable configuration. No slicer has ever done that. Recommended modes in Cura is a naive version (or put in political incorrect way -- a joke) As a consumer, when you plug a power adapter to electric grid, you really don't need to understand the whole complicated process how the electricity deliver to your home. If you want to know the nitty-gritty, just Wikipedia it. You will be amazed how engineer hide that superb well for ordinary people. @ianpaschal I'm fine your implying me trolling. That's how the liberals in US did to violate other's freedom of speech. You think code review is a panacea? No, it didn't solve the problem, either. My suggestion to split stable and experimental branch is to set up a clear firewall between new features that impact everyone (category 1) and new features that only impact some specific brand of 3D printer (category 2). For example, a new feature that change how to determine the starting point of path belong to category 1. Such feature needs to be carefully reviewed (as you proposed) and an extended long period of testing by all users. Note that it should not be just UM brand 3D printer's user. My contribution to Cura open source project doesn't mean you can offend my own interest. Otherwise, in the long run you just exclude others to join this open source project. In the end, Cura just turned into another MySQL. I will just fork it to work on 15.04 branch. For a new feature like adding new support for two extruders 3D printer, it is category 2. You can merge it to stable branch as early as possible. When you do code review, classify them into two categories and then merge accordingly. That is my proposal in https://github.com/Ultimaker/CuraEngine/issues/784

@kmanstudios Well, you misunderstood us all. My points of view is from a non-techie user. Please allow me to give you an example. To improve usability of slicer, we should not expose the exact number of layer height like 0.1234 mm. But instead, we should just say fine, normal or draft in the option. From there we deduce rest of settings like how to do a trade off between print speed and print quality. If UI can achieve this for slicing engine, that can beat all the slicer out there. If you are truly a hacker/engineer who want to take control, just read the code. But I can imagine nobody just nobody in the world want to do that for improving one single print.

@ghostkeeper I totally agree with you. Even for a sane engineer/hacker like me, I don't want to spend my time to figure it out what the setting is or even read the code to figure it out why. No matter how smart you are, sometimes you have to admit you have a limited time and energy to get your print better. For majority of user, they just don't care why and take it as the limitation of their 3D printer.

@smartavionics Your example is exactly my concern on the improvement (or hack/tweak) I mentioned. We need a better way to manage it and expose it to end user. If we don't get it right, we are in the wrong way. I made a discussion thread in Github. Welcome to chime in. https://github.com/Ultimaker/CuraEngine/issues/784

I totally agree that your support for Cura should base on promoting the sales of Ultimaker brand 3D printer. The point is well taken. I'm not against it at all. Because everyone has to pay their bills. Smart software developer deserve a better pay. In fact, by supporting Cura can it also promote the sales of your 3D printer in the long run. It is a very smart business strategy compared to some Chinese 3D printer company, who just build a cheaper and better 3D printer. They have no clues how to keep their advantage in the long run. The 3D printer I owned didn't upgrade their firmware according to slicer thus it may not see the tweak or benefit in the latest slicing engine. However, there is one and only one model (not talking about STL model, I refer to slicing algorithm) in theory. If it is not, your model is wrong and go find another one. Majority of new settings might be a must-have. But some like the one impact tool path generation needs to be carefully reviewed. Those settings related to tool path severely impacts print time and print quality regardless of your printing material or the brand of 3D printer. Like the z-seam setting in Cura engine 3.31, I disliked this. After reading how it works, I think it should be deduced intelligently instead of exposing it. That's a nitty-grity. Regarding to the intelligent profile, formalizing human intent into machine understandable format is always a hard subject in computer science. It is like automating software requirement in software engineering. Unless we have a true AI (not talking about pattern recognition like artificial vision, voice recognition and etc), we will never have that day coming soon. For now, what we can achieve is to reduce the number of settings that exposed to the UI as many as possible. Transform those technical settings into novice understandable terminology. That alone can make a night and day difference in term of usability. It will for sure promote the sales of Ultimaker 3D printer as well. My suggestion is that put more focus on UI and make very very conservative change in Cura engine. I have my suggestion in Github regarding to the branching management (https://github.com/Ultimaker/CuraEngine/pull/722#issuecomment-392003445)

Latest version Cura didn't optimize GCode generation that much. It generate tons of redundant M Code. In most of the print, I noticed that it generate sub par tool path and use variable print speed for different types of section (inset and infill). For sure, I can notice thate G code files size is bigger and print time is longer compared tot the legacy one. I have never seen any print quality improvement compared to old version. Early optimization is the root of all evil. See my version benchmark test: https://www.thingiverse.com/thing:2890860

Adaptive layers is to let slicer figure out the variable layer height based on the print content of each layer. It is undesirable for majority users to figure out which two layers are the same and then merge them. I don't think it is intended to solve your banding problem. Find a smaller nozzle that may have a finer print to solve the banding problem you mentioned. I wrote a matplotlib part viewer tool here, which draw islands layer by layer from the intermediate output I extract from Cura 15.04. You can take a quick look of UI and imagine how bad it is when you make your merging choices for a tall print, where might contain thousands of layers.

Regardless of the implementation of other slicer, to merge two layers you must make sure the parts (inset and infill) must be the same. Otherwise, they can't be merged it together. You can't do it by human eyes. Neither do you want to pick which layers to merge manually. It is a nightmare.

@yellowshark Thanks for sharing your thoughts. I totally agree with your points: more feature you add in the code, more bugs you introduce. No matter how good the QA (if any) is or how smart the programmer is, this is a inconvenient truth. I understood Ultimaker's strategy to split UI from engine. Let UI takes care of the complex setting for user. Hopefully in future some intelligence can tweak the optimal settings based on user's STL input model, compared to a simple rule-based driven setting check now we have. But in reality engine itself gets overly complicated. When we patched something because of an X STL input model from you, it may break Y and Z STL input model from others. I did saw a couple unit test for QA purpose. But I didn't see any integration test which perform end to end or do a physical print test. Maybe it didn't release in Github or it may be difficult to benchmark this. I didn't complain anything or anyone here. Cura is free and good stuff. I mean I can afford $150 for Simplify 3D. But there is no fun at all to poke around what is under the hood. In any case, I just want this open source project getting better and go towards a right direction. No intention to offend anyone.

The post here shares my thoughts on Cura after reading source code of Cura engine 15.04 vs 3.31. Recently, I want to improve Cura sub par path planning. Thus, I read and understand Cura engine source code. My conclusion is the following: the latest developemnt of Cura engine is going in a wrong direction. Compared to 15.04, latest Cura exposes tons of settings and frequently add/remove/patch/re-patch special hacking tweak here and there. That alone will make slicer getting worse. In philosophy, there is so called Occam's razor. The idea is simple: Among all solution, the one with fewest assumption is always the best. This idea applies to slicing as well. Let say slicing engine is a model that we want to fit a desirable physical printed model from an STL model input file --> Physical Printed Model = Slicing_Engine (STL model) Differen version of Cura engine is different slicing model. To fit majority of physical printed model well, the best model should not use tons of parameter. In econometrics, it is called model misspecification due to creating a over complex model with many parameters to fit a specific set of data points. In general, the fitting works well only in a small subset of sample data. It doesn't fit well for the majority. If you find that latest Cura 3.31 doesn't work well in your model compared to 15.04, it is highly possible that someone placed his/her hack somewhere in the settings which messed your slicing up. My observation is based on Occam's razor, my daily job experiences and also my reading of source code. It might be biased. So welcome to chime in and share your thoughts.

Boy, you completely misunderstood me. The difference I referred to in my previous comment is the difference of 2D print parts (including infill, shell and etc) between layers. In other words, the parts in each layers must be exact the same if you want to merge two layers in adaptive layers algorithm. Adaptive layers are for: saving print time prevent slicing from missing key feature due to numerical error when slicing layers

How can your human eyes can identify which layers are identical or not. You are making bad assumption. In addition, if there is 100 layers in the slicing, do you really want to add your human heuristic?

Most of the time, combing and z-seam setting from 3.x caused more trouble than improving printing experiences. The paths it generate with different combination of combing and z-seam make non-sense at all. For example, sharpest corner in z-seam. What if there are multiple sharpest corner in the same layer? Such settings should be removed for good.

@smartavionics I doubt that z-seam setting hide the truth cause of the problem. For the spiral object like tower, 3.31 always delivered sub par path planning compared to 15.04. I just found another case in MP select mini Facebook group. You can see the obvious z-seam in the inside wall (Please disregard the wall form outside. There is wavy issue. It might be caused by its bent Z threaded rod). Picture a2.jpg is G code from 3.31, while a3.jpg is G code from 15.04.

I swear I did my search in the forum and watch several Youtube video how to solve my problem -- strengthening infill in one specific part of my model. See the Video with demo. But here is my silly question: can Cura only print my original part with the changed of intersection between the original part and the facilitated part. I'd expect that Cura would print the whole facilitated part. In the video, the facilitated part is a long square stick. That seems some tedious post process fine tuning work. To avoid this, perhaps I have to clone some of my original part in CAD and do this trick?

@al65 Assuming you ignore starting point and end point among layers, the slicing problem above is called embarrassingly parallel problem. One should not group or schedule ahead in algorithm. The reason is that one machine may have only 4 cores. It is reasonable to group the threads by 4. But what if I have a many core GPU or even a grid of computer where tens of thousand of core are available. If you still groups by 4, you won't gain any performance. Thus, it is a bad idea. Early optimization is the root of all evils. If you are interested in getting your hands dirty, we could work together in 15.04 legacy branch to optimize travel path. My goal is to run TSP on path planning for parts. So far I'm working on my dev branch: Added thread safe logging to file and screen with G3LOG Enable CMake Output parts (island) to an external file for TSP solvers Added matplotlib to view the parts by layers See my forked on Cura Engine: https://github.com/rickyzhang82/CuraEngine/tree/dev-15.04.6 Also, if you want a release version with UI, you can build it as RPM in Fedora 28. I patched the build script so that it can pull from my dev-15.04.6 CuraEngine repo: https://github.com/rickyzhang82/LegacyCura/tree/dev

If you use 3.x Cura, each layer is sliced independently in parallel fashion. The starting point of each layer is determined by the z-seam option and your hard coded setting of 'layer_start_x' and 'layer_start_y' see: https://github.com/Ultimaker/CuraEngine/blame/master/src/FffGcodeWriter.cpp#L1185 But this only impact how parts (a.k.a island) get sorted. (It is not an ideal way for path planning optimization. That's what I'm working on to improve it. See my path planning thread.) To your question, the actual starting point of the layer is determined by the printing order of infill and wall. In fact, if you choose infill first, the layer starting point should always be inside the infill. I haven't figured out the end point of layer yet. But the initialization of the starting point of parts (including wall and infill) could impact tool path planning, which it may not be taken care properly. After all Cura is open source, you could do whatever you want with your ideas.

Here is a small visualize progress I made so far. I output the closed polygon of the parts from Cura Engine into a file. Then, I used matplotlib to draw the parts. You can change the layer index to explore the parts in different layer. The file format is defined in here: https://gist.github.com/rickyzhang82/33831c6d5a3eaaa3de3ffb5122f15b69 My work is in my repo dev-15.04.6 https://github.com/rickyzhang82/CuraEngine/tree/dev-15.04.6 To get the parts data, just compile cura engine and replace stocked 15.04 CuraEngine in Linux/Mac (no Windows). Slice a model and it will generate file in /tmp/parts_by_layers.txt Then run: cd CuraEngine/utils PYTHONPATH=$PWD python ui/main_app.py My next step is to output the entry point and the exit point of each part into another text file. I believe the problem is an asymmetry TSP.

The proposed fix I'm going to make is relativly easy to migrate from 15.04 legacy branch into master branch. Basically, nobody has improved path optimization since then except tweaking starting point. As I'm aware, there are way too many moving variables in master branch as I pointed it out in 3.x issue that might undermine my effort, eg sub part selection in the starting point of shell, infill and etc within a part/island. At the cost of slicing performance, reducing the air time travel in FDM may also reduce the chance of retraction. This alone should make print better than any hack/tweak we have added. The improvement doesn't require human intervention. I have done plan #1 already -- output the polygons in external file and wrote a small script in matplotlib to plot the part as well. This should attract enough interest from operation research people to chime in (if any). They always screamed for data. Regarding to the performance of slicing, in my hobbyist level 3D printing I seldom see the number of my parts are more than 100. That small problem size should be good enough to solve in exact TSP in a reasonable time frame given we have a good mixed integer linear programming solver and a beefy machine (not raspberry pi). On the other hand, if layers has more than 100 parts/islands, that is another good motivation to minimize the air time travel as much as possible. But perhaps it is done in approximated TSP approach, instead of exact approach. In such case, I should checked if the probabilities of getting better optimized result from approximated TSP is higher than the one of the nearest neighbor. Again, I'm not a OR expert. That requires me my further research in my spare time. I have tons of smart people in my community. They may help.

Solving minimal distance can potentially save the print time and improve print quality. 10 seconds wasted due to sub par path planning in one layer will lead to 16 minutes longer (given100 layers). In addition, the longer nozzle travel in FDM, the higher probability the nozzle drips the filament no matter how good you calibrate retraction. We always has one path. That works. But my point is that there may be some better way to do it. I'm going to do some work with my spare time and see how things will get improved. Here is my plan: Output parts coordinates in the file. There was a routine to output in SVG. But it is scaled. My purpose is to let other operation research folks (if they are interested) looks into the problem easily. Because those guys always ask for data. Move parts order optimization after all infill, wall and etc in the part is processed. Add information about an entry and an exit point of each part. Experiment exact/approximate TSP. My work is here. I don't know who else will be interested in my proposal.

Tool path planning (a.k.a how to instruct nozzle movement in G code by slicer) always intrigues me. I like watching time lapse in real or also view it in Cura 3.x layer view mode. But from time to time, there are some crazy dance in 3.x which doesn't make any sense to me. So I decided to read their code and see how they do path planning. Here are my findings. Please correct me if I'm wrong. Common issue In both 15.04 and 3.x: Parts (a.k.a island/cell in 2D layer or union of overlapped polygons) order optimize without exact information of entry point and exit point of the part. This is due to the fact that the G code generation is done in the following order: layers -> parts -> any sub type (like infill, wall and etc) in part. This inaccurate information almost undermined the optimization work in part path planning even with exact/approximated TSP. But why not separate parts path planning from G code generation? In other word, do part path order optimization after sub type path order optimization and entry and exit of the part are known. 3.x issue In 3.x: Within each part, the path of each sub type (like infill, wall and etc) is optimized independently. It might be local optimum in each sub type. But it is definitely not a global optimum within a part. There are ad-hoc tweaking of staring point for z-seam alignment purpose like random, shortest and sharpest corner. I'd believe this tweak alone caused some bizarre nozzle movement compared to 15.04. More often than not, it caused more bugled wall than usual. In any case, there seems to be a great room for path planning improvement in Cura. IMHO, I'd like to figure out how to fix the common issue first (the part order). I think part order optimization can convert into an asymmetry TSP. This is due to the fact that the parts in our problem has an entry and an exit. I did a test on symmetry TSP of complete graph with commercial software. The performance is quite impressive for solving 100 cities within 0.5 seconds. But that's the performance of commercial software. I don't know how good I can write a hobbyist level integer programming solver.

When solving path planning, it was better that we solve it in exact algorithm if the number of closed polygons is small or the distance among polygons are large enough. Can anyone explain the latest Cura 3.31 path planning in https://github.com/Ultimaker/CuraEngine/blob/master/src/pathOrderOptimizer.cpp? For sure, I can read. But it takes time to digest and understand. I'd wonder why it deliver subpar route for simple case like the ticket I posted here