Hello, I need to use a LIN_REL in my program.
Until now I've been working with WOPCORE to write my movements.
I would like to know how the speed is indicated to this movement.
current code : lin_rel {x 0, y 0, z 300, a 0, b 0, c 0}
I take all advice and warnings concerning use 
; set 2 m/s for all following lin/circ motions until changed again
$vel.cp = 0.2
lin_rel {x 0, y 0, z 300, a 0, b 0, c 0}Fubini
I would like to know how the speed is indicated to this movement.
current code : lin_rel {x 0, y 0, z 300, a 0, b 0, c 0}
Move commands in KRL do not include velocity as part of the command. Motions programmed by Inline Forms, like this:
actually create multiple lines of KRL that set multiple system variables, including velocity.
But since LIN_REL is not available as an Inline Form, you need to program it in "raw" KRL, as you already have.
If you keep your code as it is, the LIN_REL command will execute at the same speed as the last Inline Form LIN motion that was executed.
If you want to control the velocity of the LIN_REL directly, use Fubini's method. The system variable $VEL.CP is set in units of m/s, and controls the velocity with which any following LIN or CIRC motions are executed.
A simple user-friendly method I use with Kuka is to create a "motion parameter" function that I call before every motion. Inside the function you can have preset values for speed, acceleration, approximation, etc. Cleans up the rest of your programs and makes programming much faster.
A simple user-friendly method I use with Kuka is to create a "motion parameter" function that I call before every motion. Inside the function you can have preset values for speed, acceleration, approximation, etc. Cleans up the rest of your programs and makes programming much faster.
You can do that, but that's literally what BAS.SRC (which comes in every KRC) is for. The only "problem" with BAS is that it has a wide range of options, so you have to determine how to trigger the option you want, using the arguments in the call.
Absolutely right, that's how we used to do it. A personal goal of mine is to make the programs at least somewhat easy to read for the customer. Coming from a maintenance background I understand how frustrating it is to get called over to a robot issue and not be able to make heads or tails of the programming. Using BAS is perfectly fine, just depends on what your goals are.
