IEC 61131-3 (english) – Stefan Henneken

IEC 61131-3: SOLID – The Open/Closed Principle

Inheritance is a popular method for reusing existing function blocks. It enables new methods and properties to be added or existing methods overwritten without requiring access to the source code for the base function block. Designing software so that it can be extended without modifying the existing code is the key concept behind the Open/Closed Principle (OCP). But using inheritance also has disadvantages. These disadvantages can be minimised by employing interfaces – and this is not the only advantage of this method.

IEC 61131-3: SOLID – The Interface Segregation Principle

The basic idea of the Interface Segregation Principle (ISP) has strong similarities with the Single Responsibility Principle (SRP): Modules with too many responsibilities can negatively influence the maintenance and maintainability of a software system. The Interface Segregation Principle (ISP) focuses on the module’s interface. A module should implement only those interfaces that are needed for its task. The following shows how this design principle can be implemented.

IEC 61131-3: SOLID – The Liskov Substitution Principle

„The Liskov Substitution Principle (LSP) requires that derived function blocks (FBs) are always compatible to their base FB. Derived FBs must behave like their respective base FB. A derived FB may extend the base FB, but not restrict it.” This is the core statement of the Liskov Substitution Principle (LSP), which Barbara Liskov formulated already in the late 1980s. Although the Liskov Substitution Principle (LSP) is one of the simpler SOLID principles, its violation is very common. The following example shows why the Liskov Substitution Principle (LSP) is important.

IEC 61131-3: SOLID – The Single Responsibility Principle

The Single Responsibility Principle (SRP) is one of the more important of the SOLID principles. It is responsible for decomposition of modules and encapsulates the idea that each unit of code should be responsible for just a single, clearly defined role. This ensures that software remains extensible long term and makes it easier to maintain.

IEC 61131-3: SOLID – The Dependency Inversion Principle

Fixed dependencies are one of the main causes of poorly maintainable software. Certainly, not all function blocks can exist completely independently of other function blocks. After all, these interact with each other and are thus interrelated. However, by applying the Dependency Inversion Principle, these dependencies can be minimized. Changes can therefore be implemented more quickly.

IEC 61131-3: SOLID – Five principles for better software

In addition to the syntax of a programming language and the understanding of the most important libraries and frameworks, other methodologies – such as design patterns – belong to the fundamentals of software development. Aside from a design pattern, design principles are also a helpful tool in the development of software. SOLID is an acronym for five such design principles, which help developers to design software more understandable, more flexible and more maintainable.

IEC 61131-3: Different versions of the same library in a TwinCAT project

Library placeholders allow to reference multiple versions of the same library in a PLC project. This situation can be helpful if a library has to be updated in an existing project due to new functions, but the update turns out to give an older FB a changed behavior.

IEC 61131-3: Abstract FB vs. Interface

Function blocks, methods and properties can be marked as abstract since TwinCAT V3.1 build 4024. Abstract FBs can only be used as basic FBs for inheritance. Direct instantiation of abstract FBs is not possible. Therefore, abstract FBs have a certain similarity to interfaces. Now, the question is in which case an interface and in which case an abstract FB should be used.

IEC 61131-3: Exception Handling with TRY/CATCH

When executing a program, there is always the possibility of an unexpected runtime error occurring. These occur when a program tries to perform an illegal operation. This kind of scenario can be triggered by events such as division by 0 or a pointer which tries to reference an invalid memory address. We can significantly improve the way these exceptions are handled by using the keywords __TRY and __CATCH.

Continue reading “IEC 61131-3: Exception Handling with __TRY/__CATCH”

IEC 61131-3: Parameter transfer via FB_init

Depending on the task, it may be necessary for function blocks to require parameters that are only used once for initialization tasks. One possible way to pass them elegantly is to use the FB_init() method.

Continue reading “IEC 61131-3: Parameter transfer via FB_init”