KRL Undocumented Features

[schampneuf]

Hi,

I suggest that we could launch this topic in order to list all known KRL undocumented features.
I will begin with INVERSE and FORWARD :

INVERSE ===
E6POS DESTINATION ; Point we want to reach
E6AXIS DESTINATION_AXIS
INT ERRORCODE

$TARGET_STATUS=#SOURCE
ERRORCODE=0
DESTINATION_AXIS=INVERSE(DESTINATION,XHOME,ERRORCODE)

IF (ERRORCODE<>0) THEN
    ; Go to Destionation
    PTP DESTINATION
ELSE
    ; Can't reach destination
    HALT
ENDIF

FORWARD====
E6POS DESTINATION
E6AXIS DESTINATION_AXIS ; E6AXIS we want to reach by a LIN motion
INT ERRORCODE

$TARGET_STATUS=#SOURCE
ERRORCODE=0
DESTINATION=FORWARD(DESTINATION_AXIS,ERRORCODE)

IF (ERRORCODE<>0) THEN
    ; Go to Destionation
    LIN DESTINATION C_DIS
ELSE
    ; Can't reach destination
    HALT
ENDIF

WHAT ELSE  

[schampneuf]

Bad idea ??

[SkyeFire]

No, not a bad idea at all.  Everyone's just busy.  :)

How about LIN_REL?  This command everyone knows, and it's well documented.  Except that few people seem to know about the #TOOL switch for it.  I've never been able to find it in any manual I own, but learned about it via word-of-mouth.

Here's how it works:
LIN_REL {Z 100} will move the TCP 100mm along the +Z direction of the current active base.  Easy.
LIN_REL {Z 100} #TOOL will move the TCP 100m along the +Z direction of theactive tool.
It's that easy.  Works for X,Y,Z and A,B,C.  Basically, anything you can do with the LIN_REL tool you can do with LIN_REL #TOOL.  The #TOOL switch just changes the reference frame the controls the movement from the Base to the Tool. 

[SkyeFire]

Then there's INV_POS.  I honestly don't know exactly *what* this one does, though it appears to invert a POS or FRAME variable in some way.  I don't know what algorithm it applies, but I've heard of it being used for certain vision applications to apply offsets from a robot-mounted camera.

It works like this:  POS2=INV_POS(POS1)

If POS1={100,100,100,0,0,0} then POS2 will be {-100,-100,-100,0,0,0}.

If POS1={0,0,0,90,0,0} then POS2 will be {0,0,0,-90,0,0}

if POS1={0,0,0,90,90,0} then POS2 will be {0,0,0,-90,0,90}

If POS1={100,100,100,90,90,90} then POS2 will be {100,-100,-100,0,-90,0}

It seems pretty obvious that INV_POS is doing something like the geometric operator (matrix math), but as I said, I don't know exactly what algorithm it applies. 

[bert]

That looks like it's doing a matrix inverse on the position. All robot positions are treated as transformation matrices internally in the controller, and this is inverting that matrix.

In your example where POS1 is relative to the current baseframe, then INV_POS will tell you where the baseframe is relative to POS1. Like you say, pretty much what the geometric operator does, but with a bit more control over what frames are being used.

I was looking for something like that last year - in fact, I ended up writing a function to do the exact same thing inside the controller. If only I'd known...

[markopo]

Hi all.
I want to add some. maybe it's is  totally not  in a main stream but for someone could be usefull. Imagine You want to operate robot just in automatic mode or in hand mode. That's propably is to do just with a soft but I have a more sophisticated (read - workers are smart with panels ;)
So I have more electical answer for this problem.
When You open KRC1 cabinet from Kuka You will see ESC card with a at least 32 nodes in few relays.
There are a dip - fix ( microswiches). To find out them You have to be very patient. On this board X7 is responsible for Drive - on.  You can't put a signal on main K1 in a Powermodul. Simply by swich it on You make some bridge with (test mode and automatic mode) so no mother in which state You are. If You disconnect it ( for example You are only one person who in a firm have a experience with a robo technik, and You want that noone start up robot when You're gone). Robot is silence as a stone.

If You have more than 6 axis in Robot.( that is common mistake took by servis) You have to connect Dip - fix X9. This swich turn off Drive off too when You use A1 to A6.

X8 are in a line with K2 from Power modul so You haven't Drives if there are chaging resistors. X8 turn off external start for example from Interbus via K14 too.

Maybe I'm wrong so I'm waiting for some discussion.

Greets from frozen Poland.
Mark

[asimo]

Hi,

Thank you SkyeFire for the INV_POS function. Like bert, I had to program it myself once. Here is a small example of what you can do with it:

Code:

