Kuka Robot Language is pretty straightforward, although it has a lot of
brand-specific stuff in it. You can generate KRL programs from any text editor
-- no special formatting is required. On boot, most Kuka robots load the raw
text files from nonvolatile storage (a hard drive, on the KRC1 generation
controllers) into what amounts to a RAMdisk, and runs the programs from there.
Specifcs can change depending on what controller version you have -- my
experience is mostly limited to the KRC1 series, which uses off-the-shelf PC
hardware running W95 and VxWorks (sounds like a terrible combo, but generally
it works great), but KRL is mostly standard among all controller generations.
Only certain special functions don't carry over.
KRL has several different modules available. Each motion program consists
of two files: a *.src file, which contains all your command logic, and a *.dat
file, which contains local variables, point position data, and other items. If
you are writing your program "live" on the teach pendant, the robot system will
create and maintain these files for you. One of the best ways to learn KRL is
to create programs in this fashion, then make a backup to disk and look at the
backup files using a regular text editor. There is also the *.sub files, which
are part of the "Submit Interpreter." This makes up the Kuka robot's native
background processor. The Submit runs in the background, and there is a
setting in one of the machine setup files that controls which *.sub file gets
started on bootup. The Submit program is written in normal KRL, but cannot
contain any motion commands, only logic. It can make calls to normal *.src
subroutines, provided that those subroutines have no motion commands.
One of the nicest things about KRL is that, if you have to learn it the
hard way (which I did), almost everything is software-configured and available
on the backup disk. You can reverse-engineer a lot of KRL's functions using a
program like Grep to search for particular text (commands or variables or
subroutine names) in the backup files.
KRL looks a lot like a trimmed-down version of C, with special commands
added. Structure variables will be familiar to anyone who's done regular old
ANSI C coding. But there *are* differences -- when in doubt, treat it like
IF statements end with ENDIF. Same for FOR and WHILE loops.
Programs created from the teach pendant do something that looks odd at
first -- motion commands that look like one line on the pendant screen actually
take up a half-dozen lines or so of KRL code when you examine them offline in a
text editor. What causes this is that the pendant visually "compresses" the
multiple lines of code for operator convenience. The raw KRL behind the scenes
has lines that set speed, TCP, frame, and other options, before actually
executing the motion command itself. If you write your programs offline, you
can skip all this extra code by setting these options only when needed, and
then just executing motion commands.
Variables that start with "$" are system variables. Moiton locations are
always prefaced with an "X," although again you only see this when you're
reading/writing raw KRL -- the teach pendant tries to make it easier on the
operator. PTP is a joint-motion command, LIN is a linear interpolation. So
PTP POSITION on the pendant would look like PTP XPOSITION in raw KRL.
KRL is immune to capitalization -- ptp and PTP are the same thing.
However, it turns out there are a few setup files where this is *not* true.
So, the best route is usually to put everything in capps.
E6POS structure variables are positions, stored as . There
are additional S and T variables that control which side of 0deg the elbow and
wrist are. So you can access the Y value (in mm) of a position by using
E6AXIS structure variables are positions stored as joint angles. Axes up
to 8 are usually supported -- just leave the values for axes you don't have set
at 0. BASE and FRAME and TCP variables are set up the same way.
The DECL command is used to declare variables -- newer compilers often let
it slide, but it is must when creating structure variables. You can use INT,
REAL, BOOL, or CHAR. Strings are usually CHAR arrays, declared just by DECL
CHAR[x]. Multidimensional arrays of any variable type are supported.
The compiler tries to be helpful -- when you load a program that has a
syntax error, there is usually a file called (program name).ERR created, which
marks the offending line. But some more subtle errors don't get caught by the
I/O is accessed either by direct number ($IN[xx]), or BOOL variables can be
assigned to particular I/O bits in the $CONFIG.SYS file. "Words" of I/O, in
varying lengths, can be assigned to INT variables as well.
Global variables are assigned in $CONFIG.SYS, and can be accessed by any
routine, at any time, even the Submit. In most versions of the software,
$CONFIG.SYS is saved to storage on power-down, and the current values of the
global variables will also be saved. This comes in handy for preserving data.
Local variables are only accessible inside the src/dat file of the program they
were created in. Avoid using the same names for local and global variables.
Phew! There's tons more, of course, but that all depends on just how
exotic you're getting, and what special functions you're trying to use. Again,
one of the best ways to learn KRL is to obtain some existing programs and pick
them apart using a text editor. It takes some work, but you can
reverse-engineer a lot of the basics without much trouble.
Wow - thanks a lot for your answer, it helped me very much. You tell me
to read some existing programms. Do you know any resource for
KRL-Developers? I did not find anything yet, quite strange.
Thanks in advance,
Hmm... oddly enough, I *don't* know of any such resources "in the open,"
since I actually work for the company. So I just get all my stuff directly
from the source.
As far as looking at existing code goes, do you have a Kuka robot on hand?
What model controller? The base software package install for a Kuka robot
usually includes a set of pre-existing software written in KRL. Without
knowing more about what hardware you have, it's hard for me to be more
specific. Is this a used robot, from an industrial facility? Or is it
brand-new? If it was used, the original owner might have wiped the memory for
confidentiality reasons, but the operating system and development environment
should still be intact. If it is brand new, it should still have a basic set
of standard KRL functions and subroutines on board.
Kuka robots are very heavily used in Germany and other parts of Europe,
among automotive manufacturers in particular. If this is a university project
of some kind, you might be able to beg some backup files from an industrial
user. The nice thing about KRL is that while the language has expanded over
the past decade or so, the basics haven't really changed. So looking at KRL
for an older robot will still help you learn KRL for a newer robot, or vice
versa. The more you avoid "special" commands (certain communication buses,
machine-specific servo settings, etc), the more commonality you will find.
You could also try contacting industrial customers or Kuka itself for
manuals. You might find someone willing to share some material.
Can you describe your hardware in more detail? It'll help me get a handle
on what you have to work with.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.