Real-time programming in IEC 61131-3 languages

To develop real-time critical function blocks (FB), libraries and applications (apps) using IEC 61131 languages like Structured Text, certain fundamental aspects must be considered during development.

Note: This guideline including its software examples is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

String operations

Using IecString usually doesn't generate garbage, as this data type has a fixed length and operations on a string work in place.

That said, the use of TO_STRING does create temporary garbage. On the other hand, basic CONCAT (under 5 parameters) is free of garbage but heavy on runtime. Try to only call this method when actually needed and as infrequently as possible.

For example, if no error has actually occured then don't prepare and create error logging strings with TO_STRING and CONCAT every cycle or in a high-frequency scenario. If absolutely necessary, try to spread the usage out over a larger cycle period or between larger intervals.

Function parameters

For functions such as AND, CONCAT, MAX, MIN, MUL, MUX, OR, XOR, or self-written functions that require or using 5+ parameters, the PLCnext Engineer code generator creates a C# Any array. Depending on how frequently these functions are called, they generate garbage.

In order to avoid creating unnecessary garbage, try to limit the parameters' usage to be under 5.

Global variables

One should be careful with the usage of global variables across multiple tasks (threads/cores). Read/writes to these variables, especially for STRUCTS and ARRAYS, when used in a multi threaded scenario can lead to inconsistent data and possible exceptions, depending on how these variables are used in the context of FB's and the like.

FILE_* function blocks

FILE_* function blocks need to be handled with care. One shouldn't change the input parameters (such as Handle) while a file is still being processed, as there aren't many safety checks in place currently.

It is also worth noting that internally, this function block also currently still uses the outdated Eclr.File (eclrlib.dll) class that limit has a hard limit of 8 files being open simultaneously.

MUTEX/SEMA function blocks

Incorrect use can lead to deadlocks or significant runtime delays. Debugging these types of deadlocks or runtime delays can also be incredibly difficult, so please only use these function blocks with extreme caution.

Parameters of referenced function blocks

Based on the C# guideline, C# function blocks that start threads should optionally have an input parameter to specify CPU affinity .

In the context of IEC, care should be taken to ensure that these input parameters are passed through and are visible to the user, even if the referenced blocks are not directly visible.

Documenting FB functions

FB functions known to cause delays or CPU utilization should be documented accordingly. Even if the IEC FB does not directly cause delays or CPU utilization, other referenced FBs used should be considered and documented.

Providing examples

Whenever you develop a function block or library, it would be a good practice to also provide a basic usage or test case example project.

Down the road this helps QA, customers and colleagues that might need to help with debugging customer projects.