; Go to point P1 calculated with respect to base 2 from base 1
PTP INV_POS(base_data[1]):base_data[2]:P1

In other words, combined with the geometric operator, you can use it to determine the coordinate of a position in a different base from the one the point was recorded or defined.

[SkyeFire]

Asimo:  Whoa.  Okay, I can see just how powerful that could be -- I've wanted something like that more than once in the past.  In fact, it could come in handy for something I'm working on right now. 

Bert:  Leave it to you to recognize the exact matrix algebra function on sight.     I knew it had to be some kind of matrix math, but what exactly it was doing escaped me.
I am puzzled about one thing, though.  A bit of quick Googling implies that matrix inversions only work on square matrices.  An POS or FRAME variable in KRL only consists of 6 elements, though, which it's hard to make a square matrix from.  It looks to me as if, in order to make a square matrix, we would need three additional elements (to produce a 3x3 matrix), which must be derived from the original six elements somehow.  Or am I overlooking something obvious?
So, anyway, if I have a POS variable of {X,Y,Z,A,B,C}, how would it appear if formatted in matrix form?

[asimo]

SkyeFire,

Actually, yes, I think that INV_POS is simply a matrix inversion. It's a homogeneous transformation with homogeneous coordinates. This simplifies the transformations among coordinates frames using 4x4 matrices. So they combine translations and rotations using XYZABC to go back to the reference position.

[potis]

A tip for changing the base frame that is used to the palletizing projects. you can program a point that is saved with base 1 for example and you just change the values of that base.

base_data[1]=$nullframe   ;(makes the frame equal to the base nullframe)
base_data[1].Z=starting_offset     ;(the height of the base to start)

and

base_data[1].Z=base_data[1].Z + offset   ;(adds the offset we want for the layers)


of course every variable can be changed (x,y,z,a,b,c,)

 

[SkyeFire]

I've mentioned this elsewhere, but:

KSS versions 5.2 and higher now support a new variable declaration:  CONST.  This declaration allows you to set "variables" whose value cannot be changed without editing the .DAT file.  It works like so:

DECL CONST INT X=10

X will be permanently set to 10, and attempts to change it from inside the program or the variable monitor will generate an error.

CONST also works with GLOBAL, as shown:

DECL GLOBAL CONST Y=20

[mookie]

As Skyefire posted,

I am using this feature to insure that the positioning of my robot is always to the same position. For whatever reason, when i command a position, it has the ability to be overwritten by the robot

for instance i could do

DECL e6pos MyPartnerisNuts

MyPartnerIsNuts = $NullFrame
MyPartnerisNuts.Z =100



LIN MyPartnerisNuts


if i ran this, it may show that the z value is 99.997


so i you declare it as a constant (which is actually available all the way back to 4.1)

it will stay the same. In our applications, the user will never touch up positions from the teach pendant so i need to insure that i keep the best numbers that i can.

[Weinreich]

dunno if this is too basic, but here's a list of the most common functions of the Kuka BAS.SRC

  BAS(#INITMOV,0) ; Basic initializasion of axes
  BAS(#ACC_CP,X.X); Set Acceleration for linear motions
  BAS(#ACC_PTP,X.X); Set Acceleration for axis motions
  BAS(#VEL_CP,X.X); Set Speed for linear motions
  BAS(#VEL_PTP,X.X); Set Speed for axis motions
  BAS(#TOOL,X); Change TOOL
  BAS(#BASE,X); Change BASE

The easy way to modify settings the "right" way, getting all parameters set.

[bert]

I am puzzled about one thing, though.  A bit of quick Googling implies that matrix inversions only work on square matrices.  An POS or FRAME variable in KRL only consists of 6 elements, though, which it's hard to make a square matrix from.  It looks to me as if, in order to make a square matrix, we would need three additional elements (to produce a 3x3 matrix), which must be derived from the original six elements somehow.  Or am I overlooking something obvious?
So, anyway, if I have a POS variable of {X,Y,Z,A,B,C}, how would it appear if formatted in matrix form?

Another timely reply I'm afraid - more travel to random places...
Also, sorry if this is going a bit of topic but:

You may be overlooking something, but obvious it isn't. You need to Google for "Homogeneous transformation matrix" ;)

The {X,Y,Z,A,B,C} that you see in the gui is actually stored as a 4x4 square matrix internally. This makes a sequence of transformations easy to combine through multiplication and to invert through matrix inversion. There are very well defined and well documented ways for converting these matrices to human understandable rotation conventions and back again. In fact, using matrices also makes it easy to convert between different orientation conventions eg. ABB quaternions, Fanuc WPR, Kuka ABC etc or to calculate the position of frames relative to other frames.

Anyway, I'm going to stop before I go any further off topic...

[jseger]

bert is smart