KUKA RSI: Get $TOOL & $BASE

Does your tool and base change?

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.

Don't forget you can always ask kuka tech support, some clever guys there that know the tech packs far more than is explained in the documentation

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.

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.

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.