So, drilling down to KUKAs specifically. You have two options: run an application in Windows in parallel with the robot's core processes, or create a background task in the robot itself, in the robot's own language.
All robots used scheduled multitasking of some type. In KUKAs, the realtime OS (VxWOrks) runs in parallel with Windows (which only runs the user interface), but VxWorks has full priority over system resources. Inside VxWorks, the KUKA System Software (KSS) runs multiple tasks on a fixed schedule. Every task (Motion update, I/O update, background task, etc) gets a fixed portion of the overall "IPO Cycle".
The IPO cycle has been 12ms for about 30 years. In that time, the processor clock cycles have gotten faster, reducing the per-line execution time of any non-motion code. So, it used to be that a long background task would only run some % of its total loop during each "slice" of the IPO "pie," and would be paused between slices (and resume at each slice). These days, it's possible to run non-motion code very quickly. But if your task takes longer than the "slice", it will take multiple IPO cycles to complete. Also, even if the code runs in 10nanoseconds, you can only get an I/O refresh once every 12ms. And handling asynchronous TCP/IP or UDP from a background task is entirely possible, but can be a little bit tricky. You'll want to program in state machines, with no wait states.
The robot programming languages also generally lack of lot of tools that high-level languages all have -- for example, KRL has no POW function, and no binary shift functions. You have to write your own loops to handle that.
Adding a Windows task has other issues. If it ever conflicts with VxWorks over resources, you'll probably crash the robot. At best, you'll get lag. So any Windows-side app would have to be small, self-contained, not require the latest Windows patches or updates, and not used direct hardware resources like IRQs and DMA.
Then there's the root issue of any parallel-processing operation: dividing up the task into bite-size chunks, then re-assembling the results. That you would probably have to handle entirely outside the robots.
Hi Skyfire and HawkME,
thanks to both for your answers and sorry for my late reply. We had some interviews now and got more or less the same feedback regarding different OSs, accessibility, spare cycles, safety etc. and so on.
We also found that Siemens recommends a maximum task runtime of 70% of the set cycle time. However, you can set the IPO time individually with the restriction, that the maximum task time for operation does not exceeds the time set. Here we could try to analyse if a smaller time and faster I/O updates make the whole operation more attractive.
However, it would be great to know the potential of the whole idea. Thats why we started to make thoughts about an ideal use case, that hypothesizes a homogenous and relatively new manufacturing line with no accessibility and connectivity issues. We also found out in interviews, that total runtime during normal operation hours is sometimes only 50%. That means, in the other 50% of time, other calculations would not affect the safety of line operation.
Thats why I looked for any clustering of robots to one network in such a case, but as expected, I found nothing. That's why I have the question if you know of any projects that may have had a look at this question? In such a case, i.e. Siemens CPU 1518-4 PN/DP would be free that is normally applied for high performance calculations. Do you see any potential there (in such a best case of having state-of-the-art HW) or are still the points above predominating?
Best regards and still a happy new year!