aroth

First, here's a patch for anyone who wants to try out the 'manual slice' version (go to 'File -> Preferences' and uncheck the 'Automatic slicing' option, and then slicing will only start when you hit 'Ctrl+T'): http://pastebin.com/GX1A4igz If deferring the call causes issues, what about short-circuiting the costly part when possible? I'm assuming the costly part is where it iterates through each mesh to find the largest bounding circle that exists (if that's what it's doing?). Based upon what little I understand from my cursory examination, it seems like the method is being used to compute bounding geometries, sizes, and offsets. In theory that means instead of performing the exhaustive search through each mesh every time a change is made, the new values could be worked out mathematically based upon 1) the previous values and 2) the nature of the change. For simple changes, at least. For instance, scaling and translation seem like they should have very predictable effects upon the previously computed result. It's fundamentally the same, but multiplied by some factor (scaling) or shifted by some offset (translation). I'd say the same about rotation as well except it seems that somewhere along the way there's some accounting made for gravity/the build platform, such that a rotation can also trigger a translation along the vertical axis. Perhaps you could even precompute the result once, and then supply data to the external world by applying whatever the current transformation matrix happens to be to the precomputed result(s), in an on-demand kind of way? If so it seems like that would be very fast, once the initial computation was completed. Though as noted, graphics (and in particular, 3d-graphics) is not my area of expertise, so perhaps I'm completely wrong. So...problem already fixed for the next release? Edit: And one possible explanation for why the toolpath computation may cause issues for some people even though it's done on a background thread is paging. If the thread is allocating memory so that it can run its computations and the OS is forced to start paging things to disk, that can easily cause performance degradation in other threads (and processes, even). And then if the main thread keeps trying to bring the paged information back in...the two threads throttle each other and things grind to a near-halt. Paging might also explain why my desktop seems significantly less impacted than my laptop; it has 6x the amount of RAM installed and is very unlikely to ever need to page anything out.

After some quick initial investigations, I've found: It's trivially easy to disable automatic toolpath computation and provide a menu item that triggers it manually. Doing so improves the experience when entering print settings (speed, thickness, layer height, etc.), but does not help when rotating/scaling the model (which is the bigger issue, really). Trying to access the 'Layers' view when no layers have been generated and no layers are currently being generated will hang the app forever (so actually disabling toolpath computation in a user-friendly way is marginally less trivial). The issues when manipulating the model object appear to be related to the PrintableObject.processMatrix() method. I agree that 'fixing' the method itself would not be easy. Or it might be, for someone who does a lot of graphics programming, but I'm not that guy. In any case, deferring calls to processMatrix() seems like it may help. Not a proper fix, but the UX can't tell the difference. Developer question: Is the PrintableObject class used as a data-source for non-trivial things, or does it exist solely for the purposes of display?

That's true for some of the process, but not all of it. There's definitely something that happens when settings get changed that either uses or blocks the main/UI thread, resulting in an unresponsive application. Whether that's toolpath generation or something else, it would be useful to have an option to defer the costly operation until after all changes have been made. The issue is more noticeable on slower machines (my laptop struggles a lot more than my desktop), and is particularly pronounced on the scaling inputs. So perhaps it's related to the rendering of the part in the preview view, although scaling the graphical model should be quite efficient assuming that it's done on the GPU. But load a moderately complex model and try changing one of the scaling options when the toolpath is just starting generation, and see how long it takes before your keystroke is even recognized. This takes a few seconds on my desktop (hex-core i7 @ 4GHz, 24GB RAM), and up to a couple minutes on the laptop (quad-core Q6600 @ stock settings, 4GB RAM). And it's sufficiently reproducible that the lead developer should easily be able to experience it for himself. Though I see Cura is actually open-source. If I get some free time I'll poke around and see if I can come up with a patch/pull request.

Cura generally seems to work quite well, however I'm finding the way it automatically starts recomputing the toolpath as soon as any option is changed to be extremely annoying. For small/simple parts it's not too bad, but trying to rotate, scale, and configure a print of a complex object is a complete nightmare. You change one option, wait several seconds (or more) while it churns trying to compute a new toolpath, change a second option and wait again while it throws out the work it was trying to do and starts over, rinse and repeat. And sometimes just going into a settings dialog will trigger a recompute, even if you cancel out of it/don't actually change any options. Surely it would be possible to add an option to disable this automatic computation, so that Cura only tries to create a toolpath when I tell it to (or at least, after 'X' seconds have passed with no further changes being made)? I think that sort of change would make the software much more usable.

When printing hollow parts that have both an outer and an inner shell (for instance, vases, cups, rubbish bins, etc.), I've noticed that the interior shell tends to be far less 'polished' looking than the exterior shell at the same point. This is particularly evident when printing something like this: http://www.thingiverse.com/thing:45315 The exterior looks great, but the interior is very rough (and also tends to be cluttered with thin threads of filament that have to be manually removed after the print...though I think playing with the 'retraction' settings can help reduce that?). Is this because Cura prioritizes the exterior surface(s) and/or doesn't worry about the internal ones since it expects them to be hidden? And is there any setting in Cura that will cause it to print internal surfaces as nicely as it does the external ones?

No worries. And when you go to print it, I found that I got the best results orienting the part vertically (i.e. in the same orientation that it gets installed in) and then telling Cura to cut off the bottom 1.45mm of the part. It printed without doing that last bit, but a good portion of the bottom ended up being printed over the air and came out with a very rough surface (strands of filament going off in all directions) as a result. By cutting off the last 1.45mm I was able to get a perfectly flat bottom layer, with no negative impact on the shroud's performance as far as I can tell.

Yes, I was a bit concerned about that myself, given that I'd have a plastic shroud in close proximity to the thing that gets hot enough to melt the plastic used to make the shroud. In practice, however, it seems to work fine. Even with PLA. It constantly has cool air circulating through it, which probably helps. And it seems like the worst-case failure scenario is that it melts/deforms enough during the print that it comes into contact with the printed object and causes the print to fail. I can live with that. It probably wouldn't be a good idea to use a shroud printed in PLA to do printing with ABS though.

Thanks for the suggestion. I printed one of those (specifically, the 'V06' one found here: https://www.youmagine.com/designs/ultimaker-2-fan-mount-dual--2 ...and it made a fairly noticeable difference: It's enough of a difference that I'd suggest changing the geometry of the shroud that ships with the UM2 to provide more symmetrical cooling for the single installed extruder. Although I guess since the printer can print its own mods, its kind of a moot point.

Thanks, does that mean that increasing the 'minimum layer time' in Cura should also result in a better print?

UM2 fresh out of the box: Not sure if that counts as successful or not. There are some minor issues at 9mm/s, and some moderate issues at 10mm/s, but the print itself didn't fail. The roughness at 7mm/s is because the spool was snagged. I cleared it quickly and the print was fine after that, at least until it reached the higher speeds.

I just unboxed my Ultimaker 2 and run through a test print of the included robot example. I think the results came out quite well, particularly compared to some of the other 'first print' examples I saw when I was researching my purchase. However, I'm seeing some minor issues that seem to affect only the right half of the model. Here's a picture: Can anyone give me any pointers as to what might be the cause of these issues, and how I can fix them? I'm guessing maybe the right side of the build platform is slightly outside of level? Should I go through the leveling process again?