You are on page 1of 4

Stefan Henneken

Chief Spaghetti Coder

Home
About
Impressum

Type text to search here...


Home > IEC 61131-3 (english) > IEC 61131-3: Coding Guidelines

IEC 61131-3: Coding Guidelines


April 8, 2016 Stefan Henneken Leave a comment Go to comments

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
Privacy &(L) Peculiarities
Cookies: This site uses cookies. By continuingof individual
to use representation
this website, you agree to theirtypes
use. of IEC
61131-3.
To find out more, including how to control cookies, see here: Cookie Policy
Vendor Specific Extensions (E) Extensions which do not belong to the IEC 61131-3
range. Close and accept
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:

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Close and accept


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:

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
TheTovariables
find out more, andtoudiValue
including how
diValue control cookies,have different
see here: values at first sight. But
Cookie Policy 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 Close and accept
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.

Advertisements

REPORT THIS AD

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

REPORT THIS AD
Close and accept

You might also like