ghostkeeper

Performance is faster in some cases and slower in others. Overall we've assumed that the user has a stronger video card than 4 years ago, but there's also some performance hit in the settings that is the result of having more than 5 times as many settings and many dependencies between them. Rotating and moving parts works exactly the same right now as in 15.04. You should be able to rotate your objects and then move them. Initial layer width never existed. Initial layer line width is indeed gone. It was removed when we implemented different line widths for different features (such as support) because that clashes with a global setting such as the original initial layer line width. Initial Layer Height works similarly to the old feature though.

There is more to the line distance: It gets multiplied if there are more directions of lines on one layer. For instance, triangle infill has 3 directions of lines (making it triangles). This makes the infill thrice as much in theory (practice is a little different). Because it extrudes three times as much, the distance between the lines must be greater to achieve the same infill percentage. Grid has only 2 directions for the lines. This also illustrates the difference between the UM2 and the UM3 since they have different defaults for the infill pattern. For the more technically inclined, the precise formula that's being used to compute the line distance is this: 0 if infill_sparse_density == 0 else (infill_line_width * 100) / infill_sparse_density * (2 if infill_pattern == 'grid' else (3 if infill_pattern == 'triangles' or infill_pattern == 'cubic' or infill_pattern == 'cubicsubdiv' else (4 if infill_pattern == 'tetrahedral' else 1))) The only place where the infill density is significantly incorrect is cubic subdivision, because which cubes are subdivided is only known after slicing. There isn't a real good solution to that at the moment but that is technically a bug. In practice there are of course other differences, because the material gets blocked by other materials when it moves over a previously placed infill line in a different direction. Also above 100% infill it starts to waver, of course, because the material gets blocked.

We fixed this recently. The fix is going to be included in Cura 2.5. For details, see https://github.com/Ultimaker/CuraEngine/commit/b69a2b4891f449cb09fcebf2b765a6925d1fa226 . The problem was that it decides to prime with the other nozzle because the support or support interface is set to use that nozzle, even though support or support interface was disabled. To work around the problem in 2.4, you could enable support and support interface, make sure that the support and support interface extruders are also set to use your preferred extruder, then disable support or support interface again.

It's not so hard to get the source-version running on Debian. Take a look at the cura-build repository here: https://github.com/Ultimaker/cura-build#ubuntulinux It's tested most often with Ubuntu but Debian should work just as well. You might run into a few missing dependencies or minor problems with some of the libraries it wants to compile, which will make take a sufficiently knowledgeable programmer a few hours to complete the build. We're also quite near to releasing a public beta for 2.4. If you're slow, we'll catch up with you!

It still tries to create a brim on the outside of the inner pieces of the B. That is expected. Why it then seems to create the brim from both sides is a bit weird though.

No, it doesn't, neither the old nor the new. It just determines the order and direction of each part, and combing is then applied to the travel moves afterwards. That is a difficult one! It is prohibitively time-consuming to go combing for every distance calculation. If someone has a bright idea on how to tackle this, it'd be welcome (but don't expect it to be implemented anytime soon, can't make any promises).

Yeah, that'd be nice. It would just save the JSON file somewhere user-specified. Similarly, importing a profile. This could increase community participation.

Machine settings are separate from the profiles. Profiles override machine settings. Machine settings are stored in the /resources/machines folder in Cura's installation. We haven't yet made a way to create, import and export machines within Cura, and it's quite low on our priority list. But it should be simple enough for a technical person to create a JSON file for a specific printer, and if you make a pull request on GitHub, we can include it in a future release.

To update firmware, the easiest way is to take the latest version of Cura, which gets you the latest release build of the firmware and allows you to update it via a USB cable. If you'd like to compile/verify the firmware yourself or make changes to the firmware, download the source code from here (assuming you use an Ultimaker 2): https://github.com/Ultimaker/Ultimaker2Marlin It includes instructions on how to compile it (using Arduino's IDE) at the bottom of the page. You can make any changes you like to the entire source code.

The LineOrderOptimizer::cluster() function is grouping up lines where both endpoints are right next to each other, using a nearest-neighbour search. This happens often in Cura, especially with skin lines which are all just parallel. It's not working very well with infill lines if the infill is too sparse. I'm thinking of making the grid size depend on the infill density. It takes a line. Then it finds the nearest line where both endpoints are less than 5mm away from the first line's endpoints. Then it finds the nearest line where both endpoints are less than 5mm away from the second line's endpoints. And so on. When it finds no more lines where both endpoints are less than 5mm away from the previous, it puts all those lines in a cluster and starts with the next cluster, using a line that wasn't picked yet. The LineOrderOptimizer::optimize() function gathers up those clusters, and calls the TSP solver to determine in what order the clusters should be traversed, and in what direction. The TSP solver uses the random insertion method. Random insertion is an approximation of a solution to the Travelling Salesman problem where the goal is to find a short path along all elements. First it will take a random element (= cluster of lines, in this case) and save that as a path: That path is currently the short path along all elements it has inserted. Then the main idea: Keep taking a random element from your to-do list and insert it at the "best" position in the path. What the "best" position is in this case is up for debate, but basically it should minimize the travel time between clusters. The basic idea behind it is that after the first few elements are inserted in the path, the path should more or less span the entire space. For all the rest of the elements, there is a large chance that there is a segment of the path that runs right past the currently inserted element, so that it can insert it without much additional cost. Only for CuraEngine, normal randomness is not allowed, since we'd like to keep the result predictable across slices. So it uses a seeded pseudorandom number generator, so that the outcome is still deterministic but the effect is the same. The algorithm is still subject to change, too.

