You can find multiple programming manuals for KRL in the Manuals, Software and Tools sub-forum, but I'm not sure what you mean by "style guide."

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?)

comments

(english or local language

and when:

bad example:

#increment counter

counter = counter + 1 )

layout

(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

regards

MOM

A good start would be "MISRA_C"

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 .

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.

Not everything in there can be considered a style guide, but some things could be. Though I suppose my biggest pet peeve is use of literals where (constant) variables would work much better, e.g.:

$in[15] -> $in[ChAI_FuelValve]

Quote from Mentat

Not everything in there can be considered a style guide, but some things could be. Though I suppose my biggest pet peeve is use of literals where (constant) variables would work much better, e.g.:

$in[15] -> $in[ChAI_FuelValve]

Or just using DECL SIGNAL chAI_FuleValve $IN[15]

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.