hello, I've been looking for a way to implement a multithreaded program in a robot (1 program responsible for movement and the other for communication and e.g. counting values in the background in each loop) I can't find appropriate examples in the documentation and forums.
Does anyone have the relevant documents? / examples?
multi-threaded program in kuka KRC4 robot (KSS 8.3)
-
postek -
March 13, 2023 at 1:08 PM -
Thread is Unresolved
-
-
Roland Keller
March 13, 2023 at 1:12 PM Approved the thread. -
multithreaded programming in KRL does not exist. program is list of instructions that are executed sequentially. that is it.
the next point is about need for that - what makes you think this is needed? if you have two things that need to happen "simultaneously", how long do they both last? how much of it could be "overlapping"?
for example motion from point A to point B is something hat may take some time (few seconds).
incrementing counter also takes time but... this takes very little time. so incrementing parts counter for example is done in the same loop (sequentially) with motions. if the incrementing counter was also a slow process (something that took several seconds) that would of course have negative impact on motion but... that is just not the case. incrementing is done in a microsecond. so whether it is done or not, it has no noticeable effect on motion (a process that takes few seconds).
in other words it is perfectly suitable to do something like
if the communication is something that need to take place continuously - regardless if motion program is selected or running, then you can use background process for that. it is called Submit interpreter and runs independently of robot program.
-
The closest KSS 8.3 comes to "multithreading" is the dual Interpreters -- Robot (Level 1) and Submit (Level 0). The Robot interpreter is exactly what the name implies, has control over the robot arm motion, and executes non-motion commands in between motions, plus interrupts, triggers, and other extras.
The Level 0 (Submit, or SPS) interpreter runs independently of the L1, and can execute non-motion commands only (aside from special cases like asnych external axes). The SPS also cannot execute commands that would influence motion (changing $TOOL, for example), with the single exception of the override speed (either $OV_PRO or $OV_APPL).
The SPS has some rules. It runs normal KRL code, but in a constant loop, and the SPS should never contain any "pausing" instructions -- no WAITs, for example. This makes writing sequential code in the SPS rather different than in the L1, often depending on state machines. The "mental model" for programming in the SPS is more like programming a PLC.
By default, KRCs run the program SPS.SUB in the L0. This program serves as a skeleton for adding user code to. Code in the INIT section only runs once on reboot (or if someone manually cancels and re-starts the SPS), then the LOOP section executes in an endless loop as fast as it can. There is KUKA-system code already in place in the default SPS, and there are Folds allocated to hold User INIT and LOOP code. User-generated code should stay in these Folds, as they are protected in the event that a new KUKA Tech Pack is installed that adds code to the SPS.
-
I actually managed to complete the task without threads. I also used the "continuous" motion function during the calculations. Thanks a lot for your tips!
Sometimes you can make your life difficult with overly complex programs as you started learning programming on high-level languages.