Mapping I/O KRC4 | Get Current Cartesian Position

  • Hi everyone, i'm doing some test with a KRC4 controller V8.3.378 with WorkVisual 6.0.


    I'm totally new in KRL and krc4 (curious student),

    I'm searching to get in real time, the X,Y,Z position of the robot on my HMI. According to implant these data on my HMI in need them to be on an output and not just as global variable.

    That's why i'm searching to assign an output taking the value of $POS_ACT in real time.


    So I've read a lot of documentation showing how mapping I/O with WorkVisual but i dont really get how to declare and assign i/O.


    So I've export my project from the Smartpad and open the Wws active file on WorkVisual.

    I've searched for a file such as iosys.ini in KRC2 with the declaration of I/O and found that WorkVisual is able to map them directly.


    According to the I/O panel of WorkVisual, I can see the different digital outputs but no names are attributed, so i go to the var_const.dat to see if some outputs are use or not.


    A lot of outputs is shaded, so i guess that they are exchangeable because not uses.


    On the robot, the outputs from 2160 to 2271 was already "mapped" (connected and declared but never used). So i'm trying to use these one to get the position.

    To assign these outputs, i write this code to the var_const.dat and comment the outputs non used :



    And i also add this code to the SPS.SUB to get these informations in real time :

    Code
    POSXact = $POS_ACT.X
    POSYact = $POS_ACT.X
    POSYact = $POS_ACT.X

    But there I've some questions without answers…


    1. Is the assignement well done ?

    2. Is this assignement enough for an output ? Do i have to declare them in the config.dat too ?

    3. Is it possible to get the position with boolean outputs ?

    4. The coordinate range of each is between 500 and 2500 max for each axe so 32bit is too much ?

    5. Is there something more to do ?


    I think I missed something, thank you for your indulgence and your time,

    Sincerely,

    Lucas

  • 1. Is the assignement well done ?

    2. Is this assignement enough for an output ? Do i have to declare them in the config.dat too ?

    3. Is it possible to get the position with boolean outputs ?

    4. The coordinate range of each is between 500 and 2500 max for each axe so 32bit is too much ?

    5. Is there something more to do ?

    1. Well enough

    2. No. If the SIGNALS are DECL'd using GLOBAL, you do not have to add them to $CONFIG.DAT

    3. I'm not sure what you mean. Each "group" output is simply a collection of boolean outputs. So it would be possible, using Bitwise math, to set each boolean individually, but it would not be worth the extra effort

    4. That depends. You need to keep in mind, the SIGNALs are integer values. So if $POS_ACT.X is 1.23, your code as written will only send 1.0. For integers, 16bits would be enough to encode a value of 2500. But how are you handling sign bits? KRL only automatically applies sign (+/-) to 32-bit SIGNALs -- SIGNALs smaller than 32bit are treated as always positive integers. It is possible to encode real/floating-point values onto 32bit SIGNALs using the CAST_TO function (Panic Mode wrote several examples in the forum archives)

    5. Yes. $POS_ACT has been superceded by $POS_ACT_MES. Also, neither variable contains valid data at all times -- on initial boot, or after a program cancel, they are "declared" but not "initialized". Which means that your SPS code will crash. Each of your lines in the SPS should be preceded with an ON_ERROR_PROCEED to avoid crashing the SPS.

  • Thanks for answering Skyefire,


    The 3th question join the 4th. I was asking myself if the association of the 32 bits was able to get the Int position, but yes, math will help me.


    5. I see and will make the change, so is there a way to get the position in real time without crashing the SPS ? As i understand, except using ON_ERROR_PROCEED every line, this will not work. Should i put these lines (from SPS.SUB) in an other file call during the process of my program ?

  • I guess this is different for KRC4,

    No. That thread is talking about the axis positions -- the joint angles. Those are accessed via $AXIS_ACT or $AXIS_ACT_MEAS. Unlike $POS_ACT_MES, which is Cartesian data, $AXIS_ACT_MEAS always contains valid data. This is the same for KRC1, KRC2, and KRC4.


    The reason $POS_ACT_MES does not always contain valid data is because the values change depending on which Base and Tool are currently active. And there are certain circumstances where no valid Base or Tool are active.


    Since the motion control task and the SPS update asynchronously to each other, there is no way to guarantee that $POS_ACT_MES contains valid data the moment the SPS executes POSActX=$POS_ACT_MES.X. Even performing a validity check on $POS_ACT_MES one line earlier is not a guarantee, since $POS_ACT_MES can change state between one SPS line execution and the next. Using ON_ERR_PROCEED is the only way I'm aware of to ensure that the SPS never crashes on this condition.


    You can also use $ERR.NUMBER immediately after the assignment in the SPS to check if the assignment succeeded or not, and if not, assign a value to POSActX (et al) like -9999, to indicate to the remote device that $POS_ACT_MES currently holds no valid data. The BAS.SRC routine in your robot contains examples of using the ERR functionality in a similar fashion:

    Code
      ON_ERROR_PROCEED
      VEL_CHECK = $VEL.ORI1
      IF $ERR.NUMBER > 0 THEN
          $VEL.ORI1=DEF_VEL_ORI1 ; swivel velocity
          ERR_CLEAR($ERR)
      ENDIF
  • Thanks SkyeFire your time,


    As i understand, my sps must be like this,

    But there is something disrupting me,

    Code
    IF $ERR.NUMBER>0 THEN

    If the ERR is >0 then, the error can be everything, this can be a problem ?

    I've checked the KSS System Message Manual and found such number error like


    - 1418 : <X,Y,Z,A,B,C> Base not defined

    - 1419 : <X,Y,Z,A,B,C> Tool not defined

    - 1422 : Reading < Variable $> Incorrect value


    So my question is the following one :

    Should I identify the error codes that relate to my case? Or it does not pose a real problem of safety?

    I'm afraid to bypass another error by leaving >0


    Thanks in advance

  • Hello MOM,


    I see,

    then do you think these two error code are enough for my case ? :thinking_face:

    I'm searching in the KSS Manual in case of similar error,


    Thks


    NB : I forgot to tell you that this robot is part of a cell with a press and security elements, that's why I would like to avoid passing any erroneous code

  • Lucasss

    Changed the title of the thread from “Mapping I/O KRC4” to “Mapping I/O KRC4 | Get Current Cartesian Position”.
  • depends on your definition of real time. submit is slow and low priority task.

    you can use RSI or FSD instead of IOs and submit. then you get position data down to 1ms.

    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

  • Should I identify the error codes that relate to my case? Or it does not pose a real problem of safety?

    I'm afraid to bypass another error by leaving >0

    Using ON_ERR_PROCEED only applies to the next line of KRL code -- so ON_ERR_PROCEED on Line 1 only applies to Line 2. By line 3, the ON_ERR_PROCEED "trap" has "expired". So the odds of any other error being "caught" is extremely low. Any error that occurs on a line that is not immediately preceded by ON_ERR_PROCEED will be be caught by the system error handler and halt the program. Also, ON_ERR_PROCEED will not affect errors like collisions, E-Stops, communications failures, etc.


    It does not create a safety issue, b/c none of this code is safety-qualified, and as such should never be used for safety-critical interlocks.

  • depends on your definition of real time. submit is slow and low priority task.

    you can use RSI or FSD instead of IOs and submit. then you get position data down to 1ms.

    Thanks @PanicMode but i'm was searching for a free way to do it, just for some program tests not for the overall operation.

    But it's likely what i'm trying to do, i will consider the fact that it's not really possible for free,


    Using ON_ERR_PROCEED only applies to the next line of KRL code -- so ON_ERR_PROCEED on Line 1 only applies to Line 2. By line 3, the ON_ERR_PROCEED "trap" has "expired". So the odds of any other error being "caught" is extremely low. Any error that occurs on a line that is not immediately preceded by ON_ERR_PROCEED will be be caught by the system error handler and halt the program. Also, ON_ERR_PROCEED will not affect errors like collisions, E-Stops, communications failures, etc.


    It does not create a safety issue, b/c none of this code is safety-qualified, and as such should never be used for safety-critical interlocks.

    Thanks SkyeFire,

    I didnt catch the fact that only the error of the current line is aim,

    I guess that the code i post will make me more error than data i can use,


    One option (especially for press lines) could be a soft plc (from kuka) having direct access to actual robot position in real time

    Thanks Mom, did you have something in mind about a soft plc ? Something like mxAutomation from KUKA ?

  • Update : General conversion between different coordinate system types (KUKA, Fanuc, ABB, etc) - Page 2 - Robot Geometry, Linear Algebra, Forward and Inverse Kinematics - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)


    I find this post questioning about position with axis and the conversion from matrix to coordinates.

    Do you think it's possible to get the $AXIS_POS_MES in "real time" (around 10ms) thanks to I/O and then convert it through the HMI using maths ? (even if the coordinate are according to the world base)


    Thx in advance, :winking_face:

    Edited once, last by Lucasss ().

  • not sure if this was resolved or not but your initial post shows signal declarations that are 33-bit wide. that will not work of course. maximum width for signal is 32-bit.

    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

Advertising from our partners