OK so I misunderstood the difference beetween terms "segment" and "individual spline motion".
Thank you!
OK so I misunderstood the difference beetween terms "segment" and "individual spline motion".
Thank you!
Yes, you're right. I meant "$VEL_AXIS"...
However the manual says:
"Value assignment to the system variable. In the case SLIN segment: the assignment applies ONLY for this segment"
Now, English is not my mother tongue, but it seems to me the value should be restored after the instruction.
Hi everyone,
while programming a sequence of individual spline motions (SLIN specifically) on a KRC4 with KSS8.6, I found out the assignment made with the "WITH" statement does change the variables following it but does not "restore" them to original value at the end of the instruction. Considering the following code and ignoring other motion parameters except for $VEL_AX set to 100 for all axes, I would expect the robot to move to "pos1" with a tcp velocity of 0.1m/s then to "pos2" with a tcp velocity of 1m/s. This does not happen. The value set on WITH $VEL.CP = 0.1 is retained for the following motions.
However, the system integrator manual for KSS8.6 specifies the following:
Am I doing something wrong? I'd like to operate the "WITH" statement with the behavior specified in the manual...
Hi everyone,
A quick question: consider a set of PTP (or LIN) ... C_DIS approximated motion instructions (passing through n cartesian points) to move the robot while avoiding some obstacles.
I understand the path cannot be predicted exactly in advance so I have to try the path in AUT mode with a reduced override $OV_PRO. Let's suppose the path tried once is correct.
Will the exact same path be maintained If executed using higher/lower overrides?
I think this would be true if using SPLINE motion type, but what about old motion?
Thank you
Thank you. I will contact KUKA support to find out what's going on.
Interestingly, I noticed the motion runs perfectly using PTP, while on SPTP the alarm always appears. However, during the motion the robot inevitably is slightly "shaken" (can be noticed by looking at the tool, which is a 2.6 meters long gripper) probably by the gaps between the linear unit modules. Perhaps while on SPTP the controller has a stricter tolerance on the other axes?
Hi,
I am commissioning a KUKA KR420 R3330 F with a KL4000 linear unit on a KRC4 controller (KSS 8.6). The robot program has some segments where the robot is moved along the linear unit maintaining itself still (in a simple motion between two E6axis points with same A1...A6 values and different E1 values).
While executing these motions in T2/AUT/EXT with Override > 50% the robot often stops itself with a steep deceleration ramp and the following message is triggered:
"Ackn. Interpolation Cycle timeout monitoring LRS_HP" (KSS01205)"
If I keep the override below 50% no alarms appear and everything works smoothly.
No references to this message in Kuka Xpert nor in the manuals available to me.
Has anyone ever encountered this message?
Thank you
Thank you for your reply panic mode,
The orientation during linear movement is constant, the angles do not change during movement.
I noticed the error by manually measuring the orientation of the gripper at the end of the linear movement.
The linear movement starts with agles refered to base A -90, B 90, C 0, at the end of the movement angles are the same but the gripper is not aligned with the base as at the beginning of the movement.
To correct this misalignment i have to put angles like A -90, B 89.88, C 0.
Thank you for your reply Fubini,
-The robot was mastered with EMD with load correction.
-Tool TCP was determined with XYZ 4 point method (with error of 1,5 mm)
-Polisher base was determined with 3 point method.
-The robot is equipped with absolute accuracy, load data was determined with Kuka.LoadDataDetermination 7.1.
-We are running near wrist singularity, $SINGUL_POS[3] is set to 0.
The TCP follows the polisher base in XYZ, there is only a deviation on A rotation (of the tool) and that seems strange to me.
HI,
I am doing an application of work piece polishing, the robot pick a work piece with a gripper and process it on a polishing machine.
Tool's TCP is located on the gripper edge ( the edge is far away from robot flange): TOOL_DATA[1] = {X 313.421417,Y 1497.38013,Z 101.276588,A -0.450000,B 0.0,C -0.0367040}
I've created a base along polishing machine for work piece processing.
The work piece to process is usually very long (about 3000 mm), so the robot must execute a long linear path.
This is part of my code:
...
;=======================
; Positions calculation
;=======================
; Calculate processApproachPosition over start position
processApproachPosition = {X 0.0, Y 0.0, Z 100.0, A 0.0, B 0.0, C 0.0} : processStartPosition
; Calculate processEndPosition
processEndPosition = {X 3500.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0} : processStartPosition
;=======================
; Process polish sequence
;=======================
;----------------------------------
; Approach and process edge polish
;----------------------------------
; Go to process approach position
SLIN processApproachPosition
; Go to process start position
SLIN processStartPosition
; Go to end process position
SLIN processEndPosition WITH $VEL.CP = processSpeed
...
Display More
My problem is that during linear movement, the gripper TCP follows the path along X, Y and Z but it seems to rotate in A.
At process start position the gripper is aligned with polisher base, at the end of process the gripper is rotated in A (the gripper edge where TCP is located is on path but the other side is 10mm over the path). It looks like the TCP rotates in A some degrees along process path.
Robot model: KR 420 R3330
System software: KSS 8.6.8
Thank you all for your answers.
I'll try to better explain my situation.
The acknowledge sent by the external PLC causes the robot to follow one path rather than another:
DEF MainProgram()
...
$ADVANCE = 1
SPTP P1 C_SPL
TRIGGER WHEN DISTANCE = 1 DELAY = -100 DO SubProgram()
SPTP P2 C_SPL
CONTINUE
WAIT FOR SubProgramAnswer
SWITCH SubProgramAnswer
CASE 1:
SPTP P3 C_SPL
SPTP P4 C_SPL
CASE 2:
SPTP P5 C_SPL
SPTP P6 C_SPL
CASE 3:
...
ENDSWITCH
DEF SubProgram()
SubProgramAnswer = N
END
Display More
I want to avoid motion stop during movement, so the response of external PLC (execution of SubProgram) must be executed before reaching P2's approximation area.
But what i want to do does not seem possible because TRIGGER WHEN DISTANCE referred to P2, SubProgram() can't be called before reaching P2's approximation area.
Think about SubProgram() as a notification sent by the robot to the PLC just to notify it is approaching P2, and about SubProgramAnswer as an acknowledge sent by the PLC.
Stopping the motion must be avoided at all costs (unless communication problems occur...).
Actually we might just forget about the above, and consider this:
DEF MainProgram()
...
$ADVANCE = 1
SPTP P1 C_SPL
TRIGGER WHEN DISTANCE = 1 DELAY = -100 DO SubProgram()
SPTP P2 C_SPL
CONTINUE
WAIT FOR SubProgramAnswer
SPTP P3 C_SPL
SPTP P4 C_SPL
...
END
DEF SubProgram()
SubProgramAnswer = 1
END
Display More
The ARP proceeds with the next motion instructions (SPTP P3 and so on), only at the end of SubProgram(), which is a one-shot routine...
But using the TRIGGER WHEN DISTANCE referred to P2, SubProgram() can't be called before reaching P2's approximation area. So in this moment, no further motions have been planned (ARP has been waiting at the WAIT FOR SubProgramAnswer).
If I am not mistaken, this should cause a stop in the motion.
To complicate things a bit, what will happen now?
The code below represents a generalized concept of what I am trying to do: starting the execution of SubProgram() before reaching P2.
In my case, SubProgram() just acts as a way to communicate to an external PLC that the robot is getting close to P2.
To continue with the next instructions (SPTP P3, SPTP P4...) it is necessary to wait for the external PLC's answer (SubProgramAnswer) given AFTER the full execution of SubProgram(), hence the CONTINUE/WAIT FOR instructions.
All of this without stopping the robot!
But...
As the "system integrator" manual says, when using the trigger when distance = 1 referred to an approximate point (in this case, P2), the maximum negative offset is limited to the start of the approximate positioning arc of the end point (P2).
And...
As of the original question, to avoid stopping the motion we must ensure that the next motion instruction is read by the advance run pointer before entering P2's approximation area.
So...
If the next instructions (SPTP P3...) can be read by the ARP only after the completion of SubProgram(), but SubProgram() can be started at least at the start of P2's approximation area, it is impossible to avoid stopping the robot.
Is there any other way to anticipate the execution of SubProgram() but still while keeping the trigger referred to P2?
Thank you all.
Note: SubProgram() and the following instruction WAIT FOR SubProgramAnswer do not stop the advance run pointer.
Hi,
Considering a path passing through several approximated points, let's suppose the robot is executing the following code:
Considering $ADVANCE is set to 1, as soon as the main run begins the second motion instruction (SPTP P2 C_SPL) the advance run pointer enters SubProgram().
What happens if SubProgram() keeps the advance run pointer stuck (or looping...)?
My guess is, there are two cases:
1) the advance run pointer is kept inside SubProgram() for a greater time than the one required for the robot to reach P2's approximation area
2) the advance run pointer jumps out of SubProgram() before the robot reaches P2's approximation area
So, for case 1, the robot should stop at the beginning of P2's approximation area and an alarm is triggered.
For case 2, the robot can blend the motion between P1-P2-P3 without stopping.
Is this correct? Normally I would try and experiment the code on the robot to observe the result, but I don't have a robot available right now.
Thank you all
My original question was mainly referred to the possible effects of a WAIT SEC instruction in a continuous loop.
but... the thing is that implementation of WAIT command is not known. there are no tools for robot programmer to see CPU utilization, also this is running on RTOS anyway and robot interpreter seem to be a single thread.
the best way to see is something is useful or not is to compare results with and without it. i do not recall any observe difference... but... that does not mean that it does not exist.
This is interesting. I will definitely try to experiment and see if I can spot any difference.
How do your subprograms look like? If e.g . they start with a INI Fold you would get definetly an advance run break.
Thank you. I haven't tried the program on the robot yet...actually, the subprograms do have a INI Fold...Does it really stop the advance run? If so, I'll try to move the INI somewhere else (maybe in the main program?)
Thank you all for your useful answers,
Mudanda
Hi,
I am programming a while loop in a sequential program, which is used to wait for a mission request from a master plc.
Is it useful to add a WAIT SEC instruction (with a very low time, such as 0.1s) to reduce the load on the processor?
I have added the CONTINUE line above because the main run pointer may still be on the last motion instruction of the previous program, but I want motions between missions to be connected without stopping the robot.
My program is something like this: