Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
aroth

Feature Request: Disable automatic toolpath computation

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites

You don't need to wait until the whole toolpath is generated again, just ignore the toolpath generation and make any changes as if it was not there. The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura. For that reason you have to make a very strong case before the lead developer of Cura would even consider implementing you feature request.

 

Share this post


Link to post
Share on other sites

Dirkels, one that frequently bugs me is that if I have a model that takes a long time to slice, and then I decide to switch the settings for Support Type or Platform Adhesion, I am forced to wait until the slicing is done before Cura will allow me to change settings. If I try and change these settings before it's done slicing, the dropdown combo box will not stay visible long enough for me to do anything. That gets pretty old. I often have to resort to something like scaling the object down to be very tiny (so it slices quickly), changing the settings, and then scaling back up.

-Dave

 

Share this post


Link to post
Share on other sites

The toolpath generator is a separate background process that is running on the lowest priority which should not hinder anything else you do in Cura.

 

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.

 

Share this post


Link to post
Share on other sites

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.

 

Good luck. I have a pretty good idea what is blocking the GUI, and fixing it won't be easy.

(Disabling re-calculation does not remove the effect you are having, hench the reaction to these requests)

 

Share this post


Link to post
Share on other sites

After some quick initial investigations, I've found:

 

  1. It's trivially easy to disable automatic toolpath computation and provide a menu item that triggers it manually.
  2. 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).
  3. 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).
  4. 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?

 

Share this post


Link to post
Share on other sites

deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.

As for the delaying of slicing performance, I do not notice any performance difference. But it might be interesting to test to see if it's the starting of the slicing, or the receiving of data that is causing the slowdown.

 

Share this post


Link to post
Share on other sites

Wait, let me explain a few more things that could be messing things up here.

Another fine example of my shitty code. If you have multiple objects on the printer bed, and you print those "all at once", the GUI code (does this on a thread, but the PIL could be messing with you here) will calculate the final 3D model before sending this to the engine. With multiple complex models, this could potentially take quite a load on your CPU. Especially as it's also doing all the transformations then and essentially storing the model twice in memory. Recalculating positions so the final position of the object matches with what you want.

The plugins are run in the same Python instance as the GUI, so plugins will block the GUI (Due to the PIL once again) plugins can be a real slowdown if you have a lot of them enabled.

The Engine communicates a lot of polygon data back, the GUI is storing this. This is used to speed up rendering of the toolpaths, but storing this data could potentially be causing slowdowns.

When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.

So...

 

Share this post


Link to post
Share on other sites

Hi,

I have read above posts, a little technical, but get the idea ( I guess :) ).

I might not be the average Cura user, but I took some pictures from the workflow that suits me best.

WP 001075

 

I have an idea about the files I load, so choose the profile already.

Hit he load button

WP 001078

 

 

As soon as the models appear, move them away from the buildplatform in 1 sec before cura starts calculating.

WP 001080

 

 

Most parts I have to rotate and move. Prints a lot faster keeping the Bowden as straight as possible.

WP 001081

 

 

 

When the stones are in position, pull them fast in the right position on the buildplate.

No hesitations otherwise you have to wait until cura is done with the one yellow part.

On this computer there seems to be a delay off aprox. 1 sec before cura starts calculating.

WP 001082

When parts are yellow, hit layer view, go do something else for 2 minutes. check layers and save the gcode.

WP 001083

 

Hit normal view ( don't forget it!!) and load a new platform ( 400 stones to go ) Almost done ;)

 

And In my free time, still having fun printing at home ;).

 

But I do like a START slicing button!!!! :-|

 

 

 

 

Share this post


Link to post
Share on other sites

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

 

deferring the processMatrix can cause hell in other areas, which depend on up-to-date model information to be available. But, yes, that's one of the main causes of slowdown.

 

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.

 

 

When in toolpath view, GCode is parsed, result is stored, and then read again to be transformed into the shown toolpaths. This isn't as efficient as it can be. Totally rewrote this code for the PinkUnicorn.

 

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.

 

Share this post


Link to post
Share on other sites

If paging is happening, then you're pretty much screwed anyhow. But I don't think Cura uses shitloads of memory, and any recent laptop should come with at-least 2GB of memory these days.

As for re-using, there are some many cases that can happen, and there is quite some geometrical magic going on at that point. Lots of it is done with numpy, which makes it even trickery (but loads faster)

 

Share this post


Link to post
Share on other sites

Here's a patch that also moves the graphics/'processMatrix()' updates onto the manually triggered computation: http://pastebin.com/L6kKaRe4

Caveat Emptor

I haven't had time to test this thoroughly, but it seems to work as expected (I can rotate, scale, and configure my print parameters with zero delay, hit 'Ctrl+T', and then get a successful slice) and with only minor side-effects (if I scale an object outside of the build volume, it won't always turn gray until I hit 'Ctrl+T', etc.).

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

Terms of Use Privacy Policy