How would I access the full base name of lets say... BASE 10?
I enter BASE_NAME[10,1] and it gives me the first CHAR of the actual base name. Is there a single command just to pull the entire CHAR array?
How would I access the full base name of lets say... BASE 10?
I enter BASE_NAME[10,1] and it gives me the first CHAR of the actual base name. Is there a single command just to pull the entire CHAR array?
Hi,
KRC4
KSS 8.3.X
I was wondering if it is possible to access the "Base system name" of a given base and change it programmatically. I know how to access the FRAME (XYZABC) of the base with BASE_DATA, but want the actual string or char array variable.
Any thoughts?
Thanks!
The values I get from my interrupt are what I need them to be. I just do not understand why I need two SLIN commands in order for the interrupt to trigger. I imagine it has something to do with my $ADVANCE value, but I set it to 1 and set it to 5 and it gave me the same result...
Ah my apologies... the interrupt is declared higher up in the main program (a part I did not copy and paste).
It is declared as "INTERRUPT DECL 1 WHEN $IN[102]==FALSE DO MYTRIGGER()"
Yes, I understand I am using consecutive splines with the same target coordinate, but the interrupt only works when I have both of those identical commands in there. If I comment one out, the interrupt never gets triggered. When I include both spline commands consecutively it works just fine.
Hi all,
KSS 8.3. and KRC4 controller
I have a seemingly basic question regarding programming an interrupt. Below is the code which I am using. My issue arises in the SLIN (0,0,0) line and then the following SLIN (0,0,0) line. If I comment out the second SLIN motion line (the bolded line), then the interrupt does not turn on and is not active. However, if I keep it in the code the robot appears to behave normally while triggering the interrupt. I figure this has something to do with my advance run pointer, but cannot for the life of me figure out what is going on. When I run the code slowly it appears to run this second SLIN (0,0,0) line several times before proceeding to the "Probe_Rough_Loc()" subroutine.
;Set current base to nominal enclosure base(5)
T = 5
BAS(#BASE,T)
T = 3
BAS(#TOOL,T)
WAIT SEC 2
;Move Z forward to z +200mm in base 5
SLIN {X 0, Y 0, Z 0} WITH $VEL.CP =0.05 C_DIS
;SLIN {X 0, Y 0, Z 0} WITH $VEL.CP =0.05 C_DIS
WAIT SEC 2
;HALT
;Set base to $NULLSPACE (world) coordinates
T = 0
BAS(#BASE,T)
WAIT SEC 2
;Probe Z distance at center of part
PROBE_ROUGH_LOC()
DEF PROBE_ROUGH_LOC()
DECL INT T
T = 5
BAS(#BASE,T)
INTERRUPT ON 1
WAIT SEC 2
$VEL = {CP 0.01, ORI1 30, ORI2 30}
LIN_REL{Z 500}
WAIT SEC 0
INTERRUPT OFF 1
END
DEF MYTRIGGER()
DECL INT T
BRAKE
T = 0
BAS(#BASE,T)
LOOP
IF (probe_pt_status == 0) THEN
PT_PROBE_ROUGH = $POS_INT
EXIT
ENDIF
IF (probe_pt_status == 1) THEN
PT_PROBE_CENTER = $POS_INT
EXIT
ENDIF
IF (probe_pt_status == 2) THEN
PT_PROBE_X = $POS_INT
EXIT
ENDIF
IF (probe_pt_status == 3) THEN
PT_PROBE_XY = $POS_INT
EXIT
ENDIF
ENDLOOP
T = 4
BAS(#BASE,T)
RESUME
END
Is there a clear way that the FLANGE coordinate system is defined? Similar to how a BASE coordinate system is an X,Y,Z translation and A,B,C rotation from world frame?
Is there a value of A6 that corresponds to "nominal" position? Where the axes run parallel to the world system?
Hi all,
KSS 8.3
KRC4
I had a question regarding the FLANGE coordinate system. I am trying to define a tool via numeric input and see that the tool X, Y, Z, A, B, C is just a transform from the FLANGE coordinate system. However I cannot find how the FLANGE coordinate system is defined. Does a rotation of A6 also rotate the X and Y axes of the FLANGE coordinate system?
Thanks.
Hi guys,
KSS 8.3, KRC4
I have close to a hemispherical work-piece that is mounted to the flange of my robot arm. The TCP is currently defined at the center of the work-piece and the apex of the convex sphere. Imagine slicing a basketball in half and mounting it to the flange of the robot. I have an external tool that I am using on the work-piece. It is essential that the robot (using A and B) angles keep the work-piece normal to the static external tool at all times. The tool path is a simple raster pattern back and forth, yet with the A and B angles changing.
I am encountering difficulties doing the math to figure out how much to exactly shift the A and B angles at each X,Y position. I think a lot of my issues arise from the fact that I believe the rotations are done about the TCP as the origin. So once I shift my A angle, the previously calculated B angle no longer applies since the A angle shift actually causes my TCP to move as well. In addition, when I translate in the X,Y axes this shifts the TCP (and hence the origin as to what my original angles were supposed to be rotated around).
Would establishing an external tool help keep my TCP static at the interface between my workpiece and the tool? Even with my part rastering back and forth?
Thanks!
ALSO...
just went to that directory you mentioned. I only have my programs folder... no system folder.
Is this likely a permissions problem regarding how I set up the network between the two computers?
Your Obedient Servant
Yes, I just want to periodically check them as a means of making sure everything is working properly.
Hi all,
I have connected my KUKA CPU with an external CPU via a basic Ethernet network connection. I am wondering what is the file location for the $config.dat file on the KUKA CPU. I want to be able to see this in the windows file explorer on the external CPU. I will not be making changes to it, I just want to be able to view it.
Thanks!
Is there a way to go into INI files to change the 2 hour grace period? I already found the location of the 46 hours variable.
Ideally I would not want to disable the brake test all together.
Furthermore...
Is there a variable I can alter that notifies the user when a brake test is close to being required? I believe the default is 2 hours.
Hi guys,
KSS 8.3, KRC4
The programs that I will be running on my KUKA can run up to ~20 hours or so. I was wondering... are there system variables that I can access telling me the current amount of time since the last brake test? I can build something into my code to say if my run time is less than the time required until the next brake test, perform a brake test.
Thanks!
No. You need to do some research into Euler angles and rotation matrices. There are many discussions in the forum archives. Put very briefly, the ABC values of a robot position represent a sequence of rotations, in order A (RZ), then B (RY), then C (RX). So there are some orientations where issuing a LIN_REL {B 1.0} command would cause the $POS_ACT_MES B value to change, but there are many more where the A or C value would change, or (the vast majority of the time) all three values would change. The changes are also non-linear -- when the A or C values approach + or - 180deg, or B approaches + or - 90deg, the rates at which the other two values change accelerate drastically.
Basically, Euler angles are extremely non-intuitive, which is why KRL (and just about any other robot programming language) includes the Geometric Operator (or equivalents) for performing these calculations (also discussed in depth in the forum archives).
Thank you for the response.
I have read about the geometric operator and see that it is useful for moving to a certain POS or FRAME in a different base. You mention this geometric operator (or equivalents), is there one specifically for just jogging a specific angle that is not an Euler angle? What is the KUKA robot doing when I hold down a deadman switch and jog "B" in T1 mode? Is that an Euler angle rotation?
I am simply looking to de-tilt a metal plate on the flange such that it is completely normal to a measurement system the robot is facing.
Thank you for the suggestion.
I did, indeed, check that the correct Tool and Base are being used.
Am I correct in my understanding that if I give the KUKA a command of something like LIN_REL{B 0.1} that if I look at $POS_ACT (assuming they are in the same base) that I should see the B position change 0.1 degrees?
Thanks!
I understand that an issue may be that my tool is not defined correctly.
However, what I do not understand is why when I jog (in my base) using the B touch button why I am able to move the B back and forth without issue, yet when I give a relative B command in a program I am running the movement of the axes is much different.
Essentially, another way to ask what I do not understand is, when I jog (in my base) in T1 via holding down the dead man switches and pressing "B" what is the equivalent motion command in the KUKA programming language?
Robot is mastered correctly. My TCP is on the flange.
To give a bit more evidence or information on what I am trying to do...
Where I am right now I am giving it an X, Y, Z, A, B, C where X, Y, Z, A, and C are taken from the previous location before my 0.1 degree move in B is performed. I then grab the B angle position from this point as well but add 0.1 degrees to it. For example:
Current position: x 100.0, y 125.0, z -90.0, a 50 degrees, b 45 degrees, c 75 degrees
Commanded position: x 100.0, y 125.0, z -90.0, a 50 degrees, b 45.1 degrees, c 75 degrees
I then do a LIN (Commanded position) move.
This is where things start to get a bit odd. I move to the B 45.1 degree position, but then my next command is to go back to B 45. However, the robot only moves ~30% of this B angular move so its more like at 45.06 degrees, instead of 45.0. I attribute this to the error in the robots motors, so I am wondering how I can mitigate this.
IN ADDITION... I notice that even though I am commanding a z -90.0 each time, after each move the z value is creeping up on me so that after one run its -90.1, the second run its -90.2, etc.
My thought is that I am overconstraining the system by giving it an exact X, Y, Z, A, B, C location and am wondering if commanding my desired A, B, C first, then commanding my desired X, Y, Z, then one more command of my A, B, C will help me "iterate" to get to my desired location. (I hope the idea that I am describing is clearly communicated here...)
Lastly, something I am wondering is if I should set my CP approximation value to something much smaller than already exists.
Thanks guys.