KRL = Kuka Roboter Language

In article , Ralf Jahr writes:

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 BASIC. 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 {X,Y,Z,rZ,rY,rX}. 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 XPOSITION.Y. 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 compiler. 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.

Hello SkyeFire!

SkyeFire schrieb:

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,

Ralf

In article , Ralf Jahr writes:

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.