IEC 61131-3: Namespaces

Mit CodeSys V3 wurde das Prinzip der Namespaces (Namensräume) eingeführt. Namespaces gruppieren Variablen und Bibliotheken in zusammengehörige Einheiten. Ein Element wird dadurch nicht mehr nur durch seinen Namen, sondern auch durch seinen zugehörigen Namespace benannt.

Durch Namespaces können gleichnamige Elemente, die sich aber in verschiedenen Namespaces befinden, unterschieden werden. Es gibt mehrere Stellen innerhalb von CoDeSys V3, in denen mit Namespaces gearbeitet werden kann.

Global Variable List

Eine Gobale Variable List (GVL) wird benutzt, um globale Variablen zu deklarieren. Der Name der GVL muss im Projekt eindeutig sein. Groß- und Kleinschreibung werden nicht beachtet. GVList1 ist der gleiche Bezeichner wie GVLIST1. Das gilt im übrigen auch für die Namen von Variablen, Strukturen und Funktionsblöcken. Jede GVL ist ein in sich abgeschlossener Bereich, in dem, unabhängig von anderen GVLs, globale Variablen deklariert werden können.

Somit kann es z.B. eine Variable mit dem Namen gvar sowohl in der GVList1, als auch in der GVList2 geben. Um den Zugriff auf die Variablen wieder eindeutig zu machen, muss der Name der GVL vor den Variablennamen, getrennt durch einen Punkt, gestellt werden.

GVList1.gvar := 'neuer Wert';

Fehlt der Name der GVL, so ist es nicht mehr eindeutig, auf welche der beiden möglichen Variablen zugegriffen werden soll. Der Compiler würde in diesem Fall eine Fehlermeldung ausgeben. Existiert die Variable gvar nur in einer einzigen GVL, so kann die Angabe der GVL entfallen. Gibt es allerdings eine lokale Variable mit dem gleichen Namen, so muss der Name der GVL wieder angegeben werden, oder vor den Variablenname wird einfach ein Punkt gestellt.

PROGRAM PLC_PRG
VAR
  gvar : STRING;
END_VAR
.gvar := 'neuer Wert';

Der Punkt vor dem Variablennamen gibt an, dass auf die globale Variable mit dem Namen gvar zugegriffen werden soll. In diesem Fall darf die Variable aber auch nur in einer GVL deklariert sein.

Bibliotheken

Genau wie bei globalen Variablen, müssen auch die Bezeichner von Funktionsblöcken, Funktionen und Datentypen eindeutig sein. Das betrifft auch die Elemente, die aus Bibliotheken in das Projekt eingebunden werden. Sobald mehrere SPS-Bibliotheken von unterschiedlichen Quellen zum Einsatz kommen, können aber genau hier Namenskonflikte auftreten. Um dieses zu vermeiden, wurde meistens vom Entwickler der Bibliothek vor jedem POU- oder Datentypbezeichner ein Prefix gestellt (z.B. MC_MoveAbsolute()). Man versuchte hiermit, die Wahrscheinlichkeit eines Namenkonflikts gering zu halten. Bei CoDeSys V3 wird dieses Problem mit Namespaces gelöst. Hierzu ein Beispiel: Es werden zwei SPS-Bibliotheken erstellt, die bis auf den Namen genau gleich aufgebaut sind. Beide Bibliotheken enthalten eine Struktur, eine globale Variablenliste und eine Funktion.

Zum Test wird ein neues Projekt angelegt, in dem beide Bibliotheken eingefügt werden. Sobald versucht wird, eines der Objekte, die in den Bibliotheken definiert wurden zu benutzen, gibt der Compiler eine Fehlermeldung aus:

Sowohl die Struktur ST_Value als auch die Funktion F_GetString() sind jeweils in beiden Bibliotheken definiert. Der Compiler kann nicht eindeutig zuordnen, aus welcher Bibliothek er das entsprechende Element nehmen soll. Um die Zuordnung wieder eindeutig zu machen, kann vor dem Typbezeichner der Namespace der Bibliothek angegeben werden. Der Namespace einer Bibliothek entspricht, per Standardeinstellung, dem Name der Bibliothek. Bei der Entwicklung einer Bibliothek kann aber auch eine andere Bezeichnung gewählt werden.

Allerdings kann es jetzt immer noch passieren, dass der Namespace zweier Bibliotheken gleich ist. Wenn dann beide Bibliotheken auch noch gleiche Bezeichner beinhalten, tritt das oben genannte Problem immer noch auf. Um dieses weiter zu minimieren, definiert die CoDeSys Automation Alliance (CAA) z.B. Richtlinien für die Entwicklung von SPS-Bibliotheken. Dadurch soll u.a. die Namensgebung vereinheitlicht und die Anwendung vereinfacht werden.

Anmerkung: Obwohl in beiden SPS-Bibliotheken die Struktur ST_Value gleich aufgebaut ist, handelt es sich um zwei verschiedene Datentypen. Das bedeutet, dass in dem oberen Beispiel die Variablen stValue01 und stValue02 nicht einander zugewiesen werden können.

stValue01 := stValue02;

Diese Zuweisung würde der Compiler mit der Fehlermeldung ‘Cannot convert type ‘PLCLibrary01.ST_Value’ to type ‘PLCLibrary02.ST_Value’ ablehnen.

Author: Stefan Henneken

I’m Stefan Henneken, a software developer based in Germany. This blog is just a collection of various articles I want to share, mostly related to Software Development. View all posts by Stefan Henneken