Datentypen und Variablen in der SPS

Stell dir vor, eine SPS soll sich einen Wert merken – etwa die Stückzahl an einem Förderband. Dieser Wert muss irgendwo im Speicher liegen, und das Programm muss wissen, wo. Genau dafür gibt es Variablen. Eine Variable ist ein benannter Platz im Speicher, unter dem ein Wert abgelegt wird. Statt mit kryptischen Speicheradressen zu hantieren, schreibt man im Programm einfach Stueckzahl und meint damit immer denselben Wert.

Eine Variable besteht aus drei Teilen: einem Namen (Stueckzahl), einem Datentyp (etwa eine Ganzzahl) und dem aktuellen Wert (zum Beispiel 42). Der Name ist für den Menschen da, der Datentyp und der Wert für die Steuerung.

Warum reicht es nicht, einfach „alles als Zahl“ zu speichern? Weil eine SPS nur begrenzten Speicher hat und mit klaren Regeln arbeiten muss. Der Datentyp legt drei Dinge fest:

• Speicherbedarf: Ein einzelnes Ja/Nein-Signal braucht nur ein Bit. Eine große Zählnummer braucht mehr Platz. Würde man jedem Signal denselben großen Speicher zuweisen, wäre der Merkerbereich schnell voll.
• Wertebereich: Jeder Datentyp kann nur einen bestimmten Zahlenbereich abdecken. Wer das überschreitet, bekommt falsche Ergebnisse.
• Erlaubte Operationen: Auf einem Wahrheitswert kann man UND und ODER rechnen, aber keine Division. Auf einer Zahl umgekehrt. Der Datentyp sorgt dafür, dass nur sinnvolle Operationen zugelassen werden.

Es gibt noch einen vierten, oft übersehenen Aspekt: Datentypen schützen vor Flüchtigkeitsfehlern. Wenn das Programmiersystem weiß, dass Stueckzahl eine Ganzzahl ist, meldet es einen Fehler, sobald jemand versehentlich einen Wahrheitswert zuweisen will. Diese Prüfung passiert schon beim Übersetzen des Programms, lange bevor die Anlage läuft.

In der SPS gibt es zwei Wege, einen Wert anzusprechen. Die absolute Adressierung zeigt direkt auf eine Speicherstelle, etwa %I0.0 für einen Eingang, %Q0.1 für einen Ausgang oder %MW10 für ein Merkerwort. Die symbolische Variable dagegen trägt einen Namen wie Starttaster und überlässt es dem System, sich um die Speicherstelle zu kümmern. Moderne Programme arbeiten fast nur noch symbolisch. Wie genau Eingänge, Ausgänge und Merker adressiert werden, ist ein Thema für sich und wird in einem eigenen Beitrag behandelt – hier reicht das Grundverständnis, dass hinter jeder Variablen letztlich eine Speicherstelle mit einem Datentyp steht.

Die kleinste Informationseinheit in der SPS ist ein einzelnes Bit – es kann nur zwei Zustände annehmen: 0 oder 1, falsch oder wahr. Genau dafür gibt es den Datentyp BOOL (von „boolean“, also Wahrheitswert). Ein BOOL belegt logisch ein Bit und kennt nur die Werte TRUE und FALSE. Jeder Eingang, jeder Ausgang, jeder Verriegelung, jedes Meldebit ist im Kern ein BOOL.

Oft will man aber nicht ein einzelnes Bit betrachten, sondern eine ganze Gruppe von Bits als Block. Dafür gibt es drei Datentypen, die reine Bitmuster sind – also Sammlungen von Bits ohne eine feste Bedeutung als Zahl:

Wichtig ist der Unterschied zwischen einem logischen Wert und einer Bitsammlung. Ein BOOL steht für eine klare Ja/Nein-Aussage: Der Taster ist gedrückt oder nicht. BYTE, WORD und DWORD dagegen sind einfach Behälter für mehrere Bits. Sie sagen nichts darüber aus, ob es sich um eine Zahl, ein Zeichen oder eine Gruppe einzelner Meldebits handelt. Man verwendet sie überall dort, wo es auf die einzelnen Bits ankommt und nicht auf einen rechnerischen Wert – etwa bei einem Statuswort, in dem jedes Bit eine andere Meldung trägt, oder bei Bitmasken.

