CoDeSys V3 – Stefan Henneken

IEC 61131-3: SOLID – Das Liskov Substitution Principle

„Das Liskov Substitution Principle (LSP) fordert, dass abgeleitete FBs immer zu ihren Basis-FB kompatibel sind. Abgeleitete FBs müssen sich so verhalten wie ihr jeweiliger Basis-FB. Ein abgeleiteter FB darf den Basis-FB erweitern, aber nicht einschränken.“ Dieses ist die Kernaussage des Liskov Substitution Principle (LSP), welches Barbara Liskov schon Ende der 1980iger Jahre formulierte. Obwohl das Liskov Substitution Principle (LSP) eines der einfacheren SOLID-Prinzipien ist, tritt deren Verletzung doch sehr häufig auf. Warum das Liskov Substitution Principle (LSP) wichtig ist, zeigt das folgende Beispiel.

IEC 61131-3: SOLID – Das Dependency Inversion Principle

Feste Abhängigkeiten sind einer der Hauptursache für schlecht wartbare Software. Natürlich können nicht alle Funktionsblöcke völlig unabhängig von anderen Funktionsblöcken existieren. Schließlich agieren diese miteinander und stehen somit untereinander in Beziehungen. Durch das Anwenden des Dependency Inversion Principle können diese Abhängigkeiten aber minimiert werden. Änderungen lassen sich somit schneller umsetzen.

IEC 61131-3: unterschiedliche Versionen der gleichen Bibliothek in einem TwinCAT Projekt

Bibliotheksplatzhalter ermöglichen es, mehrere Versionen der gleichen Bibliothek in einem SPS-Projekt zu referenzieren. Diese Situation kann hilfreich sein, wenn auf Grund neuer Funktionen eine Bibliothek in einem bestehenden Projekt aktualisiert werden soll, sich durch das Update aber herausstellt, dass ein älterer FB ein geändertes Verhalten erhält.

IEC 61131-3: Parameterübergabe per FB_init

Je nach Aufgabenstellung kann es erforderlich sein, dass Funktionsblöcke Parameter benötigen, die nur einmalig für Initialisierungsaufgaben verwendet werden. Ein möglicher Weg, diese elegant zu übergeben, bietet die Methode FB_init().

Continue reading “IEC 61131-3: Parameterübergabe per FB_init”

IEC 61131-3: The Decorator Pattern

With the help of the decorator pattern, new function blocks can be developed on the basis of existing function blocks without overstraining the principle of inheritance. In the following post, I will introduce the use of this pattern using a simple example.

IEC 61131-3: Das Dekorierer Pattern

Mit Hilfe des Dekorierer Pattern können neue Funktionsblöcke auf Basis bestehender Funktionsblöcke entwickelt werden, ohne das Prinzip der Vererbung überzustrapazieren. In dem folgenden Post werde ich den Einsatz dieses Pattern an Hand eines einfachen Beispiels vorstellen.

IEC 61131-3: The State Pattern

State machines are used regularly, especially in automation technology. The state pattern provides an object-oriented approach that offers important advantages especially for larger state machines.

IEC 61131-3: Das State Pattern

Besonders in der Automatisierungstechnik finden Zustandsautomaten regelmäßig Anwendung. Mit Hilfe des State Pattern steht ein objektorientierter Ansatz zur Verfügung, der insbesondere bei größeren Zustandsautomaten wichtige Vorteile bietet.

IEC 61131-3: The generic data type T_Arg

In the article The wonders of ANY, Jakob Sagatowski shows how the data type ANY can be effectively used. In the example described, a function compares two variables to determine whether the data type, data length and content are exactly the same. Instead of implementing a separate function for each data type, the same requirements can be implemented much more elegantly with only one function using data type ANY.

Continue reading “IEC 61131-3: The generic data type T_Arg”

IEC 61131-3: The Observer Pattern

The Observer Pattern is suitable for applications that require one or more function blocks to be notified when the state of a particular function block changes. The assignment of the communication participants can be changed at runtime of the program.