KUKA RSI: Get $TOOL & $BASE

  • Hi All,


    RSI: 3.3.3.267

    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.


    Thanks

  • AD
  • 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.

    Code
    IF VARSTATE("$BASE") == #INITIALIZED THEN
    $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
    ENDIF

    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:


    DEF VAR_INIT_TEST()

    DECL FRAME f

    f = {X 0}

    $BASE = f

    IF VARSTATE("$BASE")==#INITIALIZED THEN

    $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

    ENDIF

    END



    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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now