Kuka Style Guide

  • AD
  • MaxG

    is this Style guide only for you (as mentioned in post #1) or also for others?

    If only for you:

    just make your own style guide

    (also check subjects below as guidance)

    also for others:

    talk to them and find out the important things:

    how to define variable names:

    local, global, constants

    type as prefix (hungarian)

    lower or upper Camel Case

    how to define function or procedure names?

    (Camel Case?)


    (english or local language

    and when:

    bad example:

    #increment counter

    counter = counter + 1 )


    (empty lines - maybe not always allowed - see CONTINUE)

    Create functions or procedures for common tasks (check for this on this forum for examples)

    Do not reinvent the wheel

    (I reinvented the wheel: it is a triangle now - I do not need a brake parking up or downhill - but still having problems while moving)

    Use mind map for collecting additional items and check whether they can be valid



  • Yes I am looking for guidance.

    Basically, I want to ensure that, the company has a programming procedure to follow. All programmers must do the same thing, for example using the same naming conventions for variable. Programmers come and go, so I would like to create something solid for the company, for the next guy.

    So I am looking for a guide to use a base to start from.

    Maybe I should look at adapting a C/C++ style guide.

  • KRL is more similar to Pascal than C-style languages.

    KRL is case-insensitive, and doesn't care about whitespace at all. Using indentation to mark nested loops/IFs/etc is strongly advised, and WV and OrangeEdit both support auto-indenting KRL (although they both do it by different rules :icon_rolleyes:.

    One real sticking point is if your programs mix Inline Forms with "raw" KRL. If you're making programs that can easily be touched-up by line operators, you probably need ILFs, but that puts some extra constraints on your KRL if the two program types need to interact. It's often convenient to put your hand-programmed motions into their own modules, and let those modules make subroutine calls to your "raw KRL" modules.

    Organizing your various routines into easily-deployable modules is helpful. For instance, avoid putting your global variables into $CONFIG.DAT -- instead, put them in the .DAT files of the modules that use them. If other modules need access, do it through subroutine or function calls. The idea is to be able to copy a module into a robot as a discrete unit, without any extra dependencies, or needing to hand-edit system files.

  • This is exactly why I think it is important to create a "Style Guide".

    Everyone has there own way of doing things, but I need to set some basic ground rules. I want to make it easier for the next person, because I know what a nightmare it was when I took over. I wouldn't want to wish the same on them.

    Thanks all for the valuable input and insight given.

  • Standard for naming variables is helpful, in my experience. KRL limits variable names to 24 characters, a-Z, 0-9, and _ (no spaces). Names can only start with a-Z or _ , not numbers.

    (While it is possible to start your variable names with $, that is considered bad practice, since KUKA uses that for system variables.)

    Everyone has their own rules, of course, but personally I found it helpful to "prefix" each variable name with something that indicated its type (INT, REAL, CHAR, etc), and whether it was a routine-level volatile variable, a module-level variable, or a received argument. Some people add prefixes to indicate if the variable is Global or not.

    A naming convention to make I/O names distinct from "normal" variables was also useful.

    I also tended to use Snake Case for naming my routines and variables, while FULLY CAPITALIZING KUKA variables and routine names (even the ones that, like PGNO, are not actually $System variables). I have to admit, I didn't come up with that, I adopted it from OrangeEdit's auto-fill, but I never had any cause to regret it.

    Global variables should be avoided whenever possible, and if they are necessary, name them very distinctly. One weakness of the KRL variable system is that, b/c the ability to create Global variables outside of $CONFIG.DAT was added "late", there is no namespace collision detection between Global and local variables with the same name -- instead, the compiler fails-over silently to use the local variable over the global one. WorkVisual's editor has some detection for these conflicts, but it's not 100% reliable. Multiple Global variables with the same name, however, will be detected and cause compiler faults.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now