IEC 61131-3: Coding Guidelines

The wish to raise the quality of a software is hardly much older than the software development itself. At the beginning, a set of rules should be determined which define software development guidelines, especially in major projects with multiple developers. Fortunately, PLCopen published recently a draft specifically for IEC 61131-3.

Most developers have already been in a situation in which they had to incorporate themselves in a program that they didn’t write. One realizes soon that every developer has his own programming style. These differences might complicate incorporation, so that it becomes much more time-consuming and error-prone. For this purpose, companies define very often own guidelines for the software development. In this way, the source code becomes cleaner and more homogeneous. Thus, it can easier be maintained, extended and tested. Moreover, new colleagues can be integrated faster into the development team.

Corresponding guidelines exist for such programming languages as Java, C++ or C# for a long time. These guidelines are usually acknowledged by the developers, or are even a mandatory component of a programming training.

The current PLCopen draft provides a cross-corporate set of rules specifically for IEC 61131-3, which takes account of a wide range of characteristics. Thus, points were included which make source code more portable. Especially machine-level programming (e.g., Pointer Arithmetic or permanent addresses) can make transfer to other control platform difficult or lead to program execution errors. Each rule has a unique identification. Examples explain the background of the respective rules in many cases.

At present, over 60 rules are defined, which are divided into 5 categories:

Naming Rules (N)	Declaration of variables, tasks, function blocks, functions, data types and namespaces.
Comment Rules (C)	Design guidelines on comments.
Coding Practice (CP)	General coding guidelines.
Languages (L)	Peculiarities of individual representation types of IEC 61131-3.
Vendor Specific Extensions (E)	Extensions which do not belong to the IEC 61131-3 range.

The rules should be seen as a proposition and not as a requirement. These rules make also no claim to completeness. It could very well make sense not to observe certain rules or substitute them with further rules.

Personally, I would not approve unconditionally several rules. The rule L17 is one example I can mention. This one implies that IF statements should always have an ELSE block, even though it is empty.

I also noticed a (small) contradiction in two rules. The rule L10 prohibits the statements CONTINUE and EXIT. However, EXIT is used in the examples of the rules L12 and CP9.

Some points should be seen as an addition to IEC 61131-3. Thus, IEC 61131-3 does not address whether a counter variable of a FOR loop can be further used after the termination of the loop. The rule L13 states quite clearly here that the counter variable mustn’t be used further. Depending on the compiler implementation, the program behavior can be different.

I discovered quite a few new things while reading through the coding guidelines. The rule CP8 points to a peculiarity: the inaccuracies of floating-point numbers should be considered when comparing. Otherwise, program blocks can emerge, which are maintained only with difficulty. For example:

Although, both variables have apparently the value 0.1, the condition is not fulfilled. The variable bResult is not set to TRUE. This is due to the different kind of imprecision of the data types REAL and LREAL. None of the both variables can represent the value exactly (only approximate values). These approximate values are just different. A simple example illustrates these imprecisions:

100 * 0.1 doesn’t give, as expected, 10.0, but the values which are somewhat larger or lower.

That’s why the rule CP8 recommends to consider a range and not an exact comparison:

But rather “inconvenient“ surprises can also occur, when comparing integers depending on the compiler implementation:

The variables diValue and udiValue have different values at first sight. But both variables get the same values, because type conversion takes place when comparing, and the values have the same bit pattern. The condition is fulfilled, and bResult is set to TRUE. The current IEC 61131-3 compiler should recognize this and output a warning.

In my view, the coding guidelines are a great source of information both for beginners and experienced programmers. Development teams can use these as a basis for their own coding guidelines and extend them correspondingly, or exclude rules.

PLCopen announced further guidelines in the December 2015 newsletter. The following issues are planned:

• documentation
• OOP (object-oriented programming)
• software development process
• software quality

The current coding guidelines can be requested on the PLCopen website (www.PLCopen.org).

Who wants to delve deeper into the subject, I can recommend the following books:

Clean Code by Robert C. Martin

Code Complete by Steve McConnell

Both books relate more to Java, but are also applicable to IEC61131-3 in many fields.