Cura multi threading - what is and what's next

[pm_dude 27]

Hello,

Now I know it was discussed before and many simply requested to multi thread cura for slicing without really knowing the involvements. I'm partially a tool programmer (not a software engineer) so I can understand involvements and like to optimize time and workflows in general.

From my understanding the nozzle path is the most difficult part to separate since you need to know start the from the previous layer and dont know where you will end. But I'm wondering if anything else is/could be threaded at the moment.

If this topic came up already please save everyone some time and redirect

Here are some things I have in mind:

- support generation

- brim/skirt/raft

- slicing (not defining the path)

- infill

- starting the path before all the above are complete

In many cases all the above seems to generate fast but with big and complex models even those can take a while.

 

Cheers

 

[dirkels 0]

http://umforum.ultimaker.com/index.php?/topic/6183-why-cura-so-slow/

Don't know if it covers everything you mention but have a look.

 

[pm_dude 27]

Thanks. Its a good summary. Knowing how it's currently splitted it would require quite some work to thread it

[nallath 806]

Technically speaking, cura is already threaded because the GUI and the engine are separate processes (and therefore threads).

The actual toolpath generation is the most expensive step and this will be the hardest part to do so. I believe it should be possible to do the support structured in a separate thread. The main reason why this isn't done is because it adds a whole lot of complexity (and makes debugging way, way harder).

 

[pm_dude 27]

Yes this is what I think too. In most cases the gain wont be huge time saver but just to give you an example I'm printing an item that require supports and the print time jump from 19 hours to about 40 when adding supports. The slicing time take about 10-15 minutes. The first slicing works the next one will never end (thats weird).

If the toolpath could work in reverse mode you could split this process in 2. One half of the model go upward like normal and one half go downward from the middle to the bottom. This way you can have a known starting point for both. Or there would be a need to be able to tell it where to end the layer. Or add retraction toolpath to bring 2 sections together.

I'm sure you guys already talked about these options in the past and threading can be a pain in the butt...

[Daid 297]

The main reason why I'm not using multi-threading is to save in code complexity. Not because it cannot be done. There are a few loops in the engine that could be multi-threaded with ease. Which would run about 60% of the code threaded instead of single threaded.

 

[pm_dude 27]

Between that and new features I prefer you guys work on those awesome new features

[pm_dude 27]

But at some point it will probably become relevant to do it considering new pc add cores instead of boosting clock speed.

[Daid 297]

But at some point it will probably become relevant to do it considering new pc add cores instead of boosting clock speed.

 

Oh, most certainly, but I rather delay this addition. Also because there is lots of work on compilers being done to make this easier (openmp) but this isn't fully supported by all my target platforms yet.