Wann nimmt man ein WORD und wann eine Zahl wie INT? Faustregel: Sobald man mit dem Wert rechnen will (addieren, vergleichen, multiplizieren), nimmt man einen Zahlentyp. Will man dagegen einzelne Bits setzen, abfragen oder maskieren, ist ein Bitmuster-Typ wie WORD die richtige Wahl. Beide belegen bei gleicher Größe denselben Speicher – der Unterschied liegt allein darin, wie das Programm den Inhalt interpretaiert.

Sobald die SPS mit ganzen Zahlen rechnen soll – Stückzahlen, Positionen, Zählwerte – kommen die Ganzzahl-Datentypen ins Spiel. Sie unterscheiden sich in zwei Eigenschaften: in der Bitbreite (wie viele Bits, also wie groß der Wertebereich) und im Vorzeichen (ob nur positive Werte oder auch negative möglich sind).

Datentypen mit Vorzeichen heißen signed, solche ohne unsigned. Bei den signed-Typen wird ein Teil des Wertebereichs für negative Zahlen reserviert. Die unsigned-Varianten nutzen den ganzen Bereich für positive Zahlen, können dafür aber gar nicht negativ werden.

Den Wertebereich kann man ausrechnen. Bei einem unsigned-Typ mit n Bit gilt:

Ein USINT mit 8 Bit deckt also 2⁸ = 256 Werte ab, nämlich 0 bis 255. Bei signed-Typen wird etwa die Hälfte der Werte für negative Zahlen verwendet:

Bei einem INT mit 16 Bit ergibt das ein Minimum von −2¹⁵ = −32768 und ein Maximum von 2¹⁵ − 1 = +32767.

Warum kann ein signed-Typ überhaupt negative Zahlen darstellen? Die Antwort liegt im Zweierkomplement – der Methode, mit der praktisch alle Steuerungen negative Ganzzahlen im Speicher ablegen. Die Grundidee: Das höchstwertige Bit (MSB) bekommt eine besondere Rolle als Vorzeichenbit. Ist es 0, ist die Zahl positiv (oder null), ist es 1, ist sie negativ. Aber es ist kein bloßes „Minus-Schild“, das man davorhängt. Stattdessen werden die negativen Zahlen so kodiert, dass die normale Addition automatisch das richtige Ergebnis liefert – die Hardware muss für die Subtraktion also nichts Besonderes können, sie addiert einfach.

Eine negative Zahl bildet man im Zweierkomplement, indem man alle Bits des Betrags umkehrt (aus 0 wird 1, aus 1 wird 0) und anschließend 1 addiert. Bei 8 Bit wird aus +1 (0000 0001) durch Umkehren 1111 1110 und nach dem Addieren von 1 schließlich 1111 1111 – das ist die Darstellung von −1.

Ganze Zahlen reichen nicht für alles. Sobald gebrochene Werte ins Spiel kommen – ein Temperatursollwert von 21,5 °C, ein Druck von 4,75 bar, ein Verstärkungsfaktor von 0,8 – braucht man einen Datentyp, der Nachkommastellen kann. Das ist der REAL, ein 32-Bit-Datentyp für Fließkommazahlen (auch Gleitkommazahlen genannt). Er speichert die Zahl nicht starr, sondern in der Form „Wert mal Zehnerpotenz“, ähnlich der wissenschaftlichen Schreibweise. Dadurch deckt er einen riesigen Bereich von sehr kleinen bis sehr großen Werten ab.

Der Komfort hat einen Preis: begrenzte Genauigkeit. Ein REAL hat etwa sieben signifikante Stellen. Viele Dezimalzahlen lassen sich im Binärsystem nicht exakt darstellen, sondern nur sehr nah angenähert. Das führt zu winzigen Rundungsabweichungen. Für die meisten Mess- und Stellgrößen ist das völlig unkritisch, aber es hat eine wichtige Folge für Vergleiche.

Deshalb gilt eine zentrale Regel: REAL-Werte nie direkt mit „gleich“ vergleichen. Eine Abfrage wie „ist der Istwert exakt gleich 100,0?“ schlägt in der Praxis fast immer fehl, weil der berechnete Wert vielleicht 99,99999 oder 100,00001 ist. Statt auf Gleichheit prüft man auf einen Bereich: „liegt der Wert nahe genug an 100,0, etwa zwischen 99,9 und 100,1?“. Bei Ganzzahlen ist der Gleichheitsvergleich dagegen unproblematisch, weil sie exakt gespeichert werden.

