• Hi All,


    KSS: V8.3.320/KUKA8.3

    I have been developing an application to communicate with a KRC4 controller over RSI. I have developed an external UDP Server application (running on my computer) that talks to the robot and fetches some data such as cartesian and axes positions, etc. I have gone through the manuals and tried to find a way to send the real-time values of actual TOOL and BASE to the external application from the robot. However, in the manual and the examples, I could not find any RSI block that I can use in RSI Visual to get these system variables and send over the bus.

    If anyone has achieved this, then please help me with the idea of programming it.


  • IIRC, there are RSI objects that can access the $SEN_PREA system variables. You might be able to have the SPS assign $TOOL and $BASE values to those variables.

    Thanks for the suggestion. I did exactly the same. However, when the submit gets launched or a new value to the current TOOL or BASE gets assigned, it throws an error saying invalid X value or invalid Y value, These errors are random.

    With KRC4, I observed that it throws the above-mentioned errors when the TOOL and BASE are assigned to unknown. Once a valid value is assigned, it works fine. However, when I run the program and current TOOL and BASE get reassigned, the error comes back randomly. I will have to dig into it and find a workaround.

  • Yes, under certain conditions (cold boot, Program Cancel), $BASE and $TOOL get set to Uninitialized. You get around this by using ON_ERR_PROCEED in your SPS -- if an attempt to copy $BASE or $TOOL into $SEN_PRES returns an error, skip it and keep going.

  • Sorry for the late reply.

    Thank you SkyeFire for the heads up. For now, I put protection in the code using VARSTATE.

      $SEN_PREA[1] = $BASE.X
      $SEN_PREA[2] = $BASE.Y
      $SEN_PREA[3] = $BASE.Z
      $SEN_PREA[4] = $BASE.A
      $SEN_PREA[5] = $BASE.B
      $SEN_PREA[6] = $BASE.C

    I tested the code and it works fine.

  • that may work for most cases but ... it is not ideal. you are assuming that someone will always initialize all elements. that is not a safe assumption. it is better to check each element individually if initialized....

    if you don't believe me, simply when you see $base not initialized (shows up as ? on the smartPad), you can try to give it value such as { X 0} using either program or variable monitor.

    or create new program with some test code like this:



    f = {X 0}

    $BASE = f


    $SEN_PREA[1] = $BASE.X

    $SEN_PREA[2] = $BASE.Y

    $SEN_PREA[3] = $BASE.Z

    $SEN_PREA[4] = $BASE.A

    $SEN_PREA[5] = $BASE.B

    $SEN_PREA[6] = $BASE.C



    although you only initialized one element add other five are still not initialized, your check will say that $BASE is initialized (which is not exactly true) and the program will crash when it reaches line 3.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • One problem with using VARSTATE in the SPS on certain system variables like $BASE and $TOOL is that the Level 0 interpreter (SPS) and Level 1 Interpreter ("normal" programs, usually with motion) are completely asynchronous.

    This means that, even if VARSTATE shows $BASE as being Initialized, it's possible for $BASE to change to an uninitialized state in between your SPS's VARSTATE check and the next line. I had this happen way back when I first tried doing something similar to what you're attempting now. If you roll the dice often enough, eventually you'll come up snakeeyes.

    The more robust approach is to place a ON_ERR_PROCEED immediately before each $SEN_PREA= line. Maybe follow it with a command to check the $ERR return state and, if there was a fault, fill the $SEN_PREA with deliberate nonsense (like -99999 or something) that will act as a signal to your server to not trust the $SEN_PREA values.

Advertising from our partners