[mvistein]

I'm currently developing a plugin for RoboDK (C++, Qt) which uses the internal RoboDK API. It would be nice to offload some expensive calculation tasks into a separate thread. However, it seems that the API is not inherently thread-safe, at least some method calls crash if called from another thread than the main/GUI thread. Is there any documentation available which methods of the API are thread-safe and safe to call from other threads? Or should the API not used at all from different threads?

Best regards, Michael

[Albert]

Good question... In theory, the RoboDK API via the plugin interface (C++, Qt) does not support multithreading. However, you should be able to use some functions of the plugin interface without issues.

For example, you should not have issues with SolveFK, on the other hand, SolveIK may give issues. We could make additional functions thread safe.

If you can tell us more details about what you need to speed up we may be able to help you better.

[mvistein]

I'm adding a large number of targets to a station and into a program, so I think these are the kind of operations which cannot be done from different threads.

It's not really a big issue, rather more a cosmetic thing that the UI gets unresonsive during loading the targets. I'm already using QApplication::processEvents(); calls regularly so that at least a progress bar gets updated from time to time. I was just thinking whether there is another (better?) way of doing this, which would potentially even allow to parallelize program generation in the future. But right at the moment the single-threaded performance is still good enough (opimizations like hiding instructions and targets in the programs have already been applied).

[Albert]

Adding a new target will provoke a render event which can be slow. Also, this operation should be single threaded.

However, a workaround to speed things up is to block render events while you make a lot of operations:

Code:

RDK.Command("Render", "0"); // Turn Off 3D view render

//... add targets, items and/or other operations

RDK.Command("Render", "1"); // Turn On 3D view render (it does not provoke a render event)
RDK.Render(); // Update the 3D view (provokes a render event and it should display the udpated scene)

This is not properly documented but should work well. Just make sure to activate the Render back on, otherwise the 3D view will not show anything.