Workspaces

    KR 120 R3200 PA
    KRC4 KSS V8.3.39

    I'm trying to understand workspaces. The documentation is quite straightforward and shows how both Cartesian and Axis-specific workspaces can be configured. We are told that a Cartesian workspace is a cuboid whose location and dimensions are related to the WORLD coordinate system. So far so good, however I'm having a problem with the definition of the point that may violate the workspace. Depending on the mode, the documentation refers to either the TCP or flange, and in one case also the wrist point.


    In the case of TCP, does that include the current $TOOL? Can it be that the choice of TCP, flange or wrist point can be defined elsewhere?

    in the past, workspaces only looked at one point - TCP of the current tool....


    this has changed however, your KSS checks BOTH center of the flange AND the current tool TCP.
    evaluation is always OR type for those two points.


    result of this "more than one point" space evaluation is that INSIDE and OUTSIDE are no longer complements (opposite).
    for example if one of the points is inside the space, and other is outside, then output associated with the workspace will be TRUE regardless if Mode setting is #INSIDE or #OUTSIDE.


    In KSS8.3 user cannot change behavior, but in KSS8.5 there is a bit more flexibility.

    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

    PM, Thank you for your comprehensive explanation, that aspect makes sense now. :icon_smile:

    Sorry, but now that leads to more questions. I notice that both:-
    $CYLWORKSPACE[1]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0,Z1 0.0,Z2 0.0,R 0.0,MODE #OFF,REFERENCE #WORLD,STATE FALSE}
    and
    $AXWORKSPACE[1]={A1_N 0.0,A1_P 0.0,A2_N 0.0,A2_P 0.0,A3_N 0.0,A3_P 0.0,A4_N 0.0,A4_P 0.0,A5_N 0.0,A5_P 0.0,A6_N 0.0,A6_P 0.0,E1_N 0.0,E1_P 0.0,E2_N 0.0,E2_P 0.0,E3_N 0.0,E3_P 0.0,E4_N 0.0,E4_P 0.0,E5_N 0.0,E5_P 0.0,E6_N 0.0,E6_P 0.0,MODE #OFF,STATE FALSE}
    are declared in R1\Mada\$machine.dat, whereas:-
    $WORKSPACE[1]={X 0.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0,X1 0.0,Y1 0.0,Z1 0.0,X2 0.0,Y2 0.0,Z2 0.0,MODE #OFF}
    is in Steu\Mada\$custom.dat.


      • Does that imply $WORKSPACE[n]  is not write protected, so that the variables in the structure may be written by the program? If so, then $CYLWORKSPACE[n] and $AXWORKSPACE[n] are fixed.

      • Why is there an origin reference in $CYLWORKSPACE[n].REFERENCE #WORLD existing but not in $WORKSPACE[n] which must be explicitly #WORLD? Then what are the other possibilities of the origin reference?

      • Cylindrical workspace is not described in the documentation. Can I assume the same origin definition as in Cartesian workspace (but perhaps with a non-world origin) with the cylinder having it's axis in Z with the centres Z1 and Z2 and the radius R?

      [li]In my example, the declaration of $WORKSPACE[n].STATE FALSE  seems to be missing. Or is this by design?

    i notice that you are asking questions rather than testing your theories on a robot. why?


    * $WORKSPACE[] is not write protected
    * it is what it is... ask Kuka RnD. probably compatibility is a big factor so Cartesian workspaces that existed since Adam and Eve don't have same functionality as the new and still undocumented cylindrical workspaces
    * STATE is updated at runtime, no reason to store last state

    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

    Quote from panic mode


    i notice that you are asking questions rather than testing your theories on a robot. why?

    Thank you for your answers, all understood now. :icon_smile:

    I'm not testing on a robot until I can get back to it next week. As I won't have much time to play around due to production, I wanted to get as much prior knowledge to enable an expeditious implementation of the workspace function.

    I wondered if the Cylindrical workspace could be used with the origin reference as #TOOL which then could include the outline dimensions of the gripper or weld gun etc. Then one could have two workspaces that can interact with each other. This may be similar to Safe Operation which uses up to six spheres for the Safe Tool. But this is conjecture which until there is some solid documentation, is perhaps not useful.

    Now I'm waking an old thread back from the dead!

    A previous ABB-Programmer is having a couple of questions:

    1. Workspace & Axisworkspaces can be defined via Misc->Workspace monitoring->configuration.

    Where can i define cylindrical workspaces in the same way? Or is the only option to define it in $machine.dat directly?

    2. In this menu I can also asign an output-signal to the asigned workspace. Where is this Signalconnection "defined"? I can't find it in either $machine.dat or $custom

    Also: What does

    Quote from Fubini

    Yes no HMI support here unfortunately.

    Alright. :smiling_face:

    The AXWORKSPACE & CYLWORKSPACE-definition contains a "STATE FALSE" while the "regular"/Cartesian workspaces doesn't.

    Not sure what this parameter is?

    At first sight I thought this was the signal-connection but:

    1. When I tried to enter a signal-number instead of FALSE, like "1" for example it generates a syntax-error.

    2. The Cartesian workspaces also has a signalconnection so when I can't find it in the definition of the $WORKSPACE, I guess that's not the signal.

    Code
    $AXWORKSPACE[1]={A1_N 0.0,A1_P 0.0,A2_N 0.0,A2_P 0.0,A3_N 0.0,A3_P 0.0,A4_N 0.0,A4_P 0.0,A5_N 0.0,A5_P 0.0,A6_N 0.0,A6_P 0.0,E1_N 0.0,E1_P 0.0,E2_N 0.0,E2_P 0.0,E3_N 0.0,E3_P 0.0,E4_N 0.0,E4_P 0.0,E5_N 0.0,E5_P 0.0,E6_N 0.0,E6_P 0.0,MODE #OFF,STATE FALSE}

    STATE allows activation an deactivation of the workspace on the fly. E.g. inside your program.

    Signals are if I remember correctly predefined. I can not look it up right now but I think they were called $AX_WORKSPACESTATE1 or something quite similar. You need to assign a $OUT[x] channel to them. Could be defined either in STEU/$machine.dat or $custom.dat if not directly in R1/$machine.dat. At least one of these 3 files should be the one. Something quite in the back of my head tries to tell me $custom.dat but usually my memory tries to trick me ...

    Fubini

Advertising from our partners