Liam's original idea has been brought up more often: To be able to point in the interface where support is built. It's very involved to implement though. pm_dude's idea is certainly technically feasible. Since CuraEngine is inherently 2D (per layer), it would offset the layer below with a certain distance depending on the layer height and the required 30° of overhang. It subtracts those areas from the current layer's area. The result is the areas that would have to be printed more slowly. This is already currently used to detect bridges. The lines in bridges are currently oriented to provide maximum strength (so lines don't have endpoints in the air). To make it print progressively slower between 30° and 60° is difficult due to the way g-code works. I'll make an issue for our internal issue tracker. It'll be "nice to have" though, so don't expect a feature such as this to come in anytime soon. Maybe it'll get shot down too.

Regarding the path planning itself, everything is really just based on nearest neighbour. There are currently two major spots where it is required (as far as I know; I still haven't seen everything after a month of CuraEngine programming): Optimising the order of polygons and optimising the order of skin/infill. The rest, such as filling small gaps, I don't know of where the code is but I'm told is also nearest-neighbour-based. These main two algorithms are in pathOrderOptimizer.cpp. The first is the order in which to draw polygons, which includes infill and walls and such. For these it first finds the point on each polygon that is closest to the starting position of the path. Then it treats the polygons as points so it can execute a simple nearest neighbour algorithm: Just keep going to whichever polygon is nearest to your current position that you haven't visited yet. The second application is the order in which to draw lines of skin or infill. This has a bucket grid heuristic. First all endpoints of the lines are put in an array of buckets, each bucket representing a 5x5mm area of the build plate. Then it starts the nearest neighbour search, but with a heuristic. It keeps going to whatever line is nearest to the current position (initially the starting position, thereafter the endpoint of each line). But instead of going through all lines and looking for which is closest, it will first go though all lines with an endpoint in the bucket that the current position would fall in. Only if there aren't any lines in the current bucket, it will go through the rest of the lines. The nearest neighbour algorithm is fast to compute and simple to implement, but it has a performance ratio of O(log N), meaning that the ratio of the optimal path to the worst case path from nearest neighbour scales with the logarithm of the number of nodes. The average results of nearest neighbour aren't good either, on average 24% longer than the optimal on city maps. I've been working on a new implementation based on randomised insertion that provides much better bounds (worst-case performance ratio of 2), much better average results (on average 11% longer than the shortest path on city maps) and should take a similar amount of time to compute. Edit: Source on average performance ratio.

This is because Cura is looking for faces with a shallow downward-facing angle. That tail probably just has one single point at the bottom with several sufficiently steep faces. That one's quite a stubborn bug. It hasn't been fixed in more recent versions either. I'd advise you to add a thin cylinder to your model to support the tail. It might also be a better idea to print the doggy upside-down and apply some sandpaper afterwards.

That microstructures video is completely awesome by the way.

Soda-lime glass maybe?

That is a concern, though. What antivirus are you using? Perhaps we can send them a message to let them analyse CuraEngine for virusses and hopefully conclude it is a false positive. CuraEngine does no virus-ish stuff, so it's strange that it would be flagged as positive. Perhaps because it's communicating to the GUI via a local socket?

I'm going to assume you're using 15.06.03 Can't say I'm having this problem. It sounds like the back-end that does the slicing doesn't start for some reason, because the things you mention all depend on the back-end. Print time is computed from the g-code. Saving to SD requires having a g-code to save first. Layer view draws the path of the nozzle according to the g-code. Have you tried this with a different model, preferably one that fits easily within the build volume? 15.06.xx is known to have somewhat buggy placement and bounding box implementations. If it makes a mistake and thinks the model isn't in bounds, it won't start slicing. Maybe deleting your user settings could help? Or just moving them to a back-up directory if you want to be able to restore some of them.

High time we sign our binary releases, isn't it?

Also, with regards to (1), this is a known bug. Cura requires administrator rights to be able to write to files in the Program Files folder. It works if you run Cura as administrator, but we should change that so it saves the log somewhere else, such as %APPDATA%.

It seems you're right. I'll file a bug report on this. Edit: The bug report can be found here. For updates from me and the other developers, please see that page

Increasing infill towards the top means that some of the infill towards at least one side won't really be resting on top of anything while it's printing. This requires a lot of bridging. It won't be able to transport a lot of force, so it won't make the model much stronger. That is, if the infill pattern is simply resized as it is done now. It requires a bit of creative thinking to get this idea worked out proper, I think. Perhaps something like gradually splitting lines in two as it goes up? Like if you'd see a side-view you'd see a tree structure, but then with the sides of triangles rather than single lines? Plug-ins for the back-end of Cura (CuraEngine) are planned for the future, by the way, but will take a long time to implement properly.

It looks a bit like this was printed too hot. You can try to reduce it by reducing the temperature of the nozzle (in Cura's advanced mode this is under Material). Second thing I'd try is reducing the printing speed (in Cura's advanced mode under Speed).

The Glasgow Haskell platform, GHC, tends to put some things on the %PATH% variable that has some name clashes, such as its own version of libstdc++-6.dll. I've seen the problem before with different programs. I'd advise anyone to put the Haskell platform stuff at the very end of the path or not at all.

One of the driving forces behind building the current plugin architecture for Cura was that it would be possible to collaborate with external programs such as Uformia's products, and transparently repair models from within Cura using external mesh repair tools.

It's hard to troubleshoot this. When I load up a print of a bottle, the G-code looks fine. I also looked up a model of a bicycle, like you said, and it requires a lot of support but otherwise it looks fine. What settings are you using for your print?