Wer höhere Genauigkeit braucht – etwa bei langen Rechenketten oder sehr feinen Messwerten – greift in modernen Steuerungen zum LREAL, einem 64-Bit-Fließkommatyp mit rund fünfzehn signifikanten Stellen. In Systemen wie TIA Portal oder TwinCAT is LREAL bei anspruchsvollen Berechnungen längst Standard. Das Grundproblem der nicht ganz exakten Darstellung bleibt allerdings auch beim LREAL bestehen – der Gleichheitsvergleich ist also weiterhin tabu.

Eine eigene Gruppe bilden die Zeit-Datentypen. Der wichtigste ist TIME: Er speichert eine Zeitdauer, etwa für Verzögerungen. Geschrieben wird ein solcher Wert mit dem Präfix T#, gefolgt von der Dauer – zum Beispiel T#5s für fünf Sekunden, T#500ms für eine halbe Sekunde oder T#1m30s für anderthalb Minuten. TIME ist kein Datum und keine Uhrzeit, sondern reine Zeitspanne. Genau diese Werte braucht man, um Zeitfunktionen wie die Einschalt- oder Ausschaltverzögerung zu parametrieren – das Thema dieser Zeitfunktionen wird in einem eigenen Beitrag ausführlich behandelt; hier reicht zu wissen, dass deren Zeitvorgaben vom Typ TIME sind.

Bevor eine Variable im Programm benutzt werden kann, muss sie deklariert werden – also angemeldet mit Name und Datentyp. In der Deklaration legt man fest, wie die Variable heißt, welchen Typ sie hat und optional, mit welchem Startwert sie beim Programmstart beginnt. Eine typische Deklaration sieht sinngemäß so aus: Name Fuellmenge, Typ INT, Startwert 0. Ab diesem Moment kennt das System die Variable und weiß, was mit ihr erlaubt ist.

Bei den Namen lohnt sich Disziplin. Namenskonventionen sorgen dafür, dass man im Programm sofort erkennt, was gemeint ist. Bewährt haben sich sprechende Namen ohne Umlaute und Leerzeichen, oft mit einer kurzen Vorsilbe für die Art der Variablen – etwa eine Kennung für Eingänge, Ausgänge oder Merker. Wichtig ist vor allem Einheitlichkeit: Wer einmal Sollwert_ml schreibt, sollte nicht an anderer Stelle sollwertMilliliter verwenden. Konsequente Benennung spart bei der Fehlersuche mehr Zeit als jede andere Maßnahme.

Variablen unterscheiden sich auch in ihrer Gültigkeit. Eine lokale Variable ist nur innerhalb des Programmbausteins bekannt, in dem sie deklariert wurde – außerhalb existiert sie nicht. Eine globale Variable dagegen ist im ganzen Projekt sichtbar und kann von mehreren Bausteinen genutzt werden. Faustregel: So lokal wie möglich, so global wie nötig. Lokale Variablen halten die Bausteine übersichtlich und verhindern, dass sich verschiedene Programmteile versehentlich gegenseitig Werte überschreiben. Global macht man nur das, was wirklich mehrere Bausteine gemeinsam brauchen.

Eine besondere Form ist die Konstante: ein Wert, der nach der Festlegung nicht mehr verändert wird, etwa ein fester Umrechnungsfaktor oder eine maximale Stückzahl. Konstanten bekommen einen sprechenden Namen und machen das Programm lesbarer – MAX_STUECKZAHL sagt mehr als eine nackte Zahl mitten im Code, und ändert sich der Grenzwert, muss man ihn nur an einer Stelle anpassen.

Ein häufiger Stolperstein ist die Typumwandlung. Will man einer REAL-Variablen das Ergebnis einer INT-Rechnung zuweisen oder umgekehrt, müssen die Typen zusammenpassen. Viele Systeme verlangen dafür eine ausdrückliche, explizite Typumwandlung mit Funktionen wie INT_TO_REAL oder REAL_TO_INT. Das ist kein Schikane, sondern Schutz: Beim Umwandeln von REAL nach INT gehen die Nachkommastellen verloren, und der Programmierer soll bewusst entscheiden, dass das in Ordnung ist. Eine implizite Umwandlung, bei der das System ungefragt selbst umrechnet, ist bei manchen Typen erlaubt, sollte aber mit Vorsicht genossen werden – sie verschleiert, was tatsächlich passiert.