SPS-Programmierung mit IEC 61131-3: Konzepte und Programmiersprachen, Anforderungen an Programmiersysteme, Entscheidungshilfen, Edition 4 (VDI-Buch) (German Edition)

SPS-Programmierung mit IEC 61131-3 4., neubearbeitete Auflage

Karl Heinz John • Michael Tiegelkamp

SPS-Programmierung mit IEC 61131-3 Konzepte und Programmiersprachen, Anforderungen an Programmiersysteme, Entscheidungshilfen 4., neubearbeitete Auflage

1C

Karl Heinz John Irrlrinnig 13 91301 Forchheim Deutschland [email protected]

Michael Tiegelkamp Kurpfalzstr. 34 90602 Pyrbaum Deutschland [email protected]

ISBN 978-3-642-00268-7 e-ISBN 978-3-642-00269-4 DOI 10.1007/978-3-642-00269-4 Springer Dordrecht Heidelberg London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 1995, 1997, 2000, 2009 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort zur 4. überarbeiteten Auflage

In den letzten Jahren setzte sich die IEC 61131 (bis 1998 „IEC 1131“) als Programmierstandard in der Automatisierungs-Industrie auf breiter Front durch. Von kleinen bis zu den großen SPS-Herstellern bieten heute sehr viele Programmiersysteme an, die diese Norm als Grundlage benutzen. Zusätzliche Standards und Empfehlungen – wie z.B. für Motion Control - erweitern die IEC 61131 um Funktionalität, die sich aus den steigenden Anforderungen des Markts ergeben. Eine der wichtigsten Weiterentwicklungen stellt die Norm IEC 61499 (ehemals IEC 1499) dar. Ihr ist Kap. 9 gewidmet und ihre Bedeutung für dezentrale SPSSysteme wird in Kap 7.9 angesprochen. Heute liegt die IEC 61131 in einer zweiten Version vor. In der vorliegenden 4. Buchauflage wurden die zahlreichen Änderungen und Ergänzungen dieser Norm eingebracht. Ein umfangreiches Stichwort-Verzeichnis (Index) am Ende des Buchs erleichtert eine schnelle Themensuche. Die beiliegenden DVD und CD enthalten die vollständigen Demo-Versionen zweier Programmiersysteme in aktuellen Versionen. Dadurch kann der Leser Erkenntnisse aus diesem Buch sofort umsetzen und sein Wissen durch praktische Anwendung festigen. Wir danken den Firmen SIEMENS AG und infoteam Software GmbH für die Bereitstellung dieser beiliegenden Software. Besonders bedanken wir uns wieder bei Hans-Peter Otto, Mitglied in den IEC- und DKE-Normungsgremien, der uns tatkräftig unterstützte und auch selbst weitere Anregungen mitnahm. Wir freuen uns über das große Interesse an diesem Buch und danken unseren aufmerksamen Lesern für viele Anregungen und entdeckte Druckfehler.

Karl-Heinz John

Winter 2008

Michael Tiegelkamp

Inhaltsverzeichnis

1 Einleitung.............................................................................................................9 1.1 Gegenstand des Buchs .....................................................................................10 1.2 Die Norm IEC 61131 .......................................................................................12 1.2.1 Ziele und Nutzen der Norm...........................................................................13 Hersteller (SPS- Hardware und -Software). ............................................................................13 Anwender................................................................................................................................13

1.2.2 Geschichte und Bestandteile .........................................................................14 1.3 OrganisationPLCopen......................................................................................17 1.3.1 Ziele von PLCopen .......................................................................................17 1.3.2 Gremien und Arbeitsgebiete .........................................................................18 1.3.3 Ergebnisse.....................................................................................................18 2 Bausteine der IEC 61131-3...............................................................................21 2.1 Einstieg in die neue Norm................................................................................21 2.1.1 Aufbau von Bausteinen .................................................................................22 Deklarationen von Variablen. .................................................................................................22 Anweisungsteil einer POE. .....................................................................................................23

2.1.2 Einführungsbeispiel in AWL ........................................................................25 2.1.3 SPS-Zuordnung.............................................................................................28 2.2 Die Programmorganisationseinheit (POE).......................................................30 2.3 Elemente einer POE.........................................................................................32 2.3.1 Beispiel .........................................................................................................33 2.3.2 Deklarationsteil .............................................................................................34 Variablenarten in POE-Typen.................................................................................................35 Merkmale der POE-Schnittstelle.............................................................................................36 Externer und interner Zugriff auf POE-Variablen...................................................................38

2.3.3 Anweisungsteil..............................................................................................40 2.4 Der Funktionsbaustein .....................................................................................42 2.4.1 Instanziierung von Funktionsbausteinen .......................................................42 Was ist eine Instanz?...............................................................................................................42 Instanz bedeutet „Struktur“. ....................................................................................................44 Instanz bedeutet „Gedächtnis“. ...............................................................................................46 Zusammenhang zwischen FB-Instanz und Datenbaustein. .....................................................47

2.4.2 Wiederverwendbarkeit und Objektorientierung von FB ...............................48 2.4.3 Variablenarten in FBs ...................................................................................49

2

Inhaltsverzeichnis

2.5 Die Funktion ....................................................................................................50 2.5.1 Variablenarten in Funktionen und ihr Funktionswert....................................50 2.6 Das Programm PROGRAM .............................................................................53 2.7 Ausführungssteuerung mit EN und ENO .........................................................54 2.8 Aufrufe von Funktionen und Funktionsbausteinen...........................................57 2.8.1 Gegenseitiger Aufruf zwischen POEs ...........................................................57 2.8.2 Rekursive Aufrufe sind unzulässig................................................................58 2.8.3 Erweiterbarkeit und Überladen .....................................................................60 2.8.4 Aufruf mit Formalparametern .......................................................................60 2.8.5 Aufrufe mit fehlenden oder vertauschten Eingangsparametern.....................63 2.8.6 FB-Instanzen als FB-Aktualparameter ..........................................................64 Beispiel für indirekten FB-Aufruf...........................................................................................65 FB-Instanznamen als Aktualparameter von Funktionen. ........................................................67 Funktionswerte als Aktualparameter.......................................................................................67 Initialisierung von FB-Instanzen. ............................................................................................67

2.9 POE-Merkmalsübersicht ..................................................................................68 3 Variablen, Datentypen und gemeinsame Elemente........................................69 3.1 Einfache Sprachelemente .................................................................................69 3.1.1 Reservierte Schlüsselworte ...........................................................................71 3.2 Literale und Bezeichner ...................................................................................72 3.2.1 Literale..........................................................................................................72 3.2.2 Bezeichner ....................................................................................................74 3.2.3 Kommentare..................................................................................................76 3.2.4 Pragmas.........................................................................................................76 3.3 Bedeutung von Datentypen und Variablen.......................................................77 3.3.1 Von direkten SPS-Adressen über Symbole zu Variablen..............................77 3.3.2 Der Datentyp bestimmt Eigenschaften der Variablen ...................................79 3.3.3 Typgerechte Verwendung von Variablen......................................................79 3.3.4 Automatische Abbildung von Variablen auf die SPS....................................80 3.4 Datentypen .......................................................................................................81 3.4.1 Elementare Datentypen .................................................................................81 3.4.2 Abgeleitete Datentypen (Typdefinition) .......................................................82 Zusätzliche Eigenschaften für Elementare Datentypen. ..........................................................83 Felder. .....................................................................................................................................86 Datenstrukturen. .....................................................................................................................87 Anfangswerte bei Typdefinition..............................................................................................89

3.4.3 Allgemeine Datentypen.................................................................................90 3.5 Variable............................................................................................................92 3.5.1 Eingänge, Ausgänge und Merker als besondere Variablen ...........................93 3.5.2 Multielement-Variable: Felder und Strukturen .............................................95 3.5.3 Zuweisung von Anfangswerten bei Programmstart.......................................96 3.5.4 Attribute der Variablenarten .........................................................................98 3.5.5 Grafische Darstellung von Variablen-Deklarationen ..................................100

3

4 Die Programmiersprachen der IEC 61131-3 ................................................103 4.1 Anweisungsliste AWL ...................................................................................104 4.1.1 Anweisung in AWL ....................................................................................104 4.1.2 Der universelle Akkumulator ......................................................................105 4.1.3 Anweisungsteil: Operatoren........................................................................108 Negierung des Operanden.....................................................................................................108 Schachtelungsebenen durch Klammerung. ...........................................................................108 Bedingte Ausführung von Operatoren. .................................................................................110

4.1.4 Verwendung von Funktionen und Funktionsbausteinen..............................112 Aufruf von Funktionen. ........................................................................................................112 Aufruf von Funktionsbausteinen...........................................................................................114

4.2.5 Beispiel AWL: Bergbahn............................................................................116 4.2 Strukturierter Text ST ....................................................................................119 4.2.1 Anweisung in ST.........................................................................................119 4.2.2 Ausdruck als Teilanweisung in ST..............................................................121 Operanden.............................................................................................................................121 Operatoren. ...........................................................................................................................122 Funktionen als Operatoren. ...................................................................................................124

4.2.3 Anweisung: Zuweisung ...............................................................................124 4.2.4 Anweisung: Aufruf von Funktionsbausteinen .............................................126 4.2.5 Anweisung: Rücksprung (RETURN)..........................................................126 4.2.6 Anweisung: Verzweigung, Multiauswahl....................................................127 Alternativ-Verzweigung........................................................................................................127 Multiauswahl. .......................................................................................................................128

4.2.7 Anweisung: Wiederholung..........................................................................130 WHILE- und REPEAT-Anweisungen...................................................................................130 FOR-Anweisung. ..................................................................................................................131 EXIT-Anweisung. .................................................................................................................133

4.2.8 Beispiel Stereo-Rekorder ............................................................................134 4.3 Funktionsbausteinsprache FBS ......................................................................137 4.3.1 Netzwerke, grafische Elemente mit Verbindungen (KOP, FBS) ................137 Netzwerkmarke. ....................................................................................................................137 Netzwerkkommentar.............................................................................................................138 Netzwerkgrafik. ....................................................................................................................138

4.3.2 Netzwerkaufbau in FBS ..............................................................................140 4.3.3 Grafische Objekte in FBS ...........................................................................142 Verbindungen. ......................................................................................................................143 Ausführungssteuerung (Sprünge)..........................................................................................143 Aufruf von Funktionen und Funktionsbausteinen.................................................................144

4.3.4 Programmiertechnik in FBS........................................................................146 Werteberechnung. .................................................................................................................146 Rückkopplungsvariable. .......................................................................................................148

4.3.5 Beispiel Stereo-Rekorder in FBS................................................................148 Kommentierung der Netzwerke der Bsp. 4.25 und Bsp. 4.33 ...............................................151

4.4 Kontaktplan KOP...........................................................................................152 4.4.1 Netzwerke, grafische Elemente mit Verbindungen (KOP) .........................152 4.4.2 Netzwerkaufbau in KOP .............................................................................153

4

Inhaltsverzeichnis

4.4.3 Grafikobjekte in KOP .................................................................................153 Verbindungen. ......................................................................................................................154 Kontakte und Spulen.............................................................................................................154 Ausführungssteuerung. .........................................................................................................158 Aufruf von Funktionen und Funktionsbausteinen.................................................................159

4.4.4 Programmiertechnik in KOP.......................................................................161 Werteberechnung. .................................................................................................................161 Rückkopplungsvariable. .......................................................................................................162

4.4.5 Beispiel KOP: Bergbahn.............................................................................163 Kommentierung der Bergbahn-Netzwerke............................................................................167

4.5 Ladder: eine Variante der KOP Programmierung ..........................................169 4.5.1 Netzwerkaufbau Ladder ..............................................................................170 4.5.2 Moduladressen und Speicherbereiche.........................................................171 4.6 Ablaufsprache AS ..........................................................................................174 4.6.1 Aufbau durch Schritte und Transitionen .....................................................175 4.6.2 Ablaufketten................................................................................................176 4.6.3 Detail-Beschreibung der Schritte und Transitionen ....................................182 Schritt. ..................................................................................................................................182 Transition..............................................................................................................................184

4.6.4 Schrittbearbeitung durch Aktionsblöcke und Aktionen ..............................189 4.6.5 Detailbeschreibung Aktionen und Aktionsblöcke .......................................191 Aktionen. ..............................................................................................................................191 Aktionsblock.........................................................................................................................191

4.6.6 Zusammenhang von Schritt, Transition, Aktion und Aktionsblock ............194 4.6.7 Bestimmungszeichen und Ablaufsteuerung.................................................198 Bestimmungszeichen. ...........................................................................................................198 Ablaufsteuerung....................................................................................................................206

4.6.8 Beispiel Dino-Park......................................................................................208 Kommentierung des Vergnügungspark-Netzwerks...............................................................211

5 Standardisierte SPS-Funktionalität ..............................................................213 5.1 Standard-Funktionen......................................................................................214 5.1.1 Überladen und Erweitern ............................................................................218 Überladen von Funktionen....................................................................................................218 Erweiterbarkeit von Funktionen............................................................................................220

5.1.2 Beispiele .....................................................................................................221 Funktionen zur Typumwandlung. .........................................................................................222 Numerische Funktionen. .......................................................................................................223 Arithmetische Funktionen.....................................................................................................223 Schiebe-Funktionen. .............................................................................................................224 Bitfolge-Funktionen..............................................................................................................224 Funktionen für Auswahl. ......................................................................................................225 Funktionen für Vergleich. .....................................................................................................226 Funktionen für Zeichenfolgen...............................................................................................227 Funktionen für Datentyp Zeit................................................................................................228 Funktionen für Aufzählungstypen.........................................................................................229

5

5.2 Standard-Funktionsbausteine .........................................................................230 5.2.1 Beispiele .....................................................................................................232 Bistabile Elemente (Flip-Flops). ...........................................................................................234 Flankenerkennung.................................................................................................................234 Vorwärts/Rückwärts-Zähler. .................................................................................................237 Zeitgeber (Zeiten). ................................................................................................................238

6 Zeitgemäße SPS-Konfiguration .....................................................................241 6.1 Projekt-Strukturierung durch Konfigurationselemente ..................................242 6.2 Elemente einer realen SPS-Konfiguration......................................................243 6.3 Die Konfigurationselemente ..........................................................................245 6.3.1 Aufgaben.....................................................................................................245 6.3.2 Die CONFIGURATION .............................................................................246 6.3.3 Die RESOURCE.........................................................................................247 6.3.4 Die TASK mit Laufzeitprogramm ..............................................................248 6.3.5 Die ACCESS-Deklaration...........................................................................251 6.4 Konfigurations-Beispiel .................................................................................253 6.5 Kommunikation bei Konfigurationen und POEs............................................255 7 Innovative SPS-Programmiersysteme ...........................................................259 7.1 Anforderungen an innovative Programmierwerkzeuge ..................................259 7.2 Rückübersetzung (Rückdokumentation) ........................................................260 7.2.1 Keine Rückübersetzung ..............................................................................261 7.2.2 Rückübersetzung mit Symbolik und Kommentaren ....................................261 7.2.3 Rückübersetzung inkl. Grafik-Information .................................................262 7.2.4 Quellcode in der SPS ..................................................................................262 7.3 Sprachverträglichkeit .....................................................................................262 7.3.1 Querübersetzbarkeit ....................................................................................263 Motivation für Querübersetzbarkeit......................................................................................263 Unterschiedlicher Ansatz der grafischen und textuellen Sprachen........................................264 Unterschiede in den Sprachen beeinflussen die Querübersetzbarkeit. ..................................265 Einschränkungen bei KOP / FBS..........................................................................................266 Einschränkungen bei AWL / ST. ..........................................................................................266 Querübersetzbarkeit AWL / ST.............................................................................................267 Volle Querübersetzbarkeit nur durch Zusatzinformation erreichbar. ....................................267 Gütekriterien für die Querübersetzbarkeit.............................................................................268

7.3.2 Sprachunabhängigkeit aufgerufener POEs..................................................269 7.4 Dokumentation...............................................................................................270 7.4.1 Querverweisliste..........................................................................................271 7.4.2 Zuordnungsliste (Verdrahtungsliste)...........................................................271 7.4.3 Kommentierbarkeit .....................................................................................272 7.5 Projektverwaltung ..........................................................................................272 7.6 Test&Inbetriebnahme-Funktionen .................................................................276 7.6.1 Programmtransfer........................................................................................277 7.6.2 Online-Änderung des Programms ...............................................................277 7.6.3 Fernbedienung: Start und Stopp der SPS ....................................................278 7.6.4 Variablen- und Programm-Status................................................................279 7.6.5 Forcing........................................................................................................283

6

Inhaltsverzeichnis

7.6.6 Programmtest ..............................................................................................284 7.6.7 Programmtest in Ablaufsprache ..................................................................284 7.7 Datenbausteine und Rezepturen.....................................................................284 7.8 FB-Verschaltung ............................................................................................288 7.8.1 Datenaustausch und Koordination von Bausteinen in verteilten Systemen.288 7.8.2 Makrotechnik bei FB-Verschaltung ............................................................291 7.9 Diagnose, Fehlererkennung und -Reaktion ....................................................292 Allgemeines Fehlerkonzept der IEC 61131-3. ......................................................................293 Erweitertes Fehlermodell (nicht IEC)....................................................................................294

7.10 Hardware-Abhängigkeiten ...........................................................................295 8 Stärken der IEC 61131-3................................................................................297 8.1 Komfort und Sicherheit durch Variablen und Datentypen .............................297 8.2 Bausteine mit erweiterten Möglichkeiten.......................................................298 8.3 SPS-Konfiguration mit Laufzeitverhalten ......................................................299 8.4 Einheitliche Sprachen ....................................................................................300 8.5 Strukturierte SPS-Programme ........................................................................300 8.6 Trend zu offeneren SPS-Programmiersystemen.............................................301 8.7 Fazit ...............................................................................................................302 9 Programmierung durch Konfigurierung nach IEC 61499 ..........................303 9.1 Programmierung durch FB-Verschaltung mit IEC 61131-3...........................304 9.2 IEC 61499 - die Norm für verteilte Systeme..................................................304 9.2.1 System-Modell ............................................................................................305 9.2.2 Geräte-Modell.............................................................................................306 9.2.3 Ressource-Modell .......................................................................................307 9.2.4 Anwendungs-Modell...................................................................................308 9.2.5 Funktionsbaustein-Modell...........................................................................309 Zusammengesetzte Funktionsbausteine. ...............................................................................312

9.2.6 Erstellung einer Anwendung .......................................................................313 9.3 Überblick über die Teile der IEC 61499........................................................314 10 Inhalt der beiliegenden CD und DVD .........................................................315 10.1 IEC-Programmiersysteme STEP 7 und OpenPCS .......................................315 Demo-Versionen STEP 7 (Siemens) und Open PCS (infoteam). .........................................316 AWL - Beispiele ...................................................................................................................316

10.2 Einkaufsberater für SPS-Programmiersysteme nach IEC 61131-3 ..............317

7

A Standard-Funktionen.....................................................................................319 A.1 Funktionen zur Typwandlung........................................................................320 A.2 Numerische Funktionen ................................................................................321 A.3 Arithmetische Funktionen .............................................................................322 A.4 Bitschiebe-Funktionen ..................................................................................323 A.5 Bitweise Boolesche Funktionen ....................................................................324 A.6 Auswahl-Funktionen für Max., Min. und Grenzwert ....................................325 A.7 Auswahl-Funktionen für Binäre Auswahl und Multiplexer...........................327 A.8 Vergleichs-Funktionen ..................................................................................328 A.9 Funktionen für Zeichenfolgen .......................................................................330 A.10 Funktionen für Datentypen der Zeit ............................................................333 A.11 Funktionen für Datentypen der Aufzählung ................................................334 B Standard-Funktionsbausteine .......................................................................335 B.1 Bistabile Elemente (Flip-Flops) ....................................................................336 B.2 Flankenerkennung .........................................................................................337 B.3 Zähler ............................................................................................................338 B.4 Zeitgeber (Zeiten)..........................................................................................340 C AWL-Beispiele................................................................................................343 C.1 Beispiel für FUNCTION ...............................................................................343 C.2 Beispiel für FUNCTION_BLOCK................................................................345 C.3 Beispiel für PROGRAM ...............................................................................347 D Standard-Datentypen.....................................................................................351 E Fehlerursachen ...............................................................................................353 F Implementierungsabhängige Parameter.......................................................355 G Beispiel einer AWL-Syntax...........................................................................359 G.1 Syntaxgraphen für AWL ...............................................................................360 G.2 AWL-Beispiel zu Syntaxgraphen..................................................................370 H Reservierte Schlüsselworte und Begrenzungszeichen.................................373 H.1 Reservierte Schlüsselworte............................................................................373 H.2 Begrenzungszeichen......................................................................................377

8

Inhaltsverzeichnis

I Glossar..............................................................................................................381 J Literaturverzeichnis .......................................................................................387 K Index ...............................................................................................................393 Autorenbiographien...........................................................................................401 Karl-Heinz John ...................................................................................................401 Michael Tiegelkamp ............................................................................................401

1 Einleitung

Durch den rasanten Fortschritt bei Leistung und Miniaturisierung in der Mikrotechnologie erschließt sich die Speicherprogrammierbare Steuerung (SPS) immer neue Märkte. Speziell konzipierte Regel- und Steuerhardware oder PC-basierte Controller, erweitert um realzeitfähige Hard- und Software, kontrollieren höchst komplexe Automatisierungsprozesse. Neu hinzugekommen ist das Thema „Sicherheitsgerichtete Steuerung“ zur Verhinderung von Personenschäden durch Maschinen im Produktionsprozess. Die SPSen decken durch ihre unterschiedlichen Ausprägungen ein weites Aufgabenspektrum ab — dies reicht von kleinen Knotenrechnern in Netzwerken und dezentral eingesetzten Kompaktgeräten bis hin zur modularen, fehlertoleranten Hochleistungs- SPS. Sie unterscheiden sich in Leistungsmerkmalen wie Verarbeitungsgeschwindigkeit, Vernetzungsfähigkeit oder das Angebot verwendbarer Peripherie-Baugruppen. Der Begriff SPS sei im Weiteren als Technologie verstanden; dies weicht vom amerikanischen Begriff PLC (Programmable Logic Controller) ab, der darunter lediglich eine bestimmte Hardware-Architektur — im Gegensatz zu den PCControllern (Soft Logic Array) — versteht. Mit den IEC 61131 Programmiersprachen lassen sich klassische SPSen, embedded Controller, Industrie- PCs, ja sogar Standard- PCs programmieren, wenn geeignete Hardware zum Anschluss an Sensoren und Aktoren vorhanden ist (z.B. Feldbuskarte). Dieses Spektrum der Leistungsfähigkeit seitens der Hardware erfordert eine entsprechende Unterstützung durch geeignete Programmierwerkzeuge, die eine kostengünstige und qualitätsbewusste Erstellung einfacher wie umfangreicher Anwender-Programme ermöglicht, beispielsweise: -

Gleichzeitige Unterstützung mehrerer SPS-Programmiersprachen, Änderung der Programme „on-line“ in der SPS, Rückdokumentation der Programme aus der SPS, Wiederverwendbarkeit von SPS-Programm-Bausteinen, Test und Simulation der Anwenderprogramme „off-line“, Integrierte Projektierungs- und Inbetriebnahme-Werkzeuge, Qualitätssicherung, Projektdokumentation, Verwendung von Systemen mit offenen Schnittstellen.

10

1 Einleitung

Auf der Basis von PCs entstanden in den letzten 10 Jahren immer leistungsfähigere SPS-Programmierwerkzeuge. Die bisher verwendeten klassischen SPS-Programmiersprachen wie Anweisungsliste, Kontaktplan oder Funktionsplan stoßen an ihre Grenzen. Die Anwender fordern einheitliche, herstellerübergreifende Sprachkonzepte, höhere Programmiersprachen und Entwicklungswerkzeuge, wie sie im Bereich der PC-Welt bereits seit längerem üblich sind. Mit Einführung der internationalen Norm IEC 1131 (inzwischen unbenannt in IEC 61131) wurde eine Basis für eine einheitliche SPS-Programmierung geschaffen, die effiziente Konzepte der Software-Technologie berücksichtigt. Die Norm liegt inzwischen in einer überarbeiteten 2. Ausgabe vor, die vollständig in das Buch eingearbeitet ist.

1.1 Gegenstand des Buchs Dieses Buch hat zum Ziel, eine verständliche Einführung in die Konzepte und Sprachen der Norm IEC 61131 zu geben. Dabei werden einfache Beispiele verwendet, um die Ideen und Anwendung der neuen SPS-Programmiersprachen zu erklären. Ein größeres Beispiel-Programm fasst jeweils die Ergebnisse eines Abschnitts nochmals zusammen. Das Buch versteht sich als Einführung und Erklärungshilfe für Leute in Ausbildung und Praxis, welche die Möglichkeiten der neuen Norm kennenlernen und nutzen möchten. Das Buch beschreibt die Methodik der Norm aus einer herstellerunabhängigen Sicht. Spezielle Ausprägungen und Varianten einzelner Programmiersysteme sollten den jeweiligen Handbüchern vorbehalten sein. Es setzt geringe Kenntnisse im Umgang mit Personal Computern und Grundkenntnisse im Bereich der SPS-Technik voraus (siehe dazu [Berger-03] oder [Berger-06]). Auch erfahrene SPS-Programmierer finden hier Informationen, die ihnen die Arbeit mit diesen Programmiersystemen erleichtern. Das Buch legt Wert darauf, den Standard selbst zu beschreiben und weniger die entsprechenden Varianten der Programmiersysteme auf dem Markt. Berufsschüler und Studenten erhalten ein Nachschlagewerk, das ihnen systematisch das Erlernen des neuen Programmierstandards erleichtert. Mit Hilfe des „Einkaufsberaters“ kann der Leser zusätzlich SPS-Programmiersysteme selbst und individuell beurteilen, siehe beiliegende CD.

1.1 Gegenstand des Buchs

11

Formale Inhalte und Aufbau der IEC werden praxisgerecht dargestellt, schwierige Sachverhalte im Zusammenhang erläutert und Interpretationsspielräume sowie Erweiterungsmöglichkeiten aufgezeigt. Dieses Buch soll helfen, dem Leser konkrete Antworten auf folgende Fragen zu geben: -

wie erfolgt die Programmierung nach IEC 61131? Was sind die wesentlichen Ideen der Norm, wie werden sie praxisgerecht umgesetzt? wo liegen die Vorteile der internationalen Norm IEC 61131 gegenüber der sonstigen Mikrocontroller- oder PC- Programmierung? was müssen heutige Programmiersysteme leisten, um konform zur IEC 61131 zu sein und diese Norm zu erfüllen? worauf sollte man als Anwender bei der Auswahl eines SPS-Programmiersystems mindestens achten; welche Kriterien sind für die Leistungsfähigkeit von Programmiersystemen ausschlaggebend?

Kapitel 2 stellt die drei Grundbausteine der Norm vor: Programm, Funktion und Funktionsbaustein. Ein Einführungsbeispiel, das die wichtigsten Sprachelemente der Norm beinhaltet und gleichzeitig einen Überblick über ihre Programmiermethodik bietet, schafft einen Einstieg in die Begriffswelt der IEC 61131. Kapitel 3 beschreibt die gemeinsamen Sprachelemente der fünf Programmiersprachen, sowie die Möglichkeit der Datenbeschreibung mit Hilfe von Deklarationen. Es schließen sich in Kapitel 4 die fünf Programmiersprachen der IEC 61131 an, die ausführlich erläutert und jeweils durch ein umfangreicheres Beispiel ergänzt werden. Die Mächtigkeit der IEC 61131 beruht u.a. auf einer einheitlichen Beschreibung häufig verwendeter Bausteine, den sogenannten Standard-Funktionen und -Funktionsbausteinen. Ihre Definition und Verwendungsmöglichkeiten sind in Kapitel 5 beschrieben. Nach der Programmierung erfolgt mittels der Konfiguration eine Zuweisung der Programme und Daten an die Eigenschaften und Hardware der ausführenden SPS. Dies ist in Kapitel 6 zu finden. Der SPS-Markt entwickelte sich zu einer Technologie mit sehr spezifischen Anforderungen. Diese Besonderheiten der Programmerstellung mit einer SPS sowie die Umsetzung mit den Mitteln der IEC 61131 sind das Thema von Kapitel 7. Kapitel 8 fasst die wichtigsten Eigenschaften der Norm aus Kapitel 2 bis 7 zusammen. Die wesentlichen Vorteile der Norm und konformer Programmiersysteme können nochmals nachgelesen werden. Kapitel 9 stellt die Norm IEC 61499 vor, die verteilte Automatisierungsprozesse behandelt. Sie basiert auf IEC 61131-3, erweitert diese jedoch ganz erheblich um eine Sichtweise, die sich aus den Anforderungen an hohe Parallelität und Dezentralisierung moderner Automatisierungsaufgaben ergibt.

12

1 Einleitung

Kapitel 10 erläutert die Benutzung der mitgelieferten CD. Sie beinhaltet Programmierbeispiele dieses Buchs, einen Einkaufsberater in Tabellenform, sowie ablauffähige Versionen zweier IEC -Programmiersysteme. Die sich anschließenden Anhänge liefern weitere Detail-Informationen zu den Kapiteln. Das Glossar aus Anhang I stellt alphabetisch die wichtigsten Begriffe dieses Buchs mit einer Kurzerklärung zusammen. Anhang J enthält das Literaturverzeichnis, in dem neben Büchern auch Referenzen auf Fachaufsätze zum Thema IEC 61131-3 enthalten sind. In Anhang K ist ein allgemeiner Index zu finden, der zum Auffinden von Stichworten sehr hilfreich sein kann.

1.2 Die Norm IEC 61131 Die mehrteilige Norm IEC 61131 fasst Anforderungsdefinitionen für SPS-Systeme zusammen. Die Anforderungen betreffen die SPS-Hardware und das Programmiersystem. Die Norm umfasst sowohl gängige Konzepte der bisherigen SPS-Programmierung als auch Erweiterungen um neue Programmiermethoden. Die IEC 61131-3 sieht sich als Richtlinie zur SPS-Programmierung, nicht als starr bindende Vorschrift. Die enorme Menge der Festlegungen führte dazu, dass die Programmiersysteme nur einen mehr oder weniger großen Teil der Norm realisiert haben, die durchaus eine unterschiedliche Ausprägung haben können. Diesen Umfang hat der SPS-Hersteller zu dokumentieren: will er normkonform sein, hat er nachzuweisen, in welchen Teilen er die Norm erfüllt oder nicht. Dazu beinhaltet die Norm 62 Tabellen (engl.: feature tables) mit Anforderungsdefinitionen, die vom Hersteller jeweils mit Vermerken („ist erfüllt; ist nicht implementiert; folgende Teile sind erfüllt:...“) zu versehen sind. Die Norm bildet so den Maßstab, an dem sich sowohl Hersteller als auch Anwender orientieren können, um festzustellen, in welchem Maß sich ein Programmiersystem an den Standard hält, d.h. konform zur IEC 61131-3 ist. Zum Nachweis der Konformität definiert die PLCopen, Abschn. 1.3, weitere Tests für Konformitätsklassen, die von unabhängigen Instituten durchgeführt werden können. Die Norm wurde von der Arbeitsgruppe SC65B WG7 (anfangs: SC65A WG6) der internationalen Normungsgruppe IEC (International Electrotechnical Commission) erarbeitet, die sich aus Vertretern verschiedener SPS-Hersteller, Softwarehäusern und Anwendern zusammensetzt. Dies hat den Vorteil, dass sie von den meisten SPS-Herstellern als Richtlinie akzeptiert wird. So hat sich die

1.2 Die Norm IEC 61131

13

IEC 61131-3 in den letzten Jahren als einziger Weltstandard zur SPSProgrammierung durchgesetzt.

1.2.1 Ziele und Nutzen der Norm Durch die ständig steigende Komplexität der SPS-Systeme wachsen die Kosten für: -

die Ausbildung der Anwendungsprogrammierer, die Erstellung der immer größeren Programme, die Implementierung immer komplexerer Programmiersysteme.

Die SPS-Programmiersysteme folgen, zeitlich verzögert, dem Trend des SoftwareMassenmarkts in der PC-Welt. Wie dort lässt sich der Kostendruck vor allem durch Vereinheitlichung, Synergien sowie Wiederverwendung bereits erstellter Software mildern. Hersteller (SPS- Hardware und -Software). Mehrere Hersteller können gemeinsam in die – mit der heute vom Markt geforderten Funktionalität – viele Millionen € teure Programmiersoftware investieren. Die Grundausprägung eines Programmiersystems ist durch die Norm weitgehend festgelegt. Basissoftware wie Editoren kann, bis auf spezifische Teile wie Codegeneratoren oder „on-line“-Module, gemeinsam genutzt werden. Die Marktdifferenzierung erfolgt über sogenannte Zusatzbausteine zum Grundpaket, die in speziellen Marktsegmenten benötigt werden, sowie über die SPS-Hardware. Durch den Zukauf von Fremdprodukten lassen sich die Entwicklungskosten wesentlich verringern. Die Fehleranfälligkeit neu entwickelter Software wird durch die Verwendung bereits erprobter Software stark reduziert Der Entwicklungsaufwand heutiger Programmierwerkzeuge ist durch die geforderte Funktionalität deutlich gewachsen. Durch den Zukauf von Softwarekomponenten (nur ein Teil der Programmierhersteller bietet dies an) oder Komplettsystemen kann die Zeit bis zur Markteinführung wesentlich verkürzt werden, so dass mit der raschen Hardware-Entwicklung Schritt gehalten werden kann. Anwender. Anwender arbeiten oft gleichzeitig mit SPS-Systemen unterschiedlicher Hersteller. Mussten bislang Mitarbeiter mehrere Programmier-Ausbildungen durchlaufen, beschränkt sich dies bei IEC 61131-3- Systemen auf die Bedienspezifika der einzelnen Programmiersysteme und zusätzliche Besonderheiten der SPSen. Systemspezialisten und Ausbildungspersonal können daher eingespart, SPSProgrammierer flexibler eingesetzt werden. Die Anforderungsdefinitionen der Norm erleichtern die Auswahl geeigneter Programmiersysteme, denn sie sind dadurch vergleichbarer geworden.

14

1 Einleitung

Ist auch in nächster Zeit nicht abzusehen, dass vollständige Anwenderprogramme ohne Anpassung zwischen unterschiedlichen SPS-Systemen ausgetauscht werden können, so entsprechen sich doch Sprachelemente und Programmstruktur bei den verschiedenen IEC- Systemen. Dies erleichtert die Portierung auf Fremdsysteme.

1.2.2 Geschichte und Bestandteile Die Norm IEC 61131 stellt eine Zusammenfassung und Fortschreibung verschiedener Normen dar. Sie verweist allein auf 10 internationale Standards (IEC 50, IEC 559, IEC 617-12, IEC 617-13, IEC 848, ISO/AFNOR, ISO/IEC 646, ISO 8601, ISO 7185, ISO 7498). Sie beinhalten Vorschriften über den verwendeten Zeichencode, Definition der verwendeten Nomenklatur oder den Aufbau grafischer Darstellungen. Bereits in der Vergangenheit wurden mehrere Versuche unternommen, eine Norm der SPS-Programmier-Technologie zu etablieren. Der IEC 61131- Standard ist die erste Norm, welche die nötige internationale (und industrielle) Akzeptanz erhält. Die wichtigsten Vorläuferpapiere zur IEC 61131 sind in der Tab. 1.1 zusammengestellt.

Jahr 1977 1979

deutsch DIN 40 719-6 (Funktionspläne)

1982

VDI-Richtlinie 2880, Blatt 4 SPS-Programmiersprachen DIN 19239 SPS-Programmierung

1983 1985

international IEC 848 Start der Arbeitsgruppe für den ersten IEC 61131 Draft Fertigstellung erster Draft IEC 61131; Aufteilung in 5 Unterarbeitsgruppen Christensen Report (Allen Bradley) SPS Programmiersprachen Erste Ergebnisse der IEC 65 A WG6 TF3

Tab. 1.1. Wichtige Vorläufer der IEC 61131-3

DIN EN mit anschließender Nummer bezeichnet die deutsche Norm, bei der internationalen (in englischer Sprache) Version steht dafür die Bezeichnung IEC, gefolgt von der gleichen Nummer. Die Abkürzung Ed. steht für Edition und gibt den jeweiligen Ausgabestand an. TR kürzt Technical Report ab und bezeichnet eine nicht- bindende Erklärung zur Norm. Die Norm umfasst (Stand Dezember 2007) sieben Teile. In der nachfolgenden Übersicht sind die jeweiligen Titel aufgeführt, in Klammern sind das Jahr der Erstveröffentlichung sowie der aktuellen Fassung zu finden:

1.2 Die Norm IEC 61131

-

15

DIN EN 61131-1 Ausgabe 2: Allgemeine Informationen (1994; 2004) [DIN EN 61131-1] DIN EN 61131-2 (VDE 0411 T 500): Betriebsmittelanforderungen und Prüfungen (1994; 2007) [DIN EN 61131-2] DIN EN 61131-3 Ed. 3: Programmiersprachen (1993; 2003); die nächste Überarbeitung erfolgt voraussichtlich 2010 [DIN EN 61131-3] IEC 61131-4 TR Ed 2.0: User guidelines (1995; 2004) [IEC 61131-4 TR] DIN EN 61131-5: Kommunikation (2001) [DIN EN 61131-5] DIN EN 61131-7: Fuzzy-Control-Programmierung (2000) [DIN EN 61131-7] DIN EN 61131-8 TR Ausgabe 2: Leitlinien für die Anwendung und Implementierung von Programmiersprachen für Speicherprogrammierbare Steuerungen (1997; 2005) [DIN EN 61131-8]. Dieses Papier wurde auch unter der Bezeichnung DIN EN 61131-3 Beiblatt 1 veröffentlicht.

Zusätzlich werden vereinzelt Corrigenda zu den Normen veröffentlicht, welche Fehlerbeschreibungen der aktuell gültigen Ausgabe beinhalten und einen Vorschlag zur Behebung vorwegnehmen. Teil 1: Allgemeine Informationen: Teil 1 enthält „allgemeine Begriffsbestimmungen und typische Funktionsmerkmale, die eine SPS von anderen Systemen unterscheiden. Hierzu zählen Standardeigenschaften wie beispielsweise die zyklische Bearbeitung des Anwenderprogramms mit dem gespeicherten Abbild der Eingangs- und Ausgangswerte oder die Arbeitsteilung zwischen Programmier-, Automatisierungs- und Bedienund Beobachtungsgerät.“ Teil 2: Betriebsmittelanforderungen und Prüfungen: Dieser Teil „definiert die elektrischen, mechanischen und funktionellen Anforderungen an die Geräte sowie entsprechende Typprüfungen. Es sind die Umgebungsbedingungen (Temperatur, Luftfeuchte usw.) und Beanspruchungsklassen der Steuerungen und Programmiergeräte vorgegeben.“. Teil 3: Programmiersprachen: Hier „wurden die weltweit verbreiteten SPS-Programmiersprachen in einer harmonisierten und zukunftsweisenden Überarbeitung aufgenommen.“ Über formale Definitionen, durch lexikalische, syntaktische und (teilweise) semantische Beschreibungen sowie Beispiele werden das grundlegende Softwaremodell und die Programmiersprachen festgelegt. Teil 4: Anwenderrichtlinien Der vierte Teil ist „als Leitfaden konzipiert, um den SPS-Anwender in allen Projektphasen der Automatisierung zu beraten. Die praxisgerechten Hinweise reichen von der Systemanalyse über die Gerätewahl bis zur Wartung.“ Teil 4 wurde in der Erstversion in Deutschland unter dem Titel „Beiblatt zu DIN EN 61131“ veröffentlicht.

16

1 Einleitung

Teil 5: Kommunikation: Dieser Teil „behandelt die Kommunikation von SPSen unterschiedlicher Hersteller miteinander und mit anderen Geräten.“ In Zusammenarbeit mit der ISO 9506 (Manufacturing Message Specification; MMS) erfolgt die Definition von Konformitätsklassen, die SPSen zur Kommunikation (z.B. über Netz) nutzen können. Dies umfasst die Funktionen Geräteanwahl, Datenaustausch, Alarmverarbeitung, Zugriffskontrolle und Netzwerkverwaltung. Teil 6: Sicherheitsgerichtete SPS: Aktuell arbeitet das Normungskomitee an der Ersterstellung der IEC 61131-6, „Sicherheitsgerichtete SPS“. Ziel ist die Aufbereitung der Anforderung der Sicherheitsnorm IEC 61508 („Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“) und der Maschinenanforderung IEC 62061 („Sicherheit von Maschinen - Funktionale Sicherheit sicherheitsbezogener elektrischer, elektronischer und programmierbar elektronischer Steuerungssysteme“) an SPSen.. Teil 7: Fuzzy Control Language: Das Ziel dieses Normteils ist es, dem Hersteller und dem Anwender ein gemeinsames Verständnis zur Integration von Fuzzy kontrollierten Anwendungen auf Basis der IEC 61131-3 zu geben. Ein weiteres Ziel ist die Portierungsmöglichkeit von Fuzzy Programmen zwischen unterschiedlichen Hersteller. Teil 8: Leitlinien für die Anwendung und Implementierung von Programmiersprachen für Speicherprogrammierbare Steuerungen: Dieses Dokument liefert Interpretationen zu offen gebliebenen Fragen der Norm. Es enthält Richtlinien zur Implementierung, Verwendungshinweise für den Endanwender sowie programmiertechnische Hilfestellungen. Die Norm beschreibt eine moderne Technologie und ist damit einem starken Innovationsdruck ausgesetzt, weshalb auch eine nationale und internationale Fortentwicklung der erreichten Ergebnisse erfolgt. Dieses Buch beschäftigt sich mit dem Teil 3 „Programmiersprachen“, kurz IEC 61131-3. Es beinhaltet die letzten Änderungen und Erweiterungen, welche 2003 mit der Ausgabe 2 eingearbeitet wurden. Zu Inhalt und Entstehung der Norm IEC 61131 siehe auch [Rolle-98].

1.3 Organisation PLCopen

17

1.3 Organisation PLCopen Die PLCopen [PLCopen Europe] ist eine hersteller- und produktunabhängige internationale Vereinigung. Ihr gehören viele SPS-Hersteller, Softwarehäuser und unabhängige Institute in Europa und Übersee an. Die Mitglieder aus den verschiedenen Branchen konzentrieren sich auf die Harmonisierung im Bereich der Steuerungsprogrammierung sowie auf die Anwendungsund Softwareschnittstellenentwicklung im Umfeld der IEC 61131-3. Zur Reduzierung der Kosten im industriellen Engineering wurden einheitliche Vorgaben und Ausführungsrichtlinien erstellt. Das Ergebnis dieser Arbeit sind zum Beispiel standardisierte Bibliotheken für verschiedene Anwendungsbereiche, die Ausarbeitung eines Konformitätslevels für Programmiersprachen und Schnittstellen für einen verbesserten Softwareaustausch. Die Experten der PLCopen- Mitglieder sind in technischen Komitees organisiert und definieren diese offenen Standards zusammen mit dem Endanwender.

1.3.1 Ziele von PLCopen PLCopen wurde 1992 direkt nach der Veröffentlichung der Norm IEC 61131-3 gegründet. Der Steuerungsmarkt war damals ein sehr heterogener Markt mit verschiedensten Programmiermethoden für viele unterschiedliche SPS-Typen. Heute ist die IEC 61131-3 ein weltweit akzeptierter Programmierstandard und viele Software- und Hardware-Hersteller bieten Produkte auf der Basis dieses Standards an, der sich auf diese Weise – dank PLCopen – in vielen verschiedenen Maschinen und anderen Anwendungsbereichen wieder findet. Heute sind die Herausforderungen auf dem Markt der industriellen Steuerungen ganz andere und die PLCopen folgt den Anforderungen des Marktes, wobei der Kernbereich eine effizientere Automatisierung durch die Definition allgemeiner Standards ist. Die aktuellen Themen sind: -

Motion Control- und Sicherheits-Funktionen, XML-Datenaustauschformat zur Standardisierung der Basisdaten von IECProjekten in Software-Systemen und Benchmarking- Projekte zur Ausarbeitung eines detaillierten BenchmarkStandards .

Weitere, neue Automatisierungsaufgaben werden auch in Zukunft durch neue industrielle Anforderungen und neue Produkte entstehen und es wird die Aufgabe der PLCopen bleiben, eine globale Harmonisierung herbeizuführen und ein einheitliches Verständnis zu schaffen. Es handelt sich bei der PLCopen somit um kein weiteres Normungsgremium, sondern um eine Interessengemeinschaft, die existierende Standards zur inter-

18

1 Einleitung

nationalen Akzeptanz verhelfen möchte. Detaillierte Information ist über das Internet abrufbar (http://www.PLCopen.org).

1.3.2 Gremien und Arbeitsgebiete Die PLCopen ist in mehrere Komitees aufgeteilt, die jeweils ein Arbeitsgebiet behandeln:

Mitglieder- Versammlung

Vorstand

Geschäftsführer

Technische Komitees

Promotion Komitees

TC 1 Standards

TC 2 Funktionen

PC 1 Allgemeine Promotion

PC 2 Trainings- Programme

TC 3 Zertifizierung

TC 4 Kommunikation

PC 3 Promotion Nord- Amerika

PC 4 Promotion Japan

TC 5 Sichere SPS

TC 6 XML

PC 5 Promotion China

Abb. 1.1. Komitees der PLCopen

Die technischen Komitees erarbeiten Richtlinien und Vorgaben zum gemeinsamen Vorgehen; die Promotion- Gremien sind für Marketingmaßnahmen verantwortlich. Die Arbeit in den Komitees wird ausschließlich von Vertretern einzelner Firmen und Institute vorgenommen; dies garantiert, dass die erarbeiteten Papiere in den Unternehmen umgesetzt werden können. 1.3.3 Ergebnisse Durch vorbereitende Maßnahmen der Promotion Komitees konnten mehrere Messen in Europa, USA und Fernost beschickt werden. Workshops und Fortbildungsseminare brachten der PLCopen die erwünschte internationale Anerkennung. Als Diskussionsforum von Anwendern, Hersteller und Software-Häusern konnten respektable technische Ergebnisse erzielt werden: -

Zertifizierung für Hersteller von SPS-Programmiersystemen, Austauschformat für Anwenderprogramme.

Die Komitees im Einzelnen:

1.3 Organisation PLCopen

19

TC 1 – Standards. Dieses Komitee ist die Schnittstelle zu den internationalen Normengremien der IEC und OPC [OPC Foundation]. Mitglieder des Komitees sammeln Vorschläge zur Verbesserung oder Fehlerkorrektur für das verantwortliche IEC 61131 Normungsgremium IEC 65B WG7 working group [IEC IEC 65B WG7] ; sie entwickeln gemeinsame Positionen unter ihren Mitgliedern, die sie wiederum den Normengremien vorschlagen und Neues aus den Gremien publizieren. Insbesondere wurden hier Verbesserungen für die 2. Ausgabe der Norm eingebracht. TC 2 – Functions. Seine Mitglieder definieren Bibliotheken von Funktionsblöcken. Als Marktstandard hat sich beispielsweise die PLCopen Motion Bibliothek durchgesetzt. Dieses Dokument untergliedert sich in folgende Teile: -

Part 1: Basisdokumentation, Part 2: Erweiterungen, zusätzliche Funktionsblöcke, Part 3: Anwender- Richtlinien (Richtlinien und Beispiele für den Anwender, Part 4: Interpolation, fokussiert auf koordinierte Multiachsen Bewegungen im 3D- Raum, Part 5: Homing (diese Funktion dient der Referenzierung einer speziellen mechanischen Position).

TC 3 – Certification. Um die IEC 61131-3 Konformität von Programmiersystemen zu prüfen, wurden mehrere Zertifizierungsstufen definiert und Testsoftware erstellt. Die Prüfung erfolgt über PLCopen akkreditierte Institute, um die angestrebte Qualität des Nachweises zu garantieren. Folgende Stufen sind definiert: -

-

-

Base Level (BL): Ursprüngliche Basisdefinition. Sie schreibt den wesentlichen Aufbau eines Programms nach IEC 61131-3 Methodik vor sowie die Erklärung des Programmierherstellers, sich an der Norm zu orientieren. Reusability Level (RL): Funktionen und Funktionsbausteine sind soweit kompatibel, dass sie auf unterschiedliche Programmiersysteme mit diesem Level portiert werden können. Conformity Level (CL): die strengste Konformitätsprüfung. Durch die Vielzahl von Datentypen in IEC 61131-3 (26) nutzen die Programmiersysteme oft nur einen Teil. Beim Konformitätstest werden nun alle Datentypen, welche der Hersteller für sein System angibt, einer strengen Kontrolle unterworfen.

Die Benchmark Workgroup ist ebenfalls dem TC 3 zugeordnet. Sie definiert Spezifikationen und Tests für Skripts, welche eine reproduzierbare und portierbare Leistungsmessung von Programmiersystemen erlauben.

20

1 Einleitung

TC 4 – Communication. TC 4 bearbeitet Definitionen an der Schnittstelle zwischen IEC 61131-3 Programmiersystemen und Kommunikationssystemen wie Profibus oder CAN. TC 5 – Safe Software. Dieses Komitee stellt Empfehlungen auf, um IEC 61131-3 Systeme in sicherheitskritischen Umgebungen einsetzen zu können. Dies schließt insbesondere die neuen Normen IEC 61508 und IEC 61511 mit ein. Weiterhin werden Richtlinien für Anwender erstellt, um Sicherheitsaspekte in sicherheitskritischen Anwendungen zu gewährleisten. TC 6 – XML. TC 6 definiert ein XML Schema, um IEC 61131-3 Anwenderprogramme und -projekte in XML zu beschreiben. Dies schließt die textuellen wie grafischen Sprachen, Variablendeklaration und Konfiguration ein. Diese Spezifikation unterstützt -

den Austausch von Bausteinen zwischen Systemen die Schnittstelle zu anderen Softwarepaketen wie Dokumentations-, Simulations- oder Verifikationswerkzeuge.

PC 1 – General Promotion. Das Komitee ist zuständig für Europa sowie Gebiete, die keine eigene Promotionsabteilung besitzen (vorhanden für Nord- Amerika, China und Japan) [PLCopen Europe]. PC 2 – Common Training. PC 2 erstellte Unterlagen für IEC 61131-3 Trainings, welche von akkreditierten Trainingunternehmen durchgeführt werden können [PLCopen Europe]. PC 3 – Promotion North America. Die Gruppe ist für Promotion- Aktivitäten in Nordamerika verantwortlich [PLCopen North America]. PC 4 – Promotion Japan. PC 4 ist für Promotion- Aktivitäten in Japan zuständig und arbeitet eng mit der dortigen lokalen PLCopen Niederlassung zusammen [PLCopen Japan]. PC 4 – Promotion China. PC 5 ist für Promotion- Aktivitäten in China zuständig und arbeitet eng mit der dortigen lokalen PLCopen Niederlassung zusammen [PLCopen China].

2 Bausteine der IEC 61131-3

In diesem Kapitel werden die wesentlichen Sprachelemente der Norm IEC 61131-3 in ihrer Bedeutung und Verwendung erläutert. Dabei werden aufeinander aufbauende praxisorientierte Beispiele verwendet. Der Leser wird in die Begriffe und Denkweise der IEC 61131-3 eingeführt. Unter Verzicht auf die formale Sprachdefinition der Norm [DIN EN IEC 61131-3] werden die grundlegenden Zusammenhänge und Konzepte ausführlich erläutert. Im ersten Abschnitt dieses Kapitels erfolgt der „kompakte“ Einstieg in die Begriffswelt mit Hilfe eines Beispiels, das die wichtigsten Sprachelemente der Norm beinhaltet und gleichzeitig einen Überblick über die Methodik der SPSProgrammierung nach IEC 61131-3 bietet. Dabei bildet der Begriff „POE“ (Programm-Organisationseinheit) einen wichtigen roten Faden zum Verständnis der neuen Sprachkonzepte. Für die Formulierung von Beispielen wird in diesem Kapitel die Programmiersprache Anweisungsliste (AWL) gewählt, da diese Notation den meisten SPSProgrammierern vertraut ist. Sie besitzt im europäischen SPS-Markt die größte Verbreitung und erschließt sich dem Leser schnell durch ihre einfache Syntax. Die Programmiersprache AWL selbst wird in Abschn. 4.1 erläutert.

2.1 Einstieg in die neue Norm Die IEC 61131-3 umfasst nicht nur die SPS-Programmiersprachen selbst, sondern bietet umfassende Konzepte und Richtlinien zum Aufbau eines SPS-Projekts. Ziel dieses Abschnitts ist es, einen raschen Überblick über wesentliche Begriffe zu geben, ohne dabei auf Einzelheiten einzugehen. Ein gemeinsames Beispiel ergänzt die Erklärungen. Detaillierte Informationen sind den sich anschließenden Abschnitten und Kapiteln zu entnehmen.

22

2 Bausteine der IEC 61131-3

2.1.1 Aufbau von Bausteinen POEs entsprechen den Bausteinen bei bisherigen Programmiersystemen. POEs können sich gegenseitig mit oder ohne Parameter aufrufen. Eine POE bildet die kleinste unabhängige Software-Einheit des Anwenderprogramms, wie es ihr Name bereits ausdrückt. Es gibt drei Arten von POEs: Funktion (FUN), Funktionsbaustein (FB) und Programm (PROG), in dieser Reihenfolge mit zunehmender Funktionalität versehen. FUNs unterscheiden sich von FBs vor allem dadurch, dass sie bei gleichen Eingangswerten immer dasselbe Ergebnis (als Funktionswert bzw. Ausgangswerte) zurückliefern, d.h. kein „Gedächtnis“, sprich keine Zustandsinformationen besitzen dürfen. Dagegen arbeiten FBs jeweils auf einem eigenen Datensatz, können sich also Zustandsinformationen „merken“ (Instanzbildung). Programme (PROG) bilden den „Kopf“ eines SPS-Anwenderprogramms und besitzen die Möglichkeit, auf SPS-Peripherie zuzugreifen bzw. diese den übrigen POEs zur Verfügung zu stellen. In der IEC 61131-3 sind die Aufrufschnittstellen und das Verhalten häufig benötigter Standard-Funktionen (Std.-FUN) wie für Arithmetik oder Vergleiche sowie Standard-Funktionsbausteine (Std.-FB) wie Zeiten oder Zähler fest vordefiniert. Deklarationen von Variablen. Die IEC 61131-3 benutzt Variablen, um Informationen zu speichern und zu verarbeiten. Variablen entsprechen den bisher in SPS-Systemen verwendeten Merkern. Allerdings muss ihr Speicherort nicht mehr vom Anwender manuell vergeben werden (Vergabe absoluter Adressen), sondern sie werden vom Programmiersystem automatisch verwaltet und besitzen einen fest zugeordneten Datentyp. Die IEC 61131-3 gibt mehrere Datentypen vor (Bool, Byte, Integer, ...), die sich beispielsweise durch die Anzahl der Bits und Vorzeichenbehandlung unterscheiden. Es können vom Anwender auch eigene Datentypen definiert werden (Strukturen, Felder). Variablen können auf eine physikalische Adresse abgebildet werden und eine Batteriepufferung (für Stromausfall) erhalten. Variablen besitzen unterschiedliche Ausprägungen. Sie können außerhalb einer POE definiert (deklariert) und programmweit benutzt werden, als Aufrufparameter in die POE eingebracht werden oder lokal für die POE von Bedeutung sein. Dazu werden sie zur Deklaration in Variablenarten eingeteilt. Sämtliche in einer POE benutzten Variablen sind im Deklarationsteil der POE bekanntzugeben. Der Deklarationsteil einer POE kann unabhängig von der verwendeten Programmiersprache einheitlich in textueller Form erstellt werden. Teile davon (Einund Ausgangsparameter der POE) sind auch grafisch darstellbar.

2.1 Einstieg in die neue Norm VAR_INPUT GueltigFlag : BOOL; END_VAR VAR_OUTPUT Drehzahl : REAL; END_VAR VAR RETAIN MotorNr : INT; MotorName : STRING [10]; NotAus AT %IX2.0 : BOOL; END_VAR

23

(* Eingangsvariable *) (* binärer Wert *) (* Ausgangsvariable *) (* Gleitpunktwert *) (* lokale Variable, batteriegepuffert *) (* Ganzzahl mit Vorzeichen *) (* Zeichenfolge für Text *) (* Eingangsbit 2.0 der Peripherie *)

Bsp. 2.1. Beispiel für typische Variablendeklarationen einer POE

Bsp. 2.1 zeigt, dass in der dazugehörigen POE ein Integerwert (16 Bit inkl. Vorzeichen) mit Namen MotorNr verwendet wird und ein 10 Zeichen langer Text MotorName zur Verfügung steht. Die Variable NotAus wird an den physikalischen SPS-Signaleingang 2.0 gelegt (AT). Diese drei Variablen sind nur in dieser POE bekannt (lokal) und können dort manipuliert werden, nach einem Stromausfall bleiben ihre Werte erhalten (RETAIN). Der Wert der Eingangsvariablen GueltigFlag wird von der aufrufenden POE zur Verfügung gestellt und besitzt die booleschen Werte FALSE oder TRUE. Die POE liefert als Ausgangsparameter den Gleitpunktwert von Drehzahl zurück. Die booleschen Werte TRUE und FALSE können auch gleichwertig mit „1“ und „0“ bezeichnet werden. Anweisungsteil einer POE. Der Anweisungsteil folgt dem Deklarationsteil und beschreibt die Befehle, welche die SPS ausführen soll. Eine POE wird in einer der textuellen Programmiersprachen Anweisungsliste (AWL) oder Strukturierter Text (ST) bzw. in den grafischen Darstellungen Kontaktplan (KOP) oder Funktionsbausteinsprache (FBS) programmiert. Während in AWL maschinennah programmiert werden kann, bietet die IEC 61131-3 mit ST eine höhere Programmiersprache. KOP ist für boolesche (binäre) Verknüpfungsschaltungen geeignet. Mit FBS können sowohl boolesche (binäre) als auch arithmetische Verknüpfungen in grafischer Darstellung programmiert werden.

24

2 Bausteine der IEC 61131-3

%IX23.5 NotAus Motor S Taste N

FlipFlop SR %IW3 %MW3

Kontaktplan

LD ORN ANDN S

%IX23.5 Taste NotAus Motor

Anweisungsliste

>=

S1 VarEin

Q1

VarAus

R

Funktionsbausteinsprache

FlipFlop ( S1 := (%IW3 >= %MW3), R := VarEin ); VarAus := FlipFlop.Q1; Strukturierter Text

Abb. 2.1. Einfache Beispiele zu den Programmiersprachen KOP, FBS, AWL und ST. Die Darstellungen in KOP und AWL sowie in FBS und ST sind jeweils zueinander äquivalent.

Zusätzlich kann die Ablaufsprache (AS) verwendet werden, um die Struktur (den Aufbau) eines SPS-Programms zu beschreiben, indem die sequentiellen und parallelen Abläufe dargestellt werden. Die darin enthaltenen AS-Teilabschnitte (Schritte und Transitionen) können voneinander unabhängig in einer der IEC 61131-3-Sprachen formuliert werden.

2.1 Einstieg in die neue Norm

25

S0

t1 S1 &

t3 S2

t2

t4

S3 t5

Ablaufsprache (AS)

Abb. 2.2. Schematisches Beispiel zur Darstellungsart AS. Die Ausführungsteile zu den Schritten (S0 bis S3) und Transitionsbedingungen (t1 bis t5) werden in der gewünschten Programmiersprache erstellt.

Abb. 2.2 zeigt ein AS-Beispiel: Die Schritte S0, S1 und S3 werden sequentiell ausgeführt, alternativ zu S1 kann S2 zur Ausführung kommen. Die Transitionen t1 bis t5 stellen die Freischaltebedingungen dar, um von einem Schritt zum nächsten zu gelangen.

2.1.2 Einführungsbeispiel in AWL Im Folgenden wird das Beispiel eines IEC 61131-3-Programms vorgestellt, für das in Abb. 2.3 zunächst seine POE-Aufrufhierarchie charakterisiert wird. Dieses Beispiel ist nicht als ausführbares Programm ausformuliert, sondern dient lediglich zum Aufzeigen der POE-Struktur.

26

2 Bausteine der IEC 61131-3

MotorRegel Programm

MotAnlauf

MotBeschl

Funktionsbaustein

Funktion

LOG Standard-Funkti on

MotBrems Funktionsbaustein

Abb. 2.3. Aufrufhierarchie von POEs an einem Beispiel

Die AWL-äquivalente Darstellung ist in Bsp. 2.2 zu sehen.

PROGRAM MotorRegel VAR_INPUT (* Eingangs variable *) MaxDrehzahl : INT; END_VAR VAR (* lokale Variable *) HochLauf : MotAnlauf; Abbremsen : MotBrems; END_VAR ... (* FB-Aufruf *) CAL HochLauf (DZ := MaxDrehzahl) LD HochLauf.laeuft ... CAL Abbremsen (* FB-Aufruf *) ... END_PROGRAM

POE-Typ mit Namen

Deklarationsteil

Anweisungsteil

POE-Ende

Bsp. 2.2. Deklaration des Programms MotorRegel der Abb. 2.3, sowie zugehörige Anweisungsteile in AWL. Kommentare werden in Klammern dargestellt „(* ... *)“.

2.1 Einstieg in die neue Norm

FUNCTION_BLOCK MotAnlauf VAR_INPUT DZ: REAL; END_VAR VAR_OUTPUT laeuft: BOOL; END_VAR ... LD DZ MotBeschl 100.0 ... END_FUNCTION_BLOCK

(* Funktionsbaustein *) (* Variablendeklaration *) (* Variablendeklaration *)

FUNCTION_BLOCK MotBrems ... END_FUNCTION_BLOCK

(* Funktionsbaustein *)

FUNCTION MotBeschl : REAL VAR_INPUT Param1, Param2: REAL; END_VAR LD Param2 LOG ... END_FUNCTION

(* Funktion *) (* Variablendeklaration *)

27

(* FUN-Aufruf *)

(* Aufruf Std.-FUN Log. *)

Bsp. 2.3. Die drei Unterprogramme der Abb. 2.3 in AWL. LOG (Logarithmus) ist eine vordefinierte Standard-Funktion der IEC 61131-3.

MotorRegel ist das Hauptprogramm. Beim Start dieses Programms ist die Variable MaxDrehzahl, wie später zu sehen ist, mit einem Wert belegt, der beim Aufruf mitgegeben wird. Diese POE ruft den Baustein HochLauf, beschrieben durch MotAnlauf, auf, der seinerseits die REAL-Funktion MotBeschl mit zwei Eingangsparametern (Drehzahl DZ und 100.0) aufruft. Diese ruft LOG auf – die IEC 61131-Standard-Funktion „Logarithmus“. Wurde HochLauf (MotAnlauf) durchlaufen, wird MotorRegel wieder aktiv, wertet das FB-Ergebnis laeuft aus und ruft nun Abbremsen, beschrieben durch MotBrems, auf. Wie in Bsp 2.2 zu sehen ist, werden die FBs MotAnlauf und MotBrems nicht

unmittelbar mit diesen Namen aufgerufen, sondern über die sogenannten „InstanzNamen“ HochLauf bzw. Abbremsen.

28

2 Bausteine der IEC 61131-3

2.1.3 SPS-Zuordnung Eine SPS kann aus mehreren Verarbeitungseinheiten wie CPUs oder Spezialprozessoren bestehen, die in der IEC 61131-3 Ressourcen genannt werden. Auf einer Ressource können mehrere Programme ablaufen, die sich durch Wichtigkeit (Priorität) oder Ausführungstyp (periodisch, zyklisch, Interrupt) unterscheiden. Jedem Programm wird eine Task zugeordnet, wodurch sich ein Laufzeitprogramm ergibt. Programme dürfen auch mehrfach zugeordnet werden (Instanziierung). Um das in Bsp. 2.2 und 2.3 beschriebene Programm in eine SPS zu laden, sind weitere Informationen nötig, damit die zugewiesene Task die gewünschten Eigenschaften besitzt: -

Auf welchem SPS-Typ, bzw. welcher Ressource soll das Programm ablaufen? Wie erfolgt die Programm-Ausführung und mit welcher Priorität? Müssen Variable auf physikalische SPS-Adressen gelegt werden? Müssen Bezüge zu anderen Programmen über globale oder externe Variablen hergestellt werden?

Diese Informationen werden als Konfiguration (CONFIGURATION) abgelegt, wie textuell in Bsp. 2.4 und grafisch mit Abb. 2.4 gezeigt wird.

CONFIGURATION MotorSteu VAR_GLOBAL Trigger AT %IX2.3 : BOOL; END_VAR RESOURCE Res_1 ON CPU001 TASK T_1 (INTERVAL := t#80ms, PRIORITY := 4); PROGRAM MotR WITH T_1 : MotorRegel (MaxDrehzahl := 12000); END_RESOURCE RESOURCE Res_2 ON CPU002 TASK T_2 (SINGLE := Trigger, PRIORITY := 1); PROGRAM MotP WITH T_2 : MotorProg (...); END_RESOURCE END_CONFIGURATION

Bsp. 2.4. Zuordnung der Programme aus Bsp. 2.3 zu Tasks und Ressourcen innerhalb einer Konfiguration

2.1 Einstieg in die neue Norm

Res_1

Res_2

CPU001

Task:

29

CPU002

zyklisch Interrupt hochprior niederprior

Task:

zyklisch Interrupt hochprior niederprior

Programm MotorRegel

Programm MotorProg

MotAnlauf

MotBrems

...

MotBeschl

LOG

Zuordnung Hardware-Adressen Global/Access-Variablen ...

CONFIGURATION MotorSteu

Abb. 2.4. Verknüpfung der Programme einer Motorsteuerung MotorSteu mit Tasks in der SPS-„Konfiguration“. Die so erhaltenen Laufzeitprogramme werden durch die Ressourcen (Prozessoren) des SPS-Systems ausgeführt.

Abb. 2.4 führt Bsp. 2.3 fort. Das Programm MotorRegel läuft zusammen mit seinen FUNs und FBs auf der Ressource CPU001. Dabei wird mit der Task angegeben, dass MotorRegel mit niedriger Priorität zyklisch ablaufen soll. Das Programm MotorProg läuft hier auf der CPU002 ab, könnte aber durchaus auch auf CPU001 ausgeführt werden, wenn diese CPU Multitasking unterstützt. Weiterhin werden in der Konfiguration Variablen der SPS-Peripherie zugewiesen sowie globale und Kommunikations-Variablen verwaltet. Dies ist ebenfalls innerhalb eines PROGRAM möglich. SPS-Projekte bestehen aus POEs, die vom SPS-Hersteller mitgeliefert oder vom Anwender selbst programmiert werden. Aus Anwenderprogrammen können Bibliotheken gebildet werden, deren ausgetestete POEs in neue Projekte einfließen. Die IEC 61131-3 unterstützt diesen Aspekt der Wiederverwendbarkeit, indem Funktionen und Funktionsbausteine – soweit wie möglich – allgemeingültig, d.h. hardwareunabhängig bleiben. Nach diesem kurzen Überblick werden in den weiteren Abschnitten die Eigenschaften und Besonderheiten von POEs ausführlich erläutert.

30

2 Bausteine der IEC 61131-3

2.2 Die Programmorganisationseinheit (POE) Als Programm-Organisationseinheiten (POE) bezeichnet die IEC 61131-3 die Bausteine, aus denen ein Projekt aufgebaut wird. POEs entsprechen den üblichen Programm-, Organisations-, Schritt- und Funktionsbausteinen der bisherigen SPSProgrammierwelt. Ein wesentliches Ziel bei der Normierung war es, die Vielfalt und oft implizite Bedeutung von Bausteinarten zu beschränken und in ihrem Wesen zu vereinfachen.

OB Organisationsbaustein

SB

PB Programmbaustein

PROGRAM Hauptprogramm

Schrittbaustein

FB DB Datenbaustein

Funktionsbaustein

Bisherige Bausteintypen DIN 19239

FUNCTION BLOCK Funktionsbaustein

FUNCTION Funktion

POEs der IEC 1131-3

Abb. 2.5. Übergang von bisherigen Bausteintypen zu POEs der IEC 61131-3

Wie Abb. 2.5 zeigt, reduziert die IEC 61131-3 die diversen Bausteintypen einzelner SPS-Hersteller auf drei einheitliche Grundtypen. Datenbausteine werden durch FB-Datenbereiche („Instanzen“, siehe unten) oder globale MultielementVariable (vgl. Kap. 3) abgelöst. Folgende drei POE-Typen bzw. „Bausteinarten“ gibt es in der neuen Norm:

2.2 Die Programmorganisationseinheit (POE)

POE-Typ Programm

Schlüsselwort PROGRAM

Funktionsbaustein

FUNCTION_BLOCK

Funktion

FUNCTION

31

Bedeutung Hauptprogramm mit Zuordnung der SPS-Peripherie, globalen Variablen und Zugriffspfaden Baustein mit Ein- und Ausgangsparameter; ist der zur Programmierung hauptsächlich benutzte POE-Typ Baustein mit Funktionswert, Ein- und Ausgangsparameter zur Erweiterung des SPSOperationsvorrats

Tab. 2.1. Die drei POE-Typen der IEC 61131-3 mit ihrer Bedeutung

Diese drei POE-Typen unterscheiden sich durch besondere Eigenschaften in ihrer Verwendung: -

-

-

Funktion (FUN). Parametrierbare POE ohne statische Variablen bzw. Zustandsinformationen (ohne „Gedächtnis“), die bei denselben Eingangsparametern stets dasselbe Ergebnis als Funktionswert und/oder Ausgangsparameter liefert. Funktionsbaustein (FB). Parametrierbare POE mit statischen Variablen (mit Gedächtnis). Ein FB (z.B. Zeit- oder Zählerbaustein) liefert bei gleichen Eingangswerten Ergebnisse, die auch vom Zustand seiner internen (VAR) und externen (VAR_EXTERNAL) Variablen abhängen können, die zwischen FBAufrufen erhalten bleiben. Programm (PROG). Dieser POE-Typ stellt das „Hauptprogramm“ dar. Alle Variablen des Gesamtprogramms, denen physikalische Adressen (z.B. Ein- und Ausgänge der SPS) zugewiesen sind, müssen in dieser POE oder oberhalb (Ressource bzw. Konfiguration) deklariert werden. Sonst wie FB.

PROG und FB können Ein- und Ausgangsparameter besitzen, Funktionen haben Eingangs- sowie Ausgangsparameter und ihren Funktionswert als Rückgabewerte. Daher entspricht FUNCTION_BLOCK der IEC 61131-3 mit Eingangs- und Ausgangsparametern in etwa einem bisher üblichen Funktionsbaustein. Die POETypen PROGRAM und FUNCTION besitzen aufgrund ihrer gegenüber FBs erweiterten bzw. eingeschränkten Eigenschaften keine direkten Pendants zu Bausteinen nach DIN 19239. Eine POE ist eine für sich abgeschlossene Einheit, die vom Compiler unabhängig von anderen Programmteilen übersetzt werden kann. Der Compiler benötigt allerdings Informationen über die Aufrufschnittstellen derjenigen POEs, die in diesem Baustein aufgerufen werden (Prototypen). Übersetzte POEs können später gemeinsam zusammengebunden werden („Link“-Vorgang), um ein Gesamtprogramm zu bilden.

32

2 Bausteine der IEC 61131-3

Der Name einer POE ist projektweit bekannt und darf daher nicht mehrfach vergeben werden. Lokale Unterprogramme wie in manchen anderen (Hoch-) Sprachen kennt die IEC 61131-3 nicht. Damit steht nach der Programmierung einer POE, der sogenannten Deklaration, ihr Name und ihre Aufrufschnittstelle sämtlichen anderen POEs des Projekts global zur Verfügung. Diese Selbständigkeit der POEs ermöglicht eine weitreichende Modularisierung der Automatisierungsaufgabe sowie die Wiederverwendbarkeit von bereits fertig implementierten und getesteten Software-Teilen. In den nächsten Abschnitten werden zunächst Gemeinsamkeiten der POE-Typen erläutert. Anschließend werden die POE-Typen charakterisiert, Aufrufbeziehungen beschrieben und schließlich zusammenfassend miteinander verglichen.

2.3 Elemente einer POE Eine POE besteht aus den in Abb. 2.6 gezeigten Teilen: -

Angabe des POE-Typs mit POE-Namen (und Datentyp bei Funktionen), Deklarationsteil mit Variablendeklarationen, POE-Rumpf mit Anweisungen.

PROGRAM PROG-Name FUNCTION_BLOCK FB-Name

FUNCTION FUN-Name Datentyp

Schnittstellen-Variablen

END_PROGRAM

lokale Variablen

Deklarationsteil

Anweisungen (POE-Rumpf)

Anweisungsteil

END_FUNCTION_BLOCK

END_FUNCTION

Abb. 2.6. Der gemeinsame Aufbau der drei POE-Typen Programm (links), Funktionsbaustein (Mitte) und Funktion (rechts). Der Deklarationsteil enthält Schnittstellen- und lokale Variablen.

Die Deklarationen dienen zur Festlegung sämtlicher von der POE verwendeten Variablen. Dabei wird zwischen nach außen sichtbaren Variablen (POE-Schnitt-

2.3 Elemente einer POE

33

stelle) und den lokalen Variablen der POE unterschieden. Diese Möglichkeiten werden im nächsten Abschnitt sowie detaillierter in Kap. 3 erklärt. Im Anweisungsteil (Rumpf) einer POE wird die Verknüpfungs- oder Berechnungsvorschrift in der gewünschten Programmiersprache programmiert. Sprachen der IEC 61131-3 werden im Kap. 4 vorgestellt und erläutert. Deklarationen und Anweisungen können graphisch oder textuell programmiert werden.

2.3.1 Beispiel

In Bsp. 2.5 werden die Elemente einer POE veranschaulicht.

FUNCTION_BLOCK FB-Name

FUNCTION_BLOCK

WeiterSchalt

Schnittstellen-Variablen

VAR_INPUT VarEin : BOOL; END_VAR (* Eingang *) (* Ausgänge *) VAR_OUTPUTVarAus1 : BYTE;

lokale Variablen

VAR

Anweisungen (POE-Rumpf)

VarAus2 : BOOL; END_VAR VarLokal : BYTE; END_VAR (* Zustandswert *)

LD VarEin ... LD VarLokal ST VarAus1 ... ST VarAus2

END_FUNCTION_BLOCK

END_FUNCTION_BLOCK

Bsp. 2.5. Elemente einer POE (links) und Beispiel für einen FB in AWL (rechts). Der FB enthält einen Eingangsparameter VarEin sowie zwei Rückgabewerte VarAus1 und VarAus2. VarLokal ist eine lokale Variable.

Der in der Programmiersprache AWL geschriebene Funktionsbaustein WeiterSchalt enthält den Eingangsparameter VarEin sowie die beiden Rückgabewerte VarAus1 und VarAus2 und die lokale Variable VarLokal. Im FB-Rumpf wird die Verwendung der AWL-Operatoren LD (Laden) und ST (Speichern) angedeutet.

34

2 Bausteine der IEC 61131-3

FUNCTION_BLOCK WeiterSchalt

BOOL

VarEin

VarAus1

BYTE

VarAus2

BOOL

END_FUNCTION_BLOCK

Bsp. 2.6. Grafische Darstellung der Aufrufschnittstelle des FB WeiterSchalt in Bsp. 2.5.

In der grafischen Darstellung der Aufrufschnittstelle sind lokale FB-Variablen wie VarLokal nicht sichtbar.

2.3.2 Deklarationsteil Die IEC 61131-3 benutzt Variablen, um Anwender-Daten zu initialisieren, weiterzuverarbeiten und zwischenzuspeichern. Diese Variablen werden zu Beginn jeder POE deklariert, d.h. ihre Zuordnung zu einem bestimmten Datentyp (wie BYTE oder REAL) bekanntgegeben. Bei dieser Deklaration können Variablen-Eigenschaften wie Batteriepufferung, Anfangswerte oder Zuordnungen zu physikalischen Adressen festgelegt werden. Die Deklaration der POE-Variablen erfolgt blockweise für Variablenarten, die jeweils deren Verwendungszweck bestimmen, wie Bsp. 2.7 zeigt. Jeder solcher Deklarationsblock (VAR_*...END_VAR) betrifft eine Variablenart und kann eine oder mehrere Variablen enthalten. Reihenfolge der Blöcke und Häufigkeit von Blöcken derselben Variablenart sind wie in Bsp. 2.8 beliebig bzw. implementierungsabhängig (für das jeweilige Programmiersystem).

(* Lokale Variable *)

VAR

VarLokal : BOOL; END_VAR

(* lokale boolesche Var. *)

(* Aufrufschnittstelle: Eingangsparameter *)

VAR_INPUT VAR_IN_OUT

VarEin : REAL; END_VAR VarEinAus : UINT; END_VAR

(* Eingangsvariable *) (* Ein- und Ausgangsvariable *)

(* Rückgabewerte: Ausgangsparameter *)

VAR_OUTPUT

VarAus : INT;

END_VAR

(* Ausgangsvariable *)

(* Globale Schnittstelle: Globale/Externe Variablen und Zugriffspfade *)

VAR_EXTERNAL VarGlob : WORD; END_VAR VAR_GLOBAL VarGlob : WORD; END_VAR VAR_ACCESS VarPfad : WORD; END_VAR

(* extern von anderer POE *) (* global für andere POEs *) (* Zugriffspfade der Konfiguration *)

Bsp. 2.7. Beispiele für Deklarationen der verschiedenen Variablenarten.

2.3 Elemente einer POE

35

(* Deklarationsblock 1 *)

VAR

VarLokal1, VarLokal2, VarLokal3: BOOL; END_VAR

(* Deklarationsblock 2 *)

VAR_INPUT

VarEin1 : REAL;

END_VAR

(* Deklarationsblock 3 *)

VAR_OUTPUT VarAus : INT;

END_VAR

(* Deklarationsblock 4 *)

VAR

VarLokal4, VarLokal5 : BOOL;

END_VAR

(* Deklarationsblock 5 *)

VAR_INPUT

VarEin2, VarEin3 : REAL;

END_VAR

(* Deklarationsblock 6 *)

VAR_INPUT

VarEin4 : REAL;

END_VAR

Bsp. 2.8. Beispiele für Deklarationsblöcke: Reihenfolge und Häufigkeit der Blöcke werden durch die IEC 61131-3 nicht festgelegt.

Variablenarten in POE-Typen. Je nach POE-Typ sind unterschiedliche Variablenarten zulässig, wie Tab. 2.2 zeigt:

Variablenart VAR VAR_INPUT VAR_OUTPUT VAR_IN_OUT VAR_EXTERNAL VAR_GLOBAL VAR_ACCESS VAR_TEMP

PROGRAM ja ja ja ja ja ja ja ja

erlaubt in: FUNCTION_BLOCK ja ja ja ja ja Nein Nein ja

FUNCTION ja ja ja ja nein nein nein nein

Tab. 2.2. Verwendung von Variablenarten innerhalb der drei POE-Typen

Wie Tab. 2.2 zeigt, können in Programmen sämtliche Variablenarten verwendet werden. Funktionsbausteine können keine globalen Variablen anderen POEs zur Verfügung stellen, dies ist nur in Programmen, Ressourcen und Konfigurationen erlaubt. FBs greifen auf solche globale Daten über die Variablenart VAR_EXTERNAL zu. Funktionen sind am stärksten eingeschränkt, da für sie nur lokale, Eingangs- und Ausgangsparameter zulässig sind. Sie geben ihr Berechnungsergebnis vor allem im Funktionswert zurück. Bis auf die lokalen Variablen können mit jeder Variablenart Daten in die POE eingebracht bzw. nach außen geliefert werden, dienen also dem Datenaustausch

36

2 Bausteine der IEC 61131-3

zwischen POEs. Die Merkmale dieser POE-Schnittstelle werden im Folgenden betrachtet. Merkmale der POE-Schnittstelle. Durch die Zuordnung von POE-Variablen zu Variablenarten (in Deklarationsblöcken) werden die Schnittstellen der POE sowie ihr lokaler Datenbereich festgelegt. Die POE-Schnittstelle gliedert sich in: -

Aufrufschnittstelle: Formalparameter (Ein- und Ein-/Ausgangsparameter), Rückgabewerte: Ausgangsparameter oder Funktionswert, Globale Schnittstelle mit globalen/externen Variablen und Zugriffspfaden.

Aufrufschnittstelle und die Rückgabewerte (bzw. Funktionswert) einer POE sind in den Sprachen KOP und FBS auch grafisch darstellbar. Die Variablen der Aufrufschnittstelle werden auch als Formalparameter bezeichnet. Beim Aufruf der POE werden die Formalparameter mit Aktualparametern versorgt, d.h. mit aktuellen (Variablen-) Werten oder Konstanten belegt. In Bsp. 2.3 besitzt der FB MotAnlauf den einzigen Formalparameter DZ, der in Bsp. 2.2 mit dem Wert des Aktualparameters MaxDrehzahl versorgt wird, sowie den Ausgangsparameter laeuft. Die Funktion MotBeschl mit zwei Formalparametern (einer davon mit dem Wert 100.0 versorgt) liefert ihr Berechnungsergebnis im Funktionswert zurück. Diese Vorstellung fasst Tab. 2.3 zusammen.

Aufrufschnittstelle

Variablenart VAR_INPUT, VAR_IN_OUT

(Formalparameter)

Rückgabewerte

VAR_OUTPUT

Globale Schnittstelle

VAR_GLOBAL, VAR_EXTERNAL, VAR_ACCESS VAR, VAR_TEMP

Lokale Daten

Bemerkungen Eingangsparameter, grafisch darstellbar Ausgangsparameter, grafisch darstellbar globale Daten POE-interne Daten

Tab. 2.3. Variablenarten für Schnittstelle und lokale Daten einer POE, siehe auch Kommentierung in Bsp 2.7.

2.3 Elemente einer POE

37

Formalparameter (VAR_INPUT): Die Aktualparameter werden der POE als Werte übergeben, d.h. nicht die Variable selbst wird an die POE weitergereicht, sondern lediglich ihre Kopie. Dadurch ist sichergestellt, dass diese Eingangsvariable innerhalb der aufgerufenen POE nicht verändert werden kann. Dieses Konzept wird auch als „call-by-value“ bezeichnet. Formalparameter (VAR_IN_OUT): Die Aktualparameter werden der aufgerufenen POE als Zeiger auf ihren Speicherort übergeben, d.h. die Variable selbst wird an die POE weitergereicht, so dass sie dort gelesen und verändert werden kann. Änderungen wirken sich also automatisch auf die außerhalb der aufgerufenen POE deklarierten Variablen aus. Dieses Konzept wird auch als „callby-reference“ bezeichnet. Diese Variablenart bietet in diesem Sinne „Zeiger“ (engl.: pointer), die auch in höheren Programmiersprachen wie C typischerweise für Rückgabewerte von Unterprogrammen verwendet werden, indem die Speicheradressen der entsprechenden Parameter übergeben werden. Rückgabewerte (VAR_OUTPUT) werden der aufgerufenen POE nicht übergeben, sondern stehen dort als Werte zur Verfügung. Sie sind daher nicht Bestandteil der Aufrufschnittstelle. Sie werden zwar grafisch zusammen mit VAR_INPUT und VAR_IN_OUT dargestellt, ihre Werte in textuellen Sprachen wie AWL oder ST jedoch nach Aufruf der POE als Variable lesend weiterverarbeitet. Ihre Übergabe an die aufrufende POE erfolgt ebenfalls „return-by-value“, indem ihre Werte der aufrufenden Instanz (FB oder PROG) zur Verfügung stehen. Dadurch sind die Ausgangsparameter der POE gegenüber Änderungen durch die aufrufende POE geschützt. Beim POE-Typ PROGRAM werden die Ausgangsparameter beim Aufruf durch die Ressource zusammen mit den Aktualparametern angegeben und entsprechenden Variablen zur Weiterverarbeitung zugewiesen (vgl. Beispiele des Kap. 6). Falls einer POE beim Aufruf umfangreiche Felder oder Datenstrukturen als Variablen übergeben werden, führt die Verwendung von VAR_IN_OUT zu effizienteren Programmen, da die Variablen zur Laufzeit nicht umkopiert werden müssen (VAR_INPUT bzw. VAR_OUTPUT), sondern einfach ihr Zeiger benutzt wird. Allerdings sind solche Variablen nicht vor (unerwünschter) Manipulation durch die aufgerufene POE geschützt.

38

2 Bausteine der IEC 61131-3

Externer und interner Zugriff auf POE-Variablen Formalparameter und Rückgabewerte besitzen die besondere Eigenschaft, auch außerhalb (extern) der sie verwendenden POE sichtbar zu sein: die aufrufende POE kann (muss aber nicht) ihre Namen explizit verwenden, um Eingangsvariable zu setzen. Dadurch wird die Aufrufstelle einer POE besser dokumentierbar und es können Parameter vertauscht bzw. weggelassen werden. Ein- und Ausgangsvariablen besitzen in diesem Zusammenhang zusätzlich einen Schutz gegen unberechtigtes Lesen bzw. Schreiben. Tab. 2.4 fasst sämtliche Variablenarten mit deren Bedeutung im Überblick zusammen. Dabei werden zu jeder Variablenart Schreib- bzw. Lese-Rechte angegeben, die kennzeichnen, ob eine Variable: -

in der aufrufenden POE („extern“) sichtbar und dort schreib- oder lesbar ist, innerhalb der POE („intern“) schreib- oder lesbar ist.

2.3 Elemente einer POE

Variablenart VAR, VAR_TEMP lokale Variable VAR_INPUT Eingangsvariable

Zugriffsrechtea extern

intern

-

SL

Sb

L

39

Erläuterung Eine lokale Variable ist nur innerhalb der POE sichtbar und kann nur dort bearbeitet werden.

Eine Eingangsvariable ist in der aufrufenden POE sichtbar und dort beschreibbar. Sie darf innerhalb der POE nur gelesen werden. Eine Ausgangsvariable ist in der aufrufenden POE L SL VAR_OUTPUT sichtbar und kann dort nur gelesen werden. Sie ist Ausgangsvariable durch die POE les- und beschreibbar. Eine Ein-/Ausgangsvariable beinhaltet die SL SL VAR_IN_OUT kombinierten Eigenschaften von VAR_INPUT und Ein- und VAR_OUTPUT: sie ist innerhalb und außerhalb der Ausgangsvariable POE les- und beschreibbar. Eine externe Variable wird benötigt, um innerhalb SL SL VAR_EXTERNAL einer POE auf eine globale Variable einer anderen Externe Variable POE lesend und schreibend zuzugreifen. Sie ist nur für POEs sichtbar, die diese globale Variable unter VAR_EXTERNAL aufführen, alle anderen haben keinen Zugriff auf diese globale Variable. Bezeichner und Typ einer Variablen unter VAR_EXTERNAL muss mit der korrespondierenden VAR_GLOBAL Deklaration im PROGRAM übereinstimmen. Auf eine GLOBAL deklarierte Variable kann von SL SL VAR_GLOBAL mehreren POEs lesend und schreibend zugegriffen Globale Variable werden. Hierzu muss die Variable in den anderen POEs unter VAR_EXTERNAL mit identischem Namen und identischem Typ angegeben werden. Globale Variable von Konfigurationen als SL SL VAR_ACCESS Kommunikationskanal zwischen Komponenten Zugriffspfade (Ressourcen) von Konfigurationen (vgl. Kap. 6). Sie kann innerhalb der POE wie eine globale Variable benutzt werden. a S = schreibend, L = lesend, SL = schreibend und lesend b nur schreibbar als Formalparameter beim Aufruf

Tab. 2.4. Bedeutung der Variablenarten. In der linken Spalte ist das Schlüsselwort der Variablenart jeweils fett dargestellt. In der Spalte „Zugriffsrechte“ wird angegeben, welche Schreib-/Leserechte für die aufrufende POE (extern) bzw. innerhalb der POE (intern) bestehen.

Für Eingangs- und Ausgangsvariablen bietet die IEC 61131-3 einen weitgehenden Zugriffsschutz, wie aus der Tab. 2.4 für VAR_INPUT und VAR_OUTPUT ersichtlich ist: Eingangsparameter dürfen innerhalb der POE nicht verändert werden, Ausgangsparameter nicht außerhalb. Auf Besonderheiten zum Deklarationsteil für Funktionsbausteine wird in Abschn. 2.4.1 im Zusammenhang mit der FB-Instanziierung nochmals eingegangen.

40

2 Bausteine der IEC 61131-3

Auf Formalparameter und Rückgabewerte von POEs kann sowohl beim Aufruf (externer Zugriff) als auch innerhalb der POE (interner Zugriff) zugegriffen werden, wie folgende Beispiele für Funktionsbausteine zeigen:

FUNCTION_BLOCK FBZwei VAR_INPUT EingVar : BYTE; END_VAR VAR_OUTPUT AusgVar : BYTE; END_VAR VAR LokVar : BYTE; END_VAR ... LD EingVar AND LokVar ST AusgVar ... END_FUNCTION_BLOCK

FUNCTION_BLOCK FBEins VAR BspFB : FBZwei; END_VAR

… LD 44 ST BspFB.EingVar CAL BspFB (* FB-Aufruf *) LD BspFB.AusgVar ... END_FUNCTION_BLOCK

Bsp. 2.9. Interner (links) und externer Zugriff (rechts) auf die FB-Formalparameter EingVar und AusgVar.

Im Bsp. 2.9 ruft FBEins den Baustein BspFB (beschrieben durch FBZwei) auf. Dazu übergibt er ihm die Konstante 44 als Aktualparameter für die Eingangsvariable EingVar. D.h. in FBEins ist diese Eingangsvariable sichtbar und wird vorbesetzt. Ebenso ist AusgVar sichtbar und kann in FBEins lesend weiterverarbeitet werden. Innerhalb FBZwei können EingVar gelesen (LD) und AusgVar geschrieben (ST) werden. Weitere Eigenschaften und Besonderheiten von Variablen und Variablenarten werden in Abschn. 3.4 beschrieben.

2.3.3 Anweisungsteil Der Anweisungsteil (Rumpf) einer POE folgt dem Deklarationsteil und enthält die von der SPS auszuführenden Anweisungen. Zur anwendungsgerechten Formulierung der Steuerungsaufgabe stehen in der IEC 61131-3 fünf Programmiersprachen zur Verfügung, von denen drei eine grafische Darstellung besitzen. Da die Art der Programmierung zwischen den einzelnen Sprachen stark voneinander abweicht, eignen sich diese für unterschiedliche Aufgaben und Anwendungsbereiche. Als Anhaltspunkt kann man beispielsweise angeben:

2.3 Elemente einer POE

AS

KOP

FBS

AWL ST

41

Ablaufsprache: Zerlegung der Steuerungsaufgabe in sequentielle und parallel auszuführende Bestandteile (Teilabschnitte), sowie deren Ausführungskontrolle. AS beschreibt anschaulich den Programmablauf, indem angegeben wird, welche Aktion des zu steuernden Prozesses zu welchem Zeitpunkt freigegeben bzw. beendet oder gesperrt wird. Die IEC 61131-3 betont die Bedeutung von AS als Darstellungsart zur Strukturierung des SPS-Programms. Kontaktplan: Grafische Verknüpfung („Stromlaufplan“) von booleschen Variablen (Kontakte und Spulen), geometrische Sicht einer Schaltung ähnlich früheren Relais-Steuerungen. In KOP geschriebene POEs werden in Netzwerk genannte Abschnitte unterteilt. Funktionsbausteinsprache: Grafische Verknüpfung unterschiedlicher Funktionselemente (arithmetische, boolesche, sonstige Funktionen und FBs). In FBS geschriebene POEs werden wie bei KOP in Netzwerke unterteilt. Häufig können boolesche FBS-Netzwerke auch in KOP dargestellt werden und umgekehrt. Anweisungsliste: Maschinennahe Programmiersprache, die von den meisten Programmiersystemen angeboten wird. Strukturierter Text: Höhere Programmiersprache (ähnlich PASCAL) für Steuerungsaufgaben sowie komplexe Berechnungsverfahren.

Tab. 2.5. Merkmale der Programmiersprachen der IEC 61131-3

Darüber hinaus erlaubt die Norm ausdrücklich, dass weitere Programmiersprachen (wie beispielsweise C oder BASIC) zur Programmierung zulässig sind, sofern sie folgende Bedingungen erfüllen: -

normgerechte Verwendung von Variablen wie in den übrigen Programmiersprachen der IEC 61131-3, also konform zum Deklarationsteil einer POE, normgerechte Aufrufe von Funktionen und Funktionsbausteinen, insbesondere der Standard-FUN bzw. -FB, keine Widersprüche zu übrigen Programmiersprachen bzw. der Darstellungsart AS.

Auf die IEC 61131-3 Programmiersprachen und ihre Darstellungsweise wird im Kap. 4 detailliert eingegangen.

42

2 Bausteine der IEC 61131-3

2.4 Der Funktionsbaustein Funktionsbausteine bilden das wesentliche Hilfsmittel zur Strukturierung von SPSProgrammen. Sie werden von Programmen und FBs aufgerufen und können selbst Funktionen und Funktionsbausteine aufrufen. In diesem Abschnitt wird auf die prinzipiellen Eigenschaften von Funktionsbausteinen eingegangen. Ein ausführliches FB-Beispiel ist in Anh. C zu finden. Das Konzept der „Instanziierung von FBs“ besitzt große Bedeutung in der Norm und bildet ein wesentliches Unterscheidungskriterium zwischen den drei POETypen. Daher wird zunächst dieses Konzept vorgestellt, bevor auf die übrigen Eigenschaften der POE-Typen eingegangen wird.

2.4.1 Instanziierung von Funktionsbausteinen

Was ist eine Instanz? Das Anlegen von Variablen durch den Programmierer unter Angabe des Variablen-Namens und Datentyps bei der Deklaration wird Instanziierung oder Instanzbildung genannt. Im folgenden Beispiel 2.10 ist die Variable namens Ventil eine Instanz des Datentyps BOOL:

Ventil

:

BOOL;

Variablen-Name

Motor1

:

MotorTyp;

FB-Instanz-Name

(* boolesche Variable *) Datentyp

(* FB-Instanz *) FB-Typ (benutzerdefiniert)

Bsp. 2.10. Deklaration einer Variable als „Instanz eines Datentyps“ (oben). Deklaration einer FB-„Variable“ als „Instanz eines benutzerdefinierten FB-Typs“ (unten).

Wie Variablen werden auch Funktionsbausteine instanziiert: In Bsp. 2.10 wird zum benutzerdefinierten Funktionsbaustein (FB-Typ) MotorTyp innerhalb einer POE-Deklaration die FB-Instanz Motor1 deklariert. Nach der Instanziierung kann ein FB (als Instanz) innerhalb der POE verwendet und aufgerufen werden.

2.4 Der Funktionsbaustein

43

Das Prinzip der Instanziierung mag auf den ersten Blick ungewöhnlich erscheinen, ist jedoch nichts wirklich Neues. Bisher wurden beispielsweise Funktionsbausteine mit Zeit- oder Zählaufgaben, kurz Zeiten und Zähler genannt, zumeist durch ihren Typ (wie Zählrichtung, Zeitverlauf) sowie eine vom Benutzer vergebene Nummer eindeutig festgelegt (z.B. Zähler „C 19“). In der neuen Norm wird nun anstelle dieser absoluten Nummer ein Variablenname unter Angabe des entsprechenden Zeiten- oder Zählertyps verlangt. Dazu wird eine Deklaration im Deklarationsteil der POE erforderlich. Das Programmiersystem kann beim Übersetzen der POE für diese FB-Variablen intern automatisch absolute Nummern für die SPS erzeugen. Mit Hilfe dieser Namen greift der SPS-Programmierer übersichtlich auf verschiedene Zeiten und Zähler desselben Typs zu, ohne dass sie sich gegenseitig beeinflussen. Die IEC 61131-3 vereinheitlicht durch die Instanziierung die Verwendung von herstellerspezifischen (wie typischerweise Zeiten und Zähler) und benutzerdefinierten FBs. Der Instanzname entspricht von der Handhabung her dem entsprechenden symbolischen Bezeichner, der FB-Typ der FB-Aufrufschnittstelle. FB-Instanzen bieten darüber hinaus noch wesentlich mehr: „Struktur“ und „Gedächtnis“ für FBs werden in den beiden nächsten Abschnitten beschrieben. Der Begriff „Funktionsbaustein“ wird häufig für zwei verschiedene Bedeutungen verwendet: er dient sowohl als Synonym für den FB-Instanznamen wie auch als FB-Typ ( = Name des FB selbst). In diesem Buch wird mit „Funktionsbaustein“ der FB-Typ bezeichnet, während die FB-Instanz jeweils ausdrücklich als Instanzname gekennzeichnet wird. Bsp. 2.11 zeigt einige Deklarationen von Funktionsbausteinen (hier Std.-FBs) und Variablen im Vergleich:

VAR FUELLST NOT_AUS Zeit9 Zeit13 ZaehlRueck AllgZaehler END_VAR

: UINT; : BOOL; : TON; : TON; : CTD; : CTUD;

(* vorzeichenlose Ganzzahl-Variable *) (* boolesche Variable *) (* Zeitglied vom Typ Einschaltverzögerung *) (* Zeitglied vom Typ Einschaltverzögerung *) (* Rückwärtszähler *) (* Auf- und Abwärtszähler *)

Bsp. 2.11. Beispiele zur Variablendeklaration und Instanziierung von Standard-Funktionsbausteinen (fett dargestellt)

Obwohl Zeit9 und Zeit13 in diesem Beispiel auf demselben FB-Typ (TON) eines Zeiten-FB beruhen, sind es eigenständige Zeitbausteine, die als Instanzen getrennt

44

2 Bausteine der IEC 61131-3

voneinander aufgerufen und ausgewertet werden, also zwei „Zeiten“ repräsentieren. FB-Instanzen sind innerhalb der POE sichtbar und benutzbar, in der sie deklariert wurden. Werden sie als global deklariert, stehen sie mit VAR_EXTERNAL sämtlichen POEs zur Verfügung. Funktionen sind dagegen immer projektweit sichtbar und können von jeder POE (ohne Deklaration) aufgerufen werden. Ebenso sind FB-Typen projektweit bekannt und können in jeder POE zur Deklaration von Instanzen benutzt werden. Deklaration und Aufruf der Standard-FBs werden in Kap. 5 ausführlich beschrieben. Ihre Verwendung wird in der jeweiligen Programmiersprache erläutert, siehe Kap. 4. Instanz bedeutet „Struktur“. Das Konzept der Instanziierung führt am Beispiel von Funktionsbausteinen wie Zeiten und Zählern zu strukturierten Variablen, die: -

die Aufrufschnittstelle wie eine Datenstruktur beschreiben, den aktuellen Zustand der Zeit oder des Zählers beinhalten, eine Methode zum Aufruf des FB darstellen.

Dies ermöglicht eine flexible Parametrierung beim Aufruf eines Funktionsbausteins und wird am Beispiel eines Vor-/Rückwärtszählers dargestellt:

VAR Zaehler : END_VAR

CTUD;

(* Vor-/Rückwärtszählers *)

Bsp. 2.12. Deklaration eines Vor-/Rückwärtszählers nach IEC 61131-3

Auf die Ein- und Ausgänge dieses Zählers kann nach dieser Deklaration mit Hilfe einer durch die IEC 61131-3 implizit definierten Datenstruktur zugegriffen werden, die in Bsp. 2.13 zur Verdeutlichung als Ersatzdarstellung angegeben wird.

2.4 Der Funktionsbaustein

45

TYPE CTUD : (* Datenstruktur einer FB-Instanz mit FB-Typ CTUD *) STRUCT (* Eingänge *) CU : BOOL; (* count up *) CD : BOOL; (* count down *) R : BOOL; (* reset *) LD : BOOL; (* load *) PV : INT; (* preset value *) (* Ausgänge *) QU : BOOL; (* output up *) QD : BOOL; (* output down *) CV : INT; (* current value *) END_STRUCT; END_TYPE

Bsp. 2.13. Datenstruktur zum Vor-/Rückwärtszähler (Standard-FB) in Bsp. 2.12 als Ersatzdarstellung

Die in Bsp. 2.13 dargestellte Datenstruktur spiegelt die Formalparameter (Aufrufschnittstelle) und Rückgabewerte des Std.-FB CTUD wider. Sie stellt in diesem Sinne die Aufrufer-Sicht für diesen FB dar. Im FB enthaltene lokale oder als extern deklarierte Variablen bleiben verdeckt. Diese Datenstruktur wird durch das Programmiersystem automatisch verwaltet und kann zur Parametrierung eines FBs beim Aufruf, wie in Bsp. 2.14 in AWL gezeigt, komfortabel benutzt werden:

LD ST LD ST LD ST CAL LD

34 Zaehler.PV %IX7.1 Zaehler.CU %M3.4 Zaehler.R Zaehler Zaehler.CV

(* Zählwert setzen *) (* hochzählen *) (* Zähler rücksetzen *) (* Aufruf des FB mit den aktuellen Parametern *) (* aktuellen Zählstand abfragen *)

Bsp. 2.14. Parametrierung und Aufruf des Vor-/Rückwärtszählers in Bsp. 2.12

In diesem Beispiel wird die Instanz Zaehler mit den Parametern 34, %IX7.1 und %M3.4 versorgt, bevor Zaehler in der fett dargestellten Zeile mit CAL aufgerufen wird. Anschließend wird der aktuelle Zählstand abgefragt. Wie in Bsp. 2.14 zu sehen ist, wird auf die FB-Ein- und Ausgangsparameter mit Hilfe des FB-Instanznamens und einem trennenden Punkt zugegriffen, wie es für Strukturvariablen (vgl. Abschn. 3.5.2) ebenfalls festgelegt ist. Beim Aufruf nehmen nicht verwendete Eingangs- oder Ausgangsparameter Anfangswerte an, die ggf. innerhalb des FB anzugeben sind.

46

2 Bausteine der IEC 61131-3

In Abschn. 4.1.4 werden zwei weitere Methoden vorgestellt, mit denen FBs in AWL über ihre Instanznamen aufgerufen werden können. Instanz bedeutet „Gedächtnis“. Durch die Deklaration mehrerer Variablennamen mit demselben FB-Typ wird für jede so gebildete Instanz gewissermaßen eine „Daten-Kopie“ des FBs im Speicher erzeugt. Diese Kopie beinhaltet sämtliche Werte der lokalen (VAR) sowie Einund Ausgangsvariablen (VAR_INPUT, VAR_OUTPUT) des FBs (Datensatz). Sie erstreckt sich nicht auf VAR_IN_OUT (keine Werte selbst, sondern nur Zeiger auf Variable) oder VAR_EXTERNAL (sind globale Variable). Dadurch kann die Instanz über mehrere Aufrufe hinweg lokale Datenwerte sowie die Ein- und Ausgangsparameter speichern, besitzt also eine Art „Gedächtnis“. Ein solches Gedächtnis ist für FBs wie Flip-Flops oder Zähler wichtig, deren Verhalten abhängig vom aktuellen Zustand ihrer Merker bzw. Zählwerte ist. Sämtliche Variablen dieses Gedächtnisses liegen in einem der FB-Instanz (durch die Deklaration) fest zugeordneten Speicherbereich. Dieser Speicherbereich muss daher statisch sein. Dies bedeutet, dass für die Verwaltung lokaler temporärer Variablen nicht wie oft üblich der Programmkeller (engl.: stack) verwendet werden kann! Insbesondere bei Funktionsbausteinen, die große lokale Datenbereiche wie Tabellen verwalten, können solche lokalen Daten zu einem (unnötig) großen statischen Speicherbedarf der FB-Instanz führen. Die IEC 61131-3 definiert daher den Variablentyp VAR_TEMP. Muss der Wert einer Variablen zwischen zwei Aufrufen nicht erhalten bleiben, wird er mit der VAR_TEMP Deklaration angelegt. Das Programmiersystem legt in diesem Fall mittels eines dynamischen Bereichs oder Stacks einen Speicherplatz an, der nur zur Ausführungszeit der Instanz Gültigkeit besitzt. Ebenso können umfangreiche Ein- und Ausgangsparameter zu speicherplatzintensiven FB-Instanzen führen. Dabei kann die Verwendung von VAR_IN_OUT anstelle von VAR_INPUT bzw. VAR_OUTPUT helfen, Speicherplatz zu sparen.

2.4 Der Funktionsbaustein

47

In Abschn. 2.3.2 wurde beschrieben, dass Ein- und Ausgangsvariablen von POEs Einschränkungen beim lesenden bzw. schreibenden Zugriff unterliegen. Dies ist insbesondere für die FB-Instanz von Bedeutung: -

-

Eingangsparameter (Formalparameter) einer FB-Instanz bleiben für den nächsten Aufruf erhalten. Könnte der aufgerufene FB seine Eingangsvariablen ändern, wären diese beim nächsten Aufruf der Instanz verfälscht, ohne dass die aufrufende POE dies merken würde. Ausgangsparameter (Rückgabewerte) einer FB-Instanz bleiben ebenfalls zwischen Aufrufen erhalten. Könnten sie durch die aufrufende POE verändert werden, könnte der aufgerufene FB dies nicht berücksichtigen und von falschen Annahmen über seinen eigenen Ausgangszustand ausgehen.

FB-Instanzen können mit Hilfe des Schlüsselworts RETAIN ebenso wie normale Variable batteriegepuffert werden, d.h. sie behalten bei einem Stromausfall ihre lokalen Werte und die ihrer Aufrufschnittstelle bei. Abschließend wird ein Zusammenhang zwischen FB-Instanzen und der bisher üblichen Verwendung von Datenbausteinen (DB) gezeigt. Zusammenhang zwischen FB-Instanz und Datenbaustein. Vor Aufruf eines (bisherigen) FBs, der – außer Übergabeparametern – keinen lokalen Datenbereich besitzt, wird oft ein Datenbaustein aktiviert, der beispielsweise Rezepturdaten oder Parametrierungsinformation besitzt. Innerhalb des FBs kann dieser DB auch als lokaler Datenbereich dienen. D.h. der Programmierer kann einen (bisherigen) FB mit individuellen „Instanzdaten“ verwenden, wobei er die eindeutige Zuordnung zwischen Daten und FB selbst zu kontrollieren hat. Diese Daten bleiben wie bei Instanzen ebenfalls zwischen den Aufrufen des FB erhalten, da der DB global zur Verfügung steht, wie Bsp 2.16 veranschaulicht:

SPA

DB 14

(* globaler DB *)

SPA ...

FB 14

(* Aufruf FB *)

a) bisheriges DB/FB-Paar

VAR_GLOBAL FB_14 : FB_Bsp; END_VAR CAL FB_14 ...

(* globale Instanz *) (* Aufruf FB-Instanz *)

b) FB-Instanz nach IEC 61131-3

Bsp. 2.15. Verwendung eines übliches DB/FB-Paares ähnlich einer FB-Instanz nach IEC 61131-3.Auf diese Methode wird in Abschn. 7.7 noch einmal eingegangen. Diese Form der Instanziierung beschränkt sich auf Funktionsbausteine, sie ist für Funktionen (FUNCTION) prinzipiell nicht möglich. Programme werden innerhalb der Konfiguration als oberste Hierarchie-Ebene ebenfalls instanziiert und aufgerufen. Allerdings unterscheidet sich diese (mächtigere) Instanz-Form von der des FBs, indem sie bei gleichzeitiger

48

2 Bausteine der IEC 61131-3

Zuordnung zu Tasks zur Bildung von Laufzeitprogrammen führt. Dies wird in Kap. 6 beschrieben.

2.4.2 Wiederverwendbarkeit und Objektorientierung von FB Funktionsbausteine unterliegen einigen Einschränkungen, die ihre Wiederverwendbarkeit sicherstellen: -

-

-

Die Deklaration von Variablen mit fester Zuordnung zu SPS-Adressen (vgl. Kap. 3: „Direkt dargestellte Variablen“: %Q, %I, %M) als lokale Variable ist in Funktionsbausteinen unzulässig, damit sie unabhängig von spezieller SPSHardware bleiben können. Eine Verwendung der SPS-Adressen als globale Variable in VAR_EXTERNAL bleibt davon unberührt. Die Deklaration von Zugriffspfaden mit VAR_ACCESS (vgl. Kap. 3) oder globalen Variablen mit VAR_GLOBAL ist ebenfalls nicht zulässig. Durch VAR_EXTERNAL kann auf globale Daten und damit indirekt auch auf Zugriffspfade zugegriffen werden. Dateninformation von außerhalb kann ausschließlich über die zulässigen Variablenarten als POE-Schnittstelle (Parameter und externe Variable) in den FB gebracht werden. Es gibt keine „Vererbungs-“ Eigenschaften wie in manchen anderen Programmiersprachen.

Daher werden Funktionsbausteine auch als gekapselt bezeichnet, um auszudrücken, dass sie universell verwendbar und bei ihrer Ausführung frei von unerwünschten Seiteneffekten sind. Die (lokalen) Daten des FBs und damit ihre Funktion hängen nicht unmittelbar von globalen Variablen, der SPS-Peripherie oder systemweiten Kommunikationspfaden ab. FBs können solche Datenbereiche nur indirekt über ihre (dokumentierbare) Schnittstelle manipulieren. Im vorangegangenen Abschnitt wurde das Instanz-Modell der Funktionsbausteine mit den Eigenschaften „Strukturierung“ und „Gedächtnis“ erläutert. Zusammen mit den Eigenschaften zur Wiederverwendbarkeit ergibt sich eine neuartige Sicht von Funktionsbausteinen, die man folgendermaßen umschreiben könnte: „Ein FB ist eine eigenständige, nach außen gekapselte Datenstruktur mit einer auf ihr definierten Berechnungsvorschrift“. Die Berechnung wird durch den Anweisungsteil des FBs dargestellt. Die Datenstruktur entspricht der FB-Instanz und kann „aufgerufen“ werden, was bei normalen Datenstrukturen nicht möglich ist. Von jedem FB-Typ können beliebig viele Instanzen gebildet werden, die voneinander unabhängig sind. Jede Instanz besitzt einen eindeutigen Namen mit eigenem Datenbereich. Aufgrund dieser Sichtweise werden Funktionsbausteine nach IEC 61131-3 auch als „objektorientiert“ bezeichnet. Allerdings dürfen diese Eigenschaften nicht mit den umfassenderen Sprachmitteln gleichgesetzt werden, die heute moderne

2.4 Der Funktionsbaustein

49

„Objektorientierte Programmiersprachen (oOOP)“ wie beispielsweise C# mit ihren Klassenhierarchien bieten. Zusammengefasst arbeiten FBs auf ihrem eigenen Datensatz, der Ein- und Ausgangsvariablen sowie lokale Variablen enthält. Bei bisheriger SPS-Programmierung greifen FBs üblicherweise auf globale Daten (wie Merkerbereiche und Datenbausteine) zu.

2.4.3 Variablenarten in FBs Ein FB kann keine oder beliebig viele Ein- und Ausgangsparameter sowie lokale und als extern deklarierte Variablen benutzen. Zusätzlich oder alternativ zur Batteriepufferung einer FB-Instanz können auch die lokalen oder Ausgangsvariablen innerhalb des FB-Deklarationsteils als gepuffert deklariert werden. Die Werte von Eingangs- bzw. Ein-/Ausgangsvariablen sind innerhalb der FBDeklaration nicht als gepuffert (RETAIN) angebbar, da es sich um ÜbergabeParameter handelt. Doch kann die FB-Instanz selbst per RETAIN gepuffert sein! Für VAR_IN_OUT ist zu beachten, dass ihre Zeiger auf Variablen zwar in einer mit RETAIN geschützten Instanz erhalten bleiben, die dazugehörigen Variablenwerte selbst jedoch verloren sein können, wenn sie nicht in der aufrufenden POE als batteriegepuffert deklariert wurden. Direkt dargestellte Variable dürfen in FBs wegen der geforderten PeripherieUnabhängigkeit nicht lokal deklariert, sondern nur als globale Variable über VAR_EXTERNAL „importiert“ werden. Eine Besonderheit bei der Variablendeklaration stellen flankengesteuerte Parameter in der IEC 61131-3 dar. Die IEC stellt die Standard-FBs R_TRIG und F_TRIG zur Flankenerkennung zur Verfügung (siehe auch Kap. 5). Die Verwendung der Flankenerkennung als Attribut von Variablenarten ist nur für Eingangsvariablen vorgesehen (siehe Abschn. 3.5.4). Für die Definition einiger SPS-typischen Grundfunktionen wie Zeiten und Zähler werden FBs benötigt, da sie eigene Zustandsinformationen besitzen. Dazu definiert die IEC 61131-3 eine Reihe von Standard-FBs, die in Kap. 5 anhand von Beispielen erläutert werden.

50

2 Bausteine der IEC 61131-3

2.5 Die Funktion Der Grundgedanke bei der Definition von Funktionen nach IEC 61131-3 besteht darin, dass Funktionen die Werte ihrer Eingangsvariablen über die Anweisungen im Funktionsrumpf zu einem eindeutigen Funktionswert („seiteneffektfrei“) sowie Ausgangswerten verknüpfen. In diesem Sinne stellen sie im einfachsten Fall eine hersteller- oder anwenderspezifische Erweiterung des Operationsvorrats der SPS dar. Für Funktionen gilt daher die Regel: gleiche Eingangswerte liefern immer dieselben Ausgangswerte und Funktionswert, unabhängig davon, wie oft oder zu welchem Zeitpunkt die Funktion aufgerufen wird, sie besitzen also kein Gedächtnis wie die FBs. Funktionen können als AWL-Operatoren ebenso verwendet werden wie als Operanden in ST-Ausdrücken. Wie FB-Typen, jedoch nicht wie die FB-Instanzen, sind auch die Funktionen sämtlichen POEs eines Projekts bekannt. Um die Definition der Grund-Funktionalität eines SPS-Systems zu vereinfachen und gleichzeitig zu vereinheitlichen, legt die IEC 61131-3 eine Sammlung von häufig verwendeten Standard-Funktionen fest, deren Eigenschaften, Laufzeitverhalten und Aufrufschnittstelle normiert sind (siehe auch Kap. 5). Mit Hilfe benutzerdefinierter Funktionen wird diese Sammlung um gerätespezifische Erweiterungen oder individuelle Funktionsbibliotheken ergänzt. Ein ausführliches FUN-Beispiel ist in Anh. C zu finden. Funktionen besitzen gegenüber den beiden anderen POE-Typen einige Einschränkungen, die zur Seiteneffektfreiheit benötigt werden und dazu dienen, dass sie auch in Ausdrücken (z.B. in ST) verwendet werden können. Dies wird im nächsten Abschnitt näher betrachtet.

2.5.1 Variablenarten in Funktionen und ihr Funktionswert Funktionen besitzen beliebig viele Eingangs- und Ausgangsparameter sowie genau einen Funktionswert. Der Funktionswert kann ein beliebiger, auch abgeleiteter Datentyp sein. Ein einfacher boolescher Wert oder ein Gleitpunkt-Doppelwort ist ebenso zugelassen wie ein Feld oder eine komplexe Datenstruktur, die aus mehreren Datenelementen bestehen kann (Multielement-Variable), wie in Kap. 3 anschließend beschrieben wird. In jeder Sprache der IEC 61131-3 wird der Funktionsname als besondere Variable innerhalb des Funktionsrumpfs verwendet, um explizit den Funktionswert zuweisen zu können.

2.5 Die Funktion

51

Da Funktionen bei gleichen Eingangsvariablen dasselbe Ergebnis liefern müssen, dürfen sie sich keine Zwischenergebnisse von einem Aufruf zum anderen merken („gedächtnislos“). Daher können Funktionen lokale Variablen für Zwischenergebnisse benutzen, diese gehen allerdings bei Beendigung der Funktion verloren. Lokale Variablen können daher auch nicht als gepuffert deklariert werden. Ebenso dürfen innerhalb von Funktionen keine Funktionsbausteine wie beispielsweise Zeiten, Zähler oder Flankenerkennungen aufgerufen werden. Auch die Verwendung von globalen Variablen ist innerhalb von Funktionen unzulässig. Wie ein SPS-System im Falle einer Spannungs-Unterbrechung und danach mit (insbesondere komplexen) Funktionen und deren aktuellen Variablenwerten umgeht, wird durch die Norm nicht festgelegt. Daher muss diejenige POE für die gewünschte Variablenpufferung sorgen, die eine Funktion aufruft. Auf jeden Fall ist es sinnvoll, in Unterprogrammen mit sensiblen Daten anstelle einer Funktion ggf. einen FB zu verwenden. Weiterhin können in Funktionen – ebenso wenig wie in FBs – keine Direkt dargestellten Variablen (physikalische Speicheradressen der SPS) deklariert werden. Bsp. 2.16 zeigt ein Beispiel für Deklaration und Aufruf einer Funktion, welche die Wurzelberechnung durchführt: neben dem Wurzelergebnis, das im Funktionswert zurückgegeben wird, ist das Fehlerflag, das eine ungültige Wurzel mit negativer Zahl, Rückgabeparameter.

52

2 Bausteine der IEC 61131-3

FUNCTION Wurzel : INT VAR_INPUT EingVar : INT; END_VAR VAR_TEMP Ergebnis : INT; END_VAR VAR_OUTPUT Fehler : BOOL; END_VAR LD EingVar LT 0 JMPC M_Fehler LD EingVar SQRT ST Ergebnis LD FALSE ST Fehler JMP M_Ende M_Fehler: LD 0 ST Ergebnis LD TRUE ST Fehler M_Ende: LD Ergebnis RET

(* Wurzel ziehen *) (* Beginn Deklarationsteil *) (* Eingangsparameter *) (* Eingangsvariable *) (* Zwischenwerte *) (* lokale Variable *) (* Ausgangsparameter *) (* Flag für Wurzel aus neg. Zahl *) (* Beginn Anweisungsteil *) (* Null laden *) (* negative Zahl? *) (* Fehlerfall *) (* Eingangsvariable laden *) (* Wurzel ziehen *) (* Ergebnis ist ok *) (* logisch „0“ für Fehlerflag: ruecksetzen *) (* Fehlerflag ruecksetzen *) (* fertig, Sprung auf FUN-Ende *) (* Behandlung des Fehlers „negative Zahl“ *) (* Null, da Ausgange im Fehlerfall ungueltig ist *) (* Resultat ruecksetzen *) (* logisch „1“ fuer Fehlerflag: setzen *) (* Fehlerflag setzen *) (* Ergebnis steht dann im Funktionswert! *) (* FUN-Ende *)

END_FUNCTION

Bsp. 2.16. Deklaration und Aufruf einer Funktion „Wurzel ziehen mit Fehler“ in AWL.

2.6 Das Programm PROGRAM

53

2.6 Das Programm PROGRAM Während Funktionen und Funktionsbausteine „Unterprogramme“ darstellen, bilden POEs vom Typ PROGRAM das „Hauptprogramm“ der SPS. Auf einer Multitasking-fähigen Steuerungs-Hardware können mehrere Hauptprogramme parallel ablaufen. Daher besitzen PROGRAMs gegenüber FBs besondere Eigenschaften, die hier erläutert werden. Für ein PROGRAM stehen dem SPS-Programmierer zusätzlich zu den Eigenschaften der Funktionsbausteine folgende weitere Merkmale zur Verfügung: -

Deklaration Direkt dargestellter Variablen zum Ansprechen physikalischer SPS-Adressen (%Q, %I, %M) ist zulässig, Verwendung von VAR_ACCESS oder VAR_GLOBAL ist möglich, PROGRAM wird innerhalb der SPS-Konfiguration einer Task zugeordnet, um ein Laufzeitprogramm zu bilden, d.h. Programme werden nicht explizit durch andere POEs aufgerufen.

Ein Programm beinhaltet die Zuordnung von Variablen zur SPS-Peripherie, indem Direkt dargestellte bzw. Symbolische Variable global oder als POE-Parameter verwendet werden. Weiterhin werden im Programm Mechanismen beschrieben, mit denen Kommunikation und globaler Datenaustausch zu anderen Programmen (innerhalb und außerhalb der Konfiguration) stattfindet. Dafür wird die Variablenart VAR_ACCESS verwendet. Diese Eigenschaften können auch auf der Ebene von Ressourcen und Konfigurationen genutzt werden, was bei komplexen SPS-Projekten zu empfehlen ist. Für kleinere Projekte kann man durch die Funktionaliät der Programm-POE auch ohne eine Konfigurationsdefinition auskommen: Das PROGRAM übernimmt die Aufgaben der Zuordnung des Programms zur SPS-Peripherie. Solche Möglichkeiten sind abhängig von der Funktionalität eines Programmiersystems und werden hier nicht weiter betrachtet. Ein ausführliches PROGRAM-Beispiel ist in Anh. C zu finden. Laufzeit-Eigenschaften und -Sonderbehandlung eines PROGRAM in einer SPSCPU kommen in der Zuordnung des PROGRAM zu TASKs zum Ausdruck. Dabei wird das Programm instanziiert, kann also mehreren Tasks zugeordnet und dadurch in der SPS mehrfach gleichzeitig ausgeführt werden. Diese Instanziierung unterscheidet sich allerdings von der für FB-Instanzen. Diese Zuordnung wird innerhalb der CONFIGURATION vorgenommen und in Kap. 6 erläutert.

54

2 Bausteine der IEC 61131-3

2.7 Ausführungssteuerung mit EN und ENO In Kontaktplan (KOP) gibt es für Funktionen und Funktionsbausteine gegenüber den übrigen Programmiersprachen der IEC 61131-3 eine Besonderheit: hier werden diese POEs mit je einem zusätzlichen Ein- und Ausgang dargestellt. Dazu dienen der boolesche Freigabe-Eingang EN (Enable In) und der boolesche Ausgang ENO (Enable Out).

SperreAus VarEin

Fun1 EN

ENO

Ein

Aus

KeinFehler VarAus

Bsp. 2.17. Aufruf einer Funktion oder eines Funktionsbausteins mit EN/ENO in KOP

Bsp. 2.17 zeigt die grafische Darstellung für den Aufruf der Funktion Fun1 mit EN und ENO in KOP. In diesem Beispiel wird Fun1 nur dann ausgeführt, wenn der Eingang EN auf „1“ (TRUE) ist, d.h. der Kontakt SperreAus geschlossen ist. Dann liegt nach fehlerfreier Abarbeitung der POE am Ausgang ENO ebenfalls TRUE, so dass die Variable KeinFehler gesetzt bleibt. Mit Hilfe des EN/ENO-Paars ist es in KOP-Darstellung möglich, jede Funktion und Funktionsbaustein, also auch solche mit nicht-booleschen Ein- und Ausgängen wie Fun1 in Bsp. 2.17, in den „Stromfluss“ der KOP-Linien zumindest teilweise zu integrieren. Aus dieser Vorstellung leitet sich die Bedeutung von EN/ENO ab, die in Tab. 2.6 skizziert wird:

2.7 Ausführungssteuerung mit EN und ENO Erläuterunga Ist EN beim Aufruf der POE FALSE, so darf der Anweisungsteil der POE nicht ausgeführt werden, sie wird also nicht durchlaufen. Der Ausgang ENO wird beim Verlassen des nicht erfolgten POE-Aufrufs ebenfalls auf FALSE gesetzt, um zu signalisieren, dass die POE nicht ausgeführt wurde. Hinweis für FB: Zuweisungen an Eingänge werden bei FB implementierungsabhängig ausgeführt, Die Werte der FB-Instanz behalten ihren Zustand vom vorhergehenden Aufruf. Bei FUN spielt dies keine Rolle (ohne Gedächtnis). EN = TRUE Ist EN beim Aufruf der POE TRUE, so wird der Anweisungsteil der POE normal ausgeführt. ENO wird in diesem Fall vor Ausführung des Anweisungsteils auf TRUE gesetzt. ENO kann anschließend durch Anweisungen im Rumpf der POE auf TRUE oder FALSE gesetzt werden. Falls bei der Ausführung des Anweisungsteils einer der Programm- oder Systemfehler auftritt, wie sie in Anh. E beschrieben werden, wird ENO durch das SPS-System auf FALSE zurückgesetzt. a TRUE = logisch „1“, FALSE = logisch „0“ EN EN=FALSE

55

ENO ENO = FALSE

ENO = TRUE

ENO = indiv. Wert

ENO = FALSE (Fehler aufgetreten)

Tab. 2.6. Bedeutung von EN und ENO für Funktionen und Funktionsbausteine

Aus Tab. 2.6 ergibt sich, dass EN und ENO den Kontrollfluss in einem grafischen Netzwerk steuern, nämlich die bedingte Ausführung einer Funktion mit der entsprechenden Nachbehandlung. EN kann nicht nur mit einem Kontakt wie in Bsp. 2.17 beschaltet werden, sondern auch mit einer Verknüpfung mehrerer Kontakte. ENO kann entsprechend mit einer komplexeren Nachverknüpfung (Kontakte und Spulen) versehen werden. Diese Kontrollfluss-Steuerung sollte im SPS-Programm allerdings logisch von den KOP-Verknüpfungen unterschieden werden, die den Datenfluss des Netzwerks bilden. Diese speziellen Ein- und Ausgänge EN und ENO werden in der IEC 61131-3 nicht wie gewöhnliche Ein- oder Ausgänge von FUN oder FB behandelt, sondern sind ausschließlich für die eben beschriebenen Aufgaben vorgesehen. Typische Beispiele für Funktionsbausteine dafür sind Zeiten- oder Zähler. In den anderen Sprachen der IEC 61131-3 ist die Verwendung dieser zusätzlichen Ein- und Ausgänge nicht vorgesehen - mit Ausnahme von FBS. Hier kann eine entsprechende Darstellung mit EN/ENO ebenfalls realisiert sein. Der Funktionsaufruf in Bsp. 2.17 kann in AWL dargestellt werden, falls das Programmiersystem EN/ENO implizit als Systemvariable unterstützt.

56

2 Bausteine der IEC 61131-3

Unterstützt ein Programmiersystem den Gebrauch von EN und ENO, sind die so programmierten POEs schwierig in eine textuelle Form zu transformieren. Um dies zu ermöglichen, müssten EN/ENO auch Schlüsselworte in AWL oder ST sein und dort wie in KOP/FBS automatisch generiert werden. Dann könnte eine in KOP aufgerufene Funktion beispielsweise auch in AWL geschrieben werden und das ENO-Flag im Fehlerfall setzen. Ansonsten könnten in KOP/FBS nur solche Funktionen aufgerufen werden, die auch in einer dieser Sprachen geschrieben wurden. Die Norm macht allerdings keine Aussage darüber, wie EN und ENO als Schlüsselworte bzw. Grafik-Elemente in KOP oder FBS zu verwenden sind, um sie setzen oder rücksetzen zu können. Außerdem stellt sich die Frage, inwieweit die Verwendung von EN und ENO bei Vergleichsfunktionen (Std.-FUN, siehe Anh. A) vorteilhaft ist. Ein Vergleicher besitzt dann zwei boolesche Ausgänge, die jeweils mit einer Spule versehen werden könnten. Falls dieser Vergleicher im Parallelzweig eines KOP-Netzwerks liegt, müssen ENO und der Ausgang Q getrennt voneinander weiterverknüpft werden: ENO führt den Parallelzweig fort, während mit Q gewissermaßen ein neues Teilnetzwerk beginnt. Aufgrund dieser Komplexität verwenden nur einige der heutigen IEC-Programmiersysteme EN und ENO. Anstatt in KOP/FBS das boolesche Paar EN und ENO fest vorzuschreiben, gibt es auch denkbare Alternativen: -

EN und ENO können in sämtlichen Programmiersprachen explizit und implizit

benutzt werden, jede in KOP/FBS aufrufbare Funktion muss mindestens einen binären Eingang und Ausgang besitzen, nur Standard-Funktionen besitzen ein EN/ENO-Paar (für Fehlerbehandlungen innerhalb des SPS-Systems), das für benutzerdefinierte Funktionen allerdings nicht verwendet werden kann.

Die dritte Alternative kommt der Definition nach IEC 61131-3 am nächsten. Dies würde allerdings bedeuten, dass EN und ENO vom SPS-Programmierer nicht beeinflussbare System-Variablen in der SPS sind.

2.8 Aufrufe von Funktionen und Funktionsbausteinen

57

2.8 Aufrufe von Funktionen und Funktionsbausteinen In diesem Abschnitt wird auf die Besonderheiten eingegangen, die beim Aufruf von Funktionen und Funktionsbausteinen zu beachten sind. Diese Besonderheiten gelten sowohl für die Standard- als auch die benutzerdefinierten Funktionen und Funktionsbausteine. Die nachfolgenden Beispiele werden weiterhin in AWL angegeben. Verwendung in ST sowie die grafische Darstellung in KOP und FBS sind Gegenstand des Kap. 4.

2.8.1 Gegenseitiger Aufruf zwischen POEs Für den gegenseitigen Aufruf von POE-Typen gelten die durch Abb. 2.7 veranschaulichten Regeln: -

PROGRAM darf FUNCTION_BLOCK und FUNCTION aufrufen, jedoch nicht umgekehrt, FUNCTION_BLOCK darf FUNCTION_BLOCK aufrufen, FUNCTION_BLOCK darf FUNCTION aufrufen, jedoch nicht umgekehrt, POE-Aufrufe dürfen nicht rekursiv sein (POE darf „sich nicht selbst“ aufrufen), auch nicht indirekt.

-

PROGRAM 1 FUNCTION

FUNCTION_BLOCK 3

2

FUNCTION

FUNCTION

FUNCTION_BLOCK

1

Programm ruft Funktion oder Funktionsbaustein auf

2

Funktion ruft Funktion auf

3

Funktionsbaustein ruft Funktion oder Funktionsbaustein auf

Abb. 2.7. Aufruf-Möglichkeiten zwischen POE-Typen: drei erlaubte Fälle

58

2 Bausteine der IEC 61131-3

Programme und FB-Instanzen können FB-Instanzen aufrufen, während Funktionen FB-Instanzen nicht aufrufen können, da sonst die Seiteneffektfreiheit der Funktionen nicht mehr gewährleistet wäre. Programme (PROGRAM) werden in der Konfiguration mit Hilfe der TASK zu Laufzeitprogrammen instanziiert und durch die Ressource aufgerufen.

2.8.2 Rekursive Aufrufe sind unzulässig Die IEC 61131-3 legt fest, dass sich POEs nicht selbst (auch nicht indirekt) aufrufen dürfen (sog. „Rekursion“), d.h. eine POE kann nicht eine POE-Instanz desselben Typs und/oder Namens aufrufen. Das hieße, dass eine POE „durch sich selbst“ definiert wird, wenn ihr Name innerhalb des eigenen Rumpfes deklariert bzw. aufgerufen wird. In manchen anderen Programmiersprachen der PC-Welt ist Rekursion allerdings üblicherweise möglich. Ließe man Rekursion zu, wäre eine Berechnung des zur Laufzeit maximalen Speicherbedarfs eines rekursiven SPS-Programms durch das Programmiersystem nicht mehr möglich. Rekursion kann immer durch entsprechende iterative Konstrukte, d.h. durch Bildung von Programmschleifen ersetzt werden. Die beiden folgenden Abbildungen geben zwei Beispiele für unzulässige Aufrufe:

FUNCTION Fun1: BOOL INT INT

Par1 Par2

BOOL

Fun1 Par1

Par1

Par2

Par2

END_FUNCTION

Fun1

FUNCTION Fun1 : BOOL VAR Par1, Par2 : INT; END_VAR

LD Par1 Fun1 Par2 ST Fun1

END_FUNCTION

Bsp. 2.18. Unzulässiger rekursiver Aufruf einer Funktion in grafischer und AWLDarstellung: Aufrufverschachtelung

In diesem Bsp. 2.18 wird innerhalb der Funktion Fun1 dieselbe Funktion nochmals aufgerufen. Der obere Teil dieser grafischen Darstellung beschreibt den Deklarationsteil der Funktion (Eingangsvariablen Par1 und Par2 vom Datentyp INT) sowie den Funktionswert vom Typ BOOL.

2.8 Aufrufe von Funktionen und Funktionsbausteinen

59

Im unteren Teil wird diese Funktion mit denselben Eingangsvariablen versorgt und aufgerufen, so dass sich zur Laufzeit der Funktion eine endlos tiefe (rekursive) Kette von Aufrufen bilden würde.

FUNCTION_BLOCK FunBst VAR_INPUT In1 : DINT; END_VAR VAR InstFunBst : FunBst; Var1 : DINT; END_VAR ... CALC InstFunBst (In1 := Var1); ... END_FUNCTION_BLOCK

(* Eingangsvariable *)

(* Instanz desselben FB-Typs unzulässig *) (* lokale Variable *)

(* rekursiver Aufruf unzulässig! *)

Bsp. 2.19. Unzulässiger rekursiver Aufruf eines Funktionsbausteins in AWL: Verschachtelung bereits im Deklarationsteil.

Bsp. 2.19 zeigt den Funktionsbaustein FunBst, in dessen lokaler Variablendeklaration (VAR) eine Instanz vom eigenen Typ (FunBst) deklariert wird. Im Programmrumpf wird diese Instanz aufgerufen, so dass sich eine endlos tiefe Verschachtelung bereits innerhalb des Deklarationsteils bei der Instanzbildung ergäbe und die zur Laufzeit benötigte Größe der Instanz nicht mehr bestimmt werden kann. Ob POEs im SPS-Programm durch (un)gewollte Programmierung nicht trotzdem rekursiv aufgerufen werden, muss der Programmierer selbst überprüfen oder sein Programmiersystem bzw. SPS-System vornehmen. Diese Prüfung kann bereits bei der Programmerstellung anhand des POEAufrufbaums durchgeführt werden, da das Verbot der Rekursion an die FB-Typen und nicht an deren Instanzen gebunden ist. Dies ist sogar dann möglich, wenn FBInstanznamen als Eingangsparameter übergeben werden (vgl. Abschn. 2.8.6). Das folgende Beispiel zeigt, wie rekursive Aufrufe auch ohne direkten Aufruf einer Funktion oder einer FB-Instanz von sich selbst entstehen können, indem sie sich wechselseitig aufrufen.

60

2 Bausteine der IEC 61131-3

FUNCTION Fun1:BOOL INT INT

Par1 Par2

BOOL

FUNCTION Fun2:BOOL INT INT

Fun2 Par1 Par2

Par1 Par2

Par1 Par2

BOOL

Fun1 Fun1

END_FUNCTION

Par1 Par2

Par1 Par2

Fun1

END_FUNCTION

Bsp. 2.20. Rekursion durch wechselseitigen Aufruf in grafischer Darstellung

Auch solche Arten der Rekursion sind in der IEC 61131-3 prinzipiell nicht zugelassen. Die Aufrufbedingung kann man wie folgt definieren: eine von einem Aufrufer A aufgerufene POE sowie sämtliche in der Aufrufhierarchie nach ihr stehenden POEs dürfen nicht den Namen des ersten Aufrufers A (FB-Instanz- oder Funktionsname) verwenden. Rekursion wird durch die IEC 61131-3 im Unterschied zu den meisten bekannten höheren Programmiersprachen (wie C) also generell verhindert. Dies macht SPS-Programme sicherer gegen Programmierfehler durch ungewollte Rekursion.

2.8.3 Erweiterbarkeit und Überladen Standardfunktionen wie Addition können mehr als zwei Eingangsparameter besitzen, was Erweiterung der Eingänge bezeichnet wird. Dies hilft in der Übersichtlichkeit mehrfacher Anwendung derselben Funktion. Eine Standardfunktion oder einen Standard-Funktionsbausteintyp bezeichnet man als überladen , wenn diese POEs mit Eingangsdatenelementen verschiedenen Datentyps arbeiten kann.Diese Konzepte werden in Abschn. 5.1.1 näher beschrieben.

2.8.4 Aufruf mit Formalparametern Beim FUN/FB-Aufruf werden Eingangsparameter an die Eingangsvariablen der POE übergeben. Diese Eingangsvariablen werden auch als Formalparameter bezeichnet, die Eingangsparameter auch als Aktualparameter, um auszudrücken, dass sie die aktuellen Eingangswerte beinhalten. Beim Aufruf einer POE können die Formalparameter ausdrücklich mit angegeben werden oder nicht. Diese Angabe ist sowohl abhängig vom POE-Typ (FUN oder

2.8 Aufrufe von Funktionen und Funktionsbausteinen

61

FB) als auch von der Programmiersprache, in der dieser POE-Aufruf definiert wird (vgl. a. Kap. 4). Tab. 2.7 gibt einen Überblick darüber, welche POE-Typen in textueller und grafischer Darstellung mit bzw. ohne Angabe von Formalparametern (das nennt man auch „nicht-formal“) aufgerufen werden können.

Sprache AWL ST KOP und FBS a b

Funktion ohne ohne oder mit b mit b

Funktionsbaustein mit a mit mit

Programm mit mit mit

auf drei verschiedene Arten möglich, vgl. Abschn. 4.1.4 bei Std.-FUN: soweit Parametername überhaupt vorhanden; EN steht ggfs. an erster Stelle.

Tab. 2.7. Mögliche explizite Angabe von Formalparametern („ohne“ bzw. „mit“) beim POE-Aufruf

Bei FBs und PROGs sind die Formalparameter immer, unabhängig von der Programmiersprache, ausdrücklich anzugeben. In AWL gibt es dazu verschiedene Möglichkeiten (siehe Abschn. 4.1.4). Funktionen können in ST wahlweise mit oder ohne Angabe der Formalparameter versorgt werden. Viele Formalparameter von Standard-Funktionen besitzen keinen Namen (vgl. Anh. A). Daher können diese in grafischer Darstellung nicht angezeigt und in textueller Darstellung nicht explizit angegeben werden. Die IEC 61131-3 gibt für den Aufruf benutzerdefinierter Funktionen in AWL nicht ausdrücklich an, ob Formalparameter angegeben werden dürfen. Damit solche Funktionsaufrufe konsistent zu den Aufrufen der Standardfunktionen bleiben, wird angenommen, dass der Name der Formalparameter bei Funktionsaufrufen in AWL prinzipiell nicht mit angegeben werden darf. Beim Aufruf von Standard-Funktionen und -Funktionsbausteinen gelten dieselben Regeln. Bsp. 2.21 zeigt Beispiele für jeden POE-Typ.

62

2 Bausteine der IEC 61131-3

FB-Deklaration:

FUN-Deklaration:

FUNCTION_BLOCK FBaust VAR_INPUT Par1 : TIME; Par2 : WORD; Par3 : INT; END_VAR

FUNCTION Funktion : INT VAR_INPUT Par1 : TIME; Par2 : WORD; Par3 : INT; END_VAR ... (* Anweisungen *) END_FUNCTION

... (* Anweisungen *) END_FUNCTION_BLOCK

PROG-Deklaration: PROGRAM Programm VAR_GLOBAL FunBst : FBaust; VarGlob: INT; END_VAR ... (* Anweisungen *) END_PROGRAM

(* 1. Aufrufe in AWL *) LD t#20:12 Funktion %IW4, VarGlob (* FUN-Aufruf *) CAL FunBst (Par1 := t#20:12, Par2 := %IW4, Par3 := VarGlob) (* FB-Aufruf *) (* 2. Aufrufe in ST *) Funktion (t#20:12, %IW4, VarGlob) (* FUN-Aufruf *) Funktion (Par1 := t#20:12, Par2 := %IW4, Par3 := VarGlob); (* FUN-Aufruf *) FunBst (Par1 := t#20:12, Par2 := %IW4, Par3 := VarGlob); (* FB-Aufruf *)

Bsp. 2.21. Äquivalente FUN- bzw. FB-Aufrufe mit und ohne explizite Angabe von Formalparametern in den textuellen Sprachen AWL und ST. Der Aufruf erfolgt jeweils in Programm.

In AWL wird der erste Eingangsparameter vor dem eigentlichen Aufruf als Aktuelles Ergebnis (AE) geladen, wie beim Aufruf der Funktion Funktion in Bsp. 2.21 zu sehen ist. Beim Funktionsaufruf werden die beiden anderen Parameter durch Kommata getrennt angegeben, sie können nicht zusätzlich mit der Angabe der Formalparameter versehen werden. Die beiden dazu äquivalenten Aufrufe in ST können mit oder ohne Angabe der Formalparameter erfolgen. Die Eingangsparameter werden jeweils in Klammern eingeschlossen. Der Aufruf der FB-Instanz FunBst erfolgt in diesem Beispiel sowohl in AWL als auch in ST mit vollständiger Angabe der drei Formalparameter. Die Benutzung von Formal- und Aktualparametern in grafischer Darstellung wird in Bsp. 3.19 dargestellt.

2.8 Aufrufe von Funktionen und Funktionsbausteinen

63

2.8.5 Aufrufe mit fehlenden oder vertauschten Eingangsparametern Funktionen und Funktionsbausteine können auch aufgerufen werden, wenn die Liste der Eingangsparameter nicht vollständig ist bzw. nicht jedem tatsächlich ein Wert zugewiesen wurde. Bei fehlenden Eingangsparametern müssen die Namen der tatsächlich benutzten Formalparameter explizit mit angegeben werden, damit das Programmiersystem die richtige Zuordnung von Aktual- und Formalparametern vornehmen kann. Auch wenn beim FUN/FB-Aufruf die Reihenfolge der Parameter geändert werden soll, ist die ausdrückliche Benennung der Formalparameter erforderlich. Diese Situationen werden in Bsp. 2.25 beispielhaft für AWL dargestellt.

(* 1. CAL

vollständiger FB-Aufruf *) FunBst (Par1 := t#20:12, Par2 := %IW4, Par3 := VarGlob);

(* 2. CAL

vollständiger FB-Aufruf mit vertauschten Parametern *) FunBst (Par2 := %IW4, Par1 := t#20:12, Par3 := VarGlob);

(* 3. CAL

unvollständiger FB-Aufruf *) FunBst (Par2 := %IW4);

(* 4. CAL

unvollständiger FB-Aufruf mit vertauschten Parametern *) FunBst (Par3 := VarGlob, Par1 := t#20:12);

Bsp. 2.22. Beispiele für FB-Aufruf aus Bsp. 2.21 mit fehlenden und vertauschten Parametern in AWL

Dies bedeutet, dass entweder sämtliche Formalparameter aufgeführt sein können, so dass die Parameter-Reihenfolge keine Rolle spielt, oder kein Formalparameter verwendet wird und die Reihenfolge zu beachten ist. Bei FB-Aufrufen sind Formalparameter immer anzugeben, für Funktionen ist dies sprachabhängig (vgl. Tab. 2.7). Für fehlende Zuweisungen an Eingangsvariablen gibt es die Möglichkeit, innerhalb des POE-Deklarationsteils Eingangsvariable zu „initialisieren“. Anstelle der fehlenden Aktualparameter wird dann standardmäßig der Anfangswert verwendet. Wird kein benutzerspezifischer Anfangswert angegeben, wird der Anfangswert der Standard-Datentypen der IEC 61131-3 verwendet, so dass Eingangsvariablen immer einen Wert besitzen. Für FBs erfolgt eine Initialisierung jeweils nur für den ersten Aufruf einer Instanz. Danach sind immer die Werte des letzten Aufrufs vorhanden, da die Instanzdaten (inkl. Eingangsvariablen) erhalten bleiben.

64

2 Bausteine der IEC 61131-3

2.8.6 FB-Instanzen als FB-Aktualparameter Dieser Abschnitt beschreibt die Verwendung von FB-Instanznamen sowie deren Ein- und Ausgänge als Aktualparameter beim Aufruf anderer Funktionsbausteine. Anhand des Bsp. 2.23 wird in diesem Abschnitt erläutert, welche Möglichkeiten in der IEC 61131-3 zur Verfügung stehen, indirekte Aufrufe oder Versorgung von FB-Instanzen vorzunehmen.

FUNCTION_BLOCK HauptFB VAR_IN_OUT Zeit1 : TON; Zeit2 : TON;

(* 1. Instanz von TON *) (* 2. Instanz von TON *)

InstFB : UnterFB;

(* Instanz von UnterFB *)

END_VAR ... CAL InstFB ( Timer := Zeit1, TimeQ := Zeit2.Q, TimeIN :=TRUE) ... LD InstFB.Zeit3.Q ... CAL Zeit1

(* FB-Aufruf der Instanz *) (* FB-Instanzname *) (* FB-Ausgang *) (* FB-Eingang *) (* Laden des FB-Ausgangs *) (* Aufruf der Zeitverzögerung *)

Bsp. 2.23. Übergabe von FB-Instanznamen Zeit1 und des Ausgangs Zeit2.Q als Aktualparameter eines anderen Funktionsbausteins. Die Zeiten Zeit1 und Zeit2 sind Instanzen des Standard-FB TON (Einschaltverzögerung, vgl. Kap. 5). UnterFB wird in Bsp. 2.24 deklariert.

Instanznamen bzw. Ein- und Ausgänge von Instanzen können als Aktualparameter für Eingangsvariable oder Ein-/Ausgangsvariable verwendet werden. Um diese Verwendungsmöglichkeiten zu beschreiben, unterscheidet Tab. 2.8 zwischen den zulässigen (in der Tabelle: „ja“) und unzulässigen Fällen („nein“).

2.8 Aufrufe von Funktionen und Funktionsbausteinen

Als Aktualparameter für UnterFB

a b c d

Instanz

Beispiel

VAR_INPUT

Instanzname -Eingang -Ausgang

Zeit1 Zeit2.IN Zeit2.Q

ja a ja

65

Rückgabewert, Externe Variable

VAR_IN_OUT (Zeiger) ja b

VAR_EXTERNAL VAR_OUTPUT ja c

nein d

-

Instanz kann in UnterFB nicht aufgerufen werden (kein indirekter FB-Aufruf möglich) Indirekter FB-Aufruf möglich, Instanz-Ausgang darf im UnterFB nicht verändert werden Direkter FB-Aufruf, Instanz-Ausgang darf im HauptFB nicht verändert werden Funktionswert einer Funktion ebenso nicht verwendbar

Tab. 2.8. Möglichkeiten, FB-Instanzen als FB-Aktualparameter zu verwenden bzw. indirekt aufzurufen. Die Spalte „Beispiel“ bezieht sich auf das Bsp. 2.23 Die letzte Spalte zeigt, dass FB-Instanzen auch als externe Variablen bzw. als Rückgabewerte verwendet werden können. Zeit2.IN darf nicht lesend verwendet und damit nicht als Parameter übergeben werden.

Wie aus dieser Übersicht hervorgeht, können nur einige Kombinationen verwendet werden, um Funktionsbausteinen in den verschiedenen Variablenarten Instanznamen oder deren Ein- und Ausgänge zu übergeben. VAR_INPUT: FB-Instanzen sowie ihre Ausgänge können im UnterFB nicht aufgerufen bzw. verändert werden, wenn sie als VAR_INPUT übergeben wurden. Auf sie kann allerdings lesend zugegriffen werden. VAR_IN_OUT: Die Übergabe eines Ausgangs einer FB-Instanz, dessen Zeiger übergeben werden würde, ist für diesen Variablenblock unzulässig. Dadurch wird eine versehentliche Änderung dieses Ausgangs verhindert. Dementsprechend ist auch eine Parametrierung einer VAR_IN_OUT-Variable mit dem Zeiger auf den Funktionswert einer Funktion nicht zulässig. Die übergebene Instanz kann aufgerufen werden, so dass ein indirekter FBAufruf realisiert werden kann. Ausgänge des übergebenen FB-Instanznamens dürfen nicht überschrieben werden. Auf FB-Instanz-Eingänge kann frei zugegriffen werden. VAR_EXTERNAL, VAR_OUTPUT: FB-Instanzen werden direkt aufgerufen, ihre Ein- und Ausgänge können von der aufrufenden POE nur lesend weiterverarbeitet werden. Beispiel für indirekten FB-Aufruf. Das Bsp. 2.24 zeigt (zusammen mit Bsp. 2.23) die Verwendung einiger in Tab. 2.8 zulässigen Fälle innerhalb des Funktionsbausteins UnterFB.

66

2 Bausteine der IEC 61131-3

FUNCTION_BLOCK UnterFB VAR_INPUT TimeIN : BOOL; (* boolesche Eingangsvariable *) TimeQ : BOOL; (* boolesche Eingangsvariable *) END_VAR VAR_IN_OUT Timer : TON; (* Zeiger auf Instanz Zeit1 von TON - Ein-/Ausgangsvariable *) END_VAR VAR_OUTPUT Zeit3 : TON; (* 3. Instanz von TON *) END_VAR VAR Start : BOOL := TRUE; (* lokale boolesche Variable *) END_VAR ... (* Indirekter Aufruf von Zeit1 mit Setzen/Abfragen der Aktualparameter über Timer *) LD Start ST Timer.IN (* Starten des Timers Zeit1 *) CAL Timer (* Indirekter Aufruf der Zeitverzögerung Zeit1 *) LD Timer.Q (* Abfrage des Ausgangs von Zeit1 *) ... (* Direkter Aufruf von Zeit3; indirekter Zugriff auf Zeit2 *) LD TimeIN (* indirekte Abfrage des Eingangs von Zeit2 nicht möglich *) ST Zeit3.IN (* Starten des Timers über Zeit3.IN *) CAL Zeit3 (* Direkter Aufruf der Zeitverzögerung Zeit3 *) LD Zeit3.Q (* Abfrage des Ausgangs über Zeit3.Q *) ... LD TimeQ (* indirekte Abfrage des Ausgangs von Zeit2 *) ... END_FUNCTION_BLOCK

Bsp. 2.24. Möglichkeiten des indirekten Aufrufs des Zeitverzögerung-FB Zeit1 aus Bsp. 2.23 sowie der Verwendung seiner Ein- und Ausgänge

Dieses Beispiel zeigt den indirekten Aufruf des FB Zeit1, dessen Instanzname dem Funktionsbaustein UnterFB in Bsp. 2.23 als Ein-/Ausgangsvariable übergeben wurde. Zur Übersichtlichkeit wurden die FB-Variablen in Bsp. 2.24 mit englischen Bezeichnungen versehen, um Verwechslungen zu Namen in Bsp. 2.23 zu vermeiden. Dem Funktionsbaustein UnterFB wird der FB-Instanzname Zeit1 erst zur Laufzeit von HauptFB übergeben. In UnterFB wird Zeit1 (als Eingangsvariable Timer) mit Parametern versorgt (Timer.IN) und anschließend aufgerufen.

2.8 Aufrufe von Funktionen und Funktionsbausteinen

67

Wie an Bsp. 2.24 dargestellt, ist es ebenfalls möglich, auf die Ein- und Ausgänge des als Instanzname übergebenen FBs zuzugreifen. Dabei können InstanzEingänge (Timer.IN) lesend und schreibend, -Ausgänge (Timer.Q) nur lesend verarbeitet werden. Die FB-Instanz Zeit3 dient in diesem Beispiel zum Vergleich der Behandlung von Eingangsparametern und Rückgabewerten eines FB als Ausgangsvariable. FB-Instanznamen als Aktualparameter von Funktionen. Instanznamen (wie Zeit1) bzw. Komponenten einer FB-Instanz (wie Zeit2.Q) können auch als Aktualparameter für Funktionen verwendet werden. Diese Tatsache klingt zunächst nach einem Widerspruch zur Forderung, dass Funktionen bei denselben Eingangsvariablen auch dasselbe Ergebnis liefern müssen und keine FBs aufrufen können. Dieser Widerspruch besteht nur scheinbar: die so übergebene FB-Instanz darf nicht aufgerufen werden, doch ihre Ein- und Ausgangsvariablen werden wie die Elemente einer gewöhnlichen Datenstruktur behandelt, siehe Abschn. 2.4.1. Funktionswerte als Aktualparameter. Funktionen bzw. ihre Funktionswerte können ebenfalls als Aktualparameter für Funktionen oder Funktionsbausteine verwendet werden. Die Eingangsvariablen besitzen denselben Datentyp wie die Funktion und bekommen den Funktionswert beim Aufruf zugewiesen. Über diese Möglichkeit macht die IEC 61131-3 allerdings keine expliziten Angaben, die Realisierung ist daher implementierungsabhängig. Initialisierung von FB-Instanzen. Instanzen von Funktionsbausteinen speichern den Zustand von Eingangs-, Ausgangs- und inneren Variablen, dies wurde „Gedächtnis genannt“. FB-Instanzen können auch initialisiert werden, wie Bsp. 2.25 zeigt.

VAR Instanz_Ex : FunBst (Par3 := 55.0, Par1 := t#20:12); END_VAR

Bsp. 2.25. Beispiele für FB-Aufruf aus Bsp. 2.21 mit fehlenden und vertauschten Parametern in AWL

68

2 Bausteine der IEC 61131-3

2.9 POE-Merkmalsübersicht Mit der folgenden Tabelle werden die in diesem Kapitel vorgestellten wesentlichen Eigenschaften der POEs im Überblick zusammengefasst.

Konzept Eingangsparameter Ausgangsparameter Ein-/Ausgangsparameter Funktionswert Aufruf von Funktionen Aufruf von Funktionsbausteinen Aufruf von Programmen Deklaration globaler Variablen Zugriff auf externe Variablen Deklaration Direkt dargestellter Variablen a Deklaration lokaler Variablen Deklaration einer FB-Instanz Überladbar b Erweiterbar c Flankenerkennung verwendbar Verwendung von EN/ENO Pufferung von lokalen und Ausgangs-Variablen Indirekter FB-Aufruf Initialisierung von FB-Instanzen Verwendung von Funktionswerten als Eingangsparameter d Verwendung von FB-Instanzen als Eingangsparameter Rekursiver Aufruf a b c d

Funktion ja ja ja ja ja nein nein nein nein nein

Funktionsbaustein ja ja ja nein ja ja nein nein ja nein

Programm ja ja ja nein ja ja nein ja ja ja

ja nein ja ja nein ja nein

ja ja ja nein ja ja ja

ja ja nein nein ja nein ja

nein nein ja

ja ja ja

ja nein ja

ja

ja

ja

nein

nein

nein

bei Funktionsbausteinen nur in VAR_EXTERNAL für Standard-Funktionen für Standard-Funktionen und Standard-Funktionsbausteine nicht in AWL, sonst: implementierungsabhängig

Tab. 2.9. POE- Merkmalsübersicht als Zusammenfassung wichtiger Ergebnisse dieses Kapitels. Die Einträge „ja“ und „nein“ bedeuten „zulässig“ bzw. „unzulässig“ für den entsprechenden POE-Typ.

3 Variablen, Datentypen und gemeinsame Elemente

In diesem Kapitel werden die grundlegenden, gemeinsamen Sprachelemente sämtlicher Programmiersprachen der IEC 61131-3 in Syntax und Semantik vorgestellt. Welche Sprachelemente die IEC 61131-3 für ihre Programmiersprachen zur Verfügung stellt, wie sie verwendet und miteinander kombiniert werden dürfen, wird durch die Syntax festgeschrieben, ihre Bedeutung wird durch die Semantik geregelt. Im ersten Abschnitt wird zunächst auf „Einfache Sprachelemente“ eingegangen, welche die Grundbausteine der Sprachen darstellen. Anschließend werden „Definition von Datentypen“ und „Deklaration von Variablen“ ausführlich erläutert.

3.1 Einfache Sprachelemente Jedes SPS-Programm besteht aus einer Anzahl von Grund-Sprachelementen als „kleinste Einheiten“, die aneinandergereiht Deklarationen bzw. Anweisungen und schließlich ganze Programme bilden. Diese sogenannten Einfachen Sprachelemente werden unterschieden in: -

Begrenzungszeichen, Schlüsselworte, Literale, Bezeichner.

70

3 Variablen, Datentypen und gemeinsame Elemente

Diese Einteilung wird anhand eines einfachen Beispiels gezeigt:

FUNCTION RealAdd : REAL VAR_INPUT Eing1, Eing2 : REAL; END_VAR RealAdd := Eing1 + Eing2 + 7.456E-3; END_FUNCTION

(* Funktionskopf *) (* Variablenart “Eingang“ *) (* Variablendeklaration *) (* Ende der Variablenart *) (* ST-Anweisung *) (* Ende der Funktion *)

Bsp. 3.1. Funktionsdeklaration mit „Einfachen Sprachelementen“ in ST. Schlüsselworte sind fett dargestellt, Bezeichner normal und das Literal kursiv. Begrenzungszeichen sind Doppelpunkt, Komma, runde Klammern, Stern, Gleich, Plus, Minus und Semikolon.

Die Funktion RealAdd beschreibt eine Funktion zur Gleitpunkt-Addition (REAL) zweier Eingangswerte Eing1, Eing2 und der festen Konstanten 7,456*10-3. Sie besteht aus einem Deklarationsteil (VAR_INPUT), der Namen und Typen der beiden Eingangsparameter festlegt, sowie einer einzigen Anweisungszeile (Addition) in der Sprache Strukturierter Text (ST). In Bsp. 3.1 sind die Schlüsselworte fett dargestellt. Es sind die von der IEC 61131-3 fest vorgegebenen Bezeichnungen, um Deklarationen und Anweisungen zu strukturieren. Sie bilden die elementaren „Worte“ der Programmiersprachen der IEC 61131-3. Die benutzerspezifischen Bezeichner sind normal dargestellt. Sie dienen dem SPS-Programmierer zur individuellen Bezeichnung von Variablen, Funktionsnamen etc. Das einzige hier verwendete Literal (hier „Zahlendarstellung“) ist kursiv geschrieben und bezeichnet eine Konstante in Gleitpunktdarstellung mit ExponentenAngabe. Mit Hilfe von Literalen werden die Werte der Datentypen dargestellt, beispielsweise Zahlen oder Zeichenfolgen. Die Begrenzungszeichen in Bsp. 3.1 sind die übrigen Sonderzeichen und Leerräume zwischen den genannten Elementen. Sie werden im Anhang H aufgelistet und hier nicht weiter behandelt.

3.1 Einfache Sprachelemente

71

Tab. 3.1 zeigt weitere Beispiele:

Sprachelement Begrenzungszeichen Schlüsselworte Literale Bezeichner

Bedeutung Sonderzeichen mit unterschiedlicher Bedeutung Standard-Bezeichner als „Worte“ der Programmiersprachen Werte-Darstellungen für verschiedene Datentypen Alphanumerische Zeichenfolgen für benutzerspezifische Namen von Variablen, Sprungmarken oder POEs usw.

Beispiele (,),+,-,*,$,;,:=,#, Leerzeichen RETAIN, VAR_INPUT, END_VAR, FUNCTION 62, 3.4509E-12, 16#a5 Var_1, Eing1, NotAus, REAL_OUT, RealAdd

Tab. 3.1. Beispiele für Einfache Sprachelemente

3.1.1 Reservierte Schlüsselworte Schlüsselworte sind Standard-Bezeichner, die durch die IEC 61131-3 in Schreibweise und Verwendungszweck eindeutig vorgegeben sind. Sie können daher nicht benutzerdefiniert für Variablen- oder sonstige Namen verwendet werden. Die Groß/Kleinschreibung ist für Schlüsselworte nicht signifikant, d.h. sie können beliebig klein, groß oder gemischt dargestellt werden. Zur besseren Unterscheidung werden die Schlüsselworte in diesem Buch generell in Großbuchstaben dargestellt. Zu fest vergebenen Reservierten Schlüsselworten zählen auch: -

Namen von Elementaren Datentypen, Namen von Standard-Funktionen (Std.-FUN), Namen von Standard-Funktionsbausteinen (Std.-FB), Namen von Eingangsparametern der Std.-FUN, Namen von Ein- und Ausgangsparametern der Std.-FB, Variablen EN und ENO in grafischen Programmiersprachen, Operatoren in der Sprache Anweisungsliste, Elemente der Sprache Strukturierter Text, Sprachelemente der Ablaufsprache.

Die in der IEC 61131-3 festgelegten Reservierten Schlüsselworte werden im Anhang H aufgelistet und hier nicht weiter behandelt.

72

3 Variablen, Datentypen und gemeinsame Elemente

3.2 Literale und Bezeichner

3.2.1 Literale Durch Literale wird die Schreibweise für Variablenwerte (Konstanten) festgelegt. Sie richtet sich nach den Datentypen dieser Variablen, die ihren Wertebereich bestimmen. Tab. 3.2 gibt einige typische Beispiele für Literale zur Zahlendarstellung. Dabei wird zwischen drei Grundtypen unterschieden: -

Numerische Literale (Zahlenwerte für Zahlen als Bitfolge sowie ganze und Gleitpunkt-Zahlen), Zeichenfolge-Literale (Werte von Zeichenfolgen – in Einzel- oder DoppelbyteDarstellung), Zeit-Literale (Werte für Zeitpunkt, Zeitdauer und Datum). Datentyp

Zahlendarstellung

Binär Boolesch Byte

0, 1 FALSE, TRUE 11, 16#0B, 2#0000_1011

Doppelwort

16#ABCDEF, 16#ab_cdef

Ganze Zahl mit Typangabe Gleitpunkt Gleitpunkt

75, +3829, -45 DINT#5, UINT#16#9AF, BOOL#0, BOOL#TRUE 567.82, -0.03 667E+4, -29E-16, 3e6

Zeichenfolge Zeichenfolge Zeichenfolge

'' 'dies ist ein Text' 'ÄË', '$C4$CB'

Doppelbyte“ÄË', '$00C4$00CB“ Zeichenfolge Mit Typangabe STRING# 'YES', WSTRING# 'YES'

Bemerkungen Zahlen als Bitfolge ein Bit boolesche Darstellung die Zahl 11 in dezimaler, hexadezimaler und dualer Darstellung hexadezimal die Zahl 11.259.375 Ganze und Gleitpunkt-Zahlen Integer, mit und ohne Vorzeichen mit und ohne Vorzeichen, auch boolesch Real Real mit Exponent Zeichenfolgen leere Zeichenfolge nicht-leere Folge: „dies ist ein Text“ Zwei identische Folgen mit Angabe der hexadezimalen Werte des ISO/IEC 10646-1 Zeichensatzes wie Einzelbyte-Zeichenfolgen, aber mit Doppel-Anführungszeichen drei Einzelbyte-Zeichen drei Doppelbyte-Zeichen

Tab. 3.2. Beispiele für Literale verschiedener Datentypen. Groß-/Kleinschreibung spielt ebenso wie bei Schlüsselworten keine Rolle (wird fortgesetzt).

3.2 Literale und Bezeichner

Datentyp

Zahlendarstellung

Zeitdauer

t#1d2h7m19s45.7ms time#2h_7m_19s TIME#-22s150ms

Datum Tageszeit

d#1994-09-23 tod#12:16:28.44

Datum und Zeit

dt#1994-09-23-12:16:28.44

73

Bemerkungen Zeitpunkt, Zeitdauer und Datum Angabe in Tagen(d), Stunden(h), Minuten(m), Sekunden(s) und Millisekunden(ms), auch negative Werte Angabe von Jahr-Monat-Tag Angaben in Stunden: Minuten:Sekunden.Hundertstel Datum und Tageszeit mit „-“ kombiniert

Tab. 3.2. (Fortsetzung)

Numerische und Zeit-Literale dürfen zusätzlich Unterstriche enthalten, um die Darstellung lesbarer zu gestalten. Groß-/Kleinschreibung spielt keine Rolle. Die höchstwertige Einheit in einem Zeitdauer-Literal darf „überlaufen“, z.B. ist der Zeitdauer-Wert t#127m_19s gültig und das Programmiersystem übernimmt die Umrechnung in die „richtige“ Darstellung t#2h_7m_19s. Während eine Zeitdauer zur Messung und Verarbeitung einer relativ verstrichenen Zeit dient, bilden die übrigen Zeitliterale absolute Tageszeit- und Datumsangaben. Literale für Zeiten und Datum können dabei in kurzer oder, zur besseren Lesbarkeit, auch in langer Schreibweise dargestellt werden. Folgende Darstellungen sind dabei pro Spalte in Tab. 3.3 äquivalent:

Zeitdauer TIME# T# time# t# Time#

Datum DATE# D# date# d# dATE#

Tageszeit TIME_OF_DAY# TOD# time_of_day# tod# Time_of_Day#

Datum und Zeit DATE_AND_TIME# DT# date_and_time# dt# dAtE_aNd_TiMe#

Tab. 3.3. Lange und kurze Schreibweisen des Präfix für Zeiten- und Datumsliterale

Zeichenfolge-Literale werden in einfachen Anführungszeichen geklammert dargestellt. Mit Hilfe des Dollar-Zeichens („$“) werden Sonderzeichen innerhalb der Zeichenfolge ermöglicht. Nicht-druckbare Sonderzeichen dienen zur Formatierung von Textausgaben auf Anzeigen oder Druckern.

74

3 Variablen, Datentypen und gemeinsame Elemente

Dollar- und Anführungszeichen selbst müssen daher ebenfalls mit einem vorangehenden weiteren „$“ gekennzeichnet werden. Tab. 3.4 zeigt diese Sonderzeichen-Regeln als Übersicht:

$-Kombination $nn $$ $', $“ $L, $l $N, $n $P, $p $R, $r $T, $t Beispiel: 'ein $'Stück$' kostet $$ 45'

auf Bildschirm bzw. Drucker Zeichen „nn“ in hexadezimaler Darstellung Dollar-Zeichen Einfaches und doppeltes Anführungszeichen Zeilenvorschub (line feed = $0A) Neue Zeile (new line) Neue Seite (new page) Wagenrücklauf (carriage return = $0D) Tabulator Zeichenfolge: „ein 'Stück' kostet $ 45“

Tab. 3.4. Verwendung des $-Sonderzeichens innerhalb Zeichenfolgen (STRING, WSTRING)

Die Zeichen unmittelbar nach einem Dollarzeichen können klein oder groß geschrieben werden.

3.2.2 Bezeichner Bezeichner sind alphanumerische Zeichenfolgen, mit deren Hilfe der SPSProgrammierer individuelle Namen für Variablen, Programme u.v.m. vergeben kann. Tab. 3.5 gibt die Sprachelemente der IEC 61131-3 an, für die Namen vergeben werden können.

Sprung- und Netzwerk-Marken Aufzählungskonstanten Konfigurationen, Ressourcen, Tasks/Laufzeitprogramme Programme, Funktionen, Funktionsbausteine Zugriffspfade Variablen (Allgemeine, Symbolische und Direkt dargestellte Variable) Abgeleitete Datentypen, Strukturkomponenten Transitionen, Schritte, Aktionsblöcke Tab. 3.5. Sprachelemente der IEC 61131-3, für die Bezeichner (Namen) vergeben werden können

3.2 Literale und Bezeichner

75

Bezeichner beginnen mit einem Buchstaben oder einem (einzelnen) Unterstrich, gefolgt von beliebig vielen Buchstaben, Ziffern und Unterstrichen. Auch bei Bezeichnern erfolgt keine Unterscheidung zwischen Klein- oder Großbuchstaben, d.h. die Variable „NOT_AUS“ ist identisch mit „Not_Aus“ oder „not_aus“. Das Programmiersystem ordnet diesen drei Bezeichnern denselben Speicherplatz zu. Die Länge von Bezeichnern ist lediglich durch die Fähigkeit des Programmiersystems beschränkt. Die ersten (mindestens) sechs Zeichen eines Bezeichners müssen nach IEC 61131-3 zur eindeutigen Unterscheidung ausgewertet werden, sie sind signifikant. Wenn ein Programmiersystem z.B. 16 Zeichen pro Bezeichner zulässt, muss der Programmierer dafür sorgen, dass sich diese Bezeichner mindestens in ihren ersten sechs Zeichen eindeutig unterscheiden: Die Variablenbezeichnungen _BOHRWERK_8 und _BOHRW werden in einem System mit sechs signifikanten Stellen als identisch betrachtet. Heutzutage sind 32 oder mehr signifikante Stellen durchaus üblich. Tab. 3.6 gibt einige Beispiele für gültige und ungültige Bezeichner.

Gültige Bezeichner MW2 VENTIL3X7, Ventil3x7 NOT_AUS, Not_Aus NOTAUS, NotAus _BOHRWERK_8, _bohrwerk_8 _BOHRWERK, _BOHRW _3ST91

Ungültige Bezeichner 2MW 3X7 Not Aus __BOHR _3ST9$1, _3ST9.1

Tab. 3.6. Beispiele für gültige und ungültige (durchgestrichen) Schreibweise von Bezeichnern

76

3 Variablen, Datentypen und gemeinsame Elemente

3.2.3 Kommentare Kommentare dürfen überall dort verwendet werden, wo auch Leerzeichen erlaubt sind, außer in Zeichenketten-Literalen. Sie werden durch die beiden Zeichen „Klammer auf“ und Stern “(*“ eingeleitet und symmetrsich mit “*)“ wieder abgeschlossen. Kommentare dürfen nicht geschachtelt werden und besitzen keinerlei syntaktische oder semantische Bedeutung für Deklarationen oder einer der durch die IEC 61131-3 definierten Sprachen.

3.2.4 Pragmas Die Norm erlaubt explizit die Verwendung sog. „Pragmas“, die typischerweise der automatischen Vor- oder Nachbearbeitung von Programmen dienen. Solche Elemente werden durch geschweifte Klammern angegeben und sind in Syntax und Semantik durch das Programmiersystem implementierungsabhängig. Daher werden sie nicht durch die Norm selbst definiert. Sie sind überall dort erlaubt, wo auch Kommentare verwendet werden dürfen.

{Author MT, Version D4.1} {n := 4}

Bsp. 3.2. Beispiele für Pragmas, die in der Norm selbst nicht definiert werden.

3.3 Bedeutung von Datentypen und Variablen

77

3.3 Bedeutung von Datentypen und Variablen Im Deklarationsteil einer POE werden ihre Variablen deklariert, d.h. mit ihren Eigenschaften bekanntgegeben (vgl. auch Abschn. 2.3.2 und Bsp. 2.10). Variablen-Deklarationen sind unabhängig von der gewählten Programmiersprache und daher einheitlich für das gesamte SPS-Projekt verwendbar. Deklarationen bestehen im Wesentlichen aus einem Bezeichner (Variablen-Namen) sowie der Angabe eines Datentyps. Typdefinitionen enthalten die anwendungsspezifischen (Abgeleiteten) Datentypen und gelten projektweit. Bevor die praktische Verwendung von Datentypen und Variablen näher erläutert (Abschn. 3.4 und 3.5) werden kann, wird zunächst beschrieben, welche Bedeutung diese beiden für die klassische SPS-Welt neuen Begriffe besitzen.

3.3.1 Von direkten SPS-Adressen über Symbole zu Variablen In der früher üblichen Programmierung (siehe DIN 19239) wird auf SPS-Speicheradressen direkt durch Angabe von „Operanden“ wie beispielsweise „M 3.1“ (Merkerbit 3.1) oder „EW 4“ (Eingangswort 4) zugegriffen. Diese Adressen können im Hauptspeicher der SPS-Zentraleinheit (CPU) bzw. in der SPSPeripherie (wie Ein- und Ausgänge der E/A-Peripherie) liegen. Adressen werden typischerweise als Bit, Byte, Wort oder Doppelwort angesprochen. Die über physikalische Adressen angesprochenen Speicherbereiche können im SPS-Programm zu unterschiedlichen Zwecken benutzt werden: als ganzzahliger oder BCD-Wert (z.B. BYTE oder WORD), als Gleitpunktzahl (z.B. REAL, LREAL) oder als Zeit- bzw. Zählwert (z.B. INT) usw., so dass das Speicherelement jeweils ein bestimmtes Datenformat (8-, 16-, 32-Bit) besitzt. Diese Datenformate sind im Allgemeinen untereinander inkompatibel, so dass sich der Programmierer merken muss, welche SPS-Adressen von seinem Programm in welchem Format benutzt werden dürfen. Dabei können fehlerhafte Programme entstehen, indem versehentlich eine falsche Speicheradresse angegeben wird (es stehen oft Adressräume von 16KB und mehr zur Verfügung) oder eine Adresse im falschen Datenformat benutzt wird. Für viele SPS-Systeme wurden deshalb zur besseren Lesbarkeit der SPS-Programme „Symbole“ eingeführt, die gleichwertig anstelle der absoluten SPSAdressen benutzt werden können: jede Adresse bekommt durch eine sogenannte Zuordnungs- oder Symbolliste einen eindeutigen symbolischen Namen zugeordnet. Diese Verwendung der symbolischen Darstellung als „Variablenersatz“ wird im linken Teil des Bsp. 3.2 gezeigt. Die IEC 61131-3 geht noch einen Schritt weiter: anstelle der Hardware-Adressen bzw. Symbole gibt sie die Verwendung von Variablen vor, wie sie in höheren Programmiersprachen üblich sind. Variablen sind vom Programmierer vergebene

78

3 Variablen, Datentypen und gemeinsame Elemente

Bezeichner (Namen), die als „Platzhalter“ die Datenwerte des Programms beinhalten. In Bsp. 3.2 werden den SPS-Adressen bzw. Symbolen auf der linken Seite die entsprechenden Deklarationen der IEC 61131-3 auf der rechten Seite gegenübergestellt.

PB 123:

PROGRAM ProgIEC

Zuordnungsliste (Symbolliste): E 3.4 = EingVar M 70.7 = MerkVar A 1.0 = AusgVar

VAR EingVar AT %IX 3.4 MerkVar AusgVar AT %QX 1.0 AT %MX 70.6 END_VAR

U U ON = ...

LD AND ORN ST ...

EingVar MerkVar M 70.6 AusgVar

: BOOL; : BOOL; : BOOL; : BOOL;

EingVar MerkVar %MX 70.6 AusgVar

Bsp. 3.3. Einführung der Begriffe „Variable“ und „Datentyp“ durch die IEC 61131-3. Links im einfach umrahmten Kasten die AWL-Darstellung nach DIN 19239, rechts analog nach IEC 61131-3.

Wie in Kap. 2 bereits beschrieben, wird jede Variable einer POE innerhalb eines Deklarationsblocks deklariert, d.h. mit ihren Eigenschaften vollständig beschrieben. In Bsp. 3.3 gibt es (auf der rechten Seite) die Variablenart VAR zur Deklaration lokaler Variable. Die dort gezeigte Verwendung des Schlüsselworts AT sowie die mit „%“ beginnenden Adressen werden näher in Abschn. 3.5.1 erläutert. Die Symbole bzw. Variablen EingVar und AusgVar des Bsp. 3.3 werden direkt als Hardware-Adressen „E 3.4“ und „A 1.0“ der SPS angesprochen. Die SPS-Adresse „M 70.6“ wird unmittelbar ohne Symbol- oder Variablen-Name verwendet. Sämtliche Adressen bzw. Variablen dieses Beispiels sind „boolesch“ (mit binären Werten 0 und 1). Dementsprechend wird auf der rechten Seite jeweils der Datentyp „BOOL“ (Abkürzung für engl.: boolean) angegeben. Die Variable MerkVar wird rechts ohne direkte Zuordnung zu einer SPSAdresse deklariert: diese Aufgabe übernimmt das Programmiersystem automatisch bei der Übersetzung des Programms, indem eine beliebige, noch freie Speicheradresse (wie z.B. M 70.7) ermittelt und zugeordnet wird.

3.3 Bedeutung von Datentypen und Variablen

79

3.3.2 Der Datentyp bestimmt Eigenschaften der Variablen Die IEC 61131-3 verwendet Variable nicht nur für SPS-Adressen, sondern einheitlich für sämtliche Anwender-Daten des SPS-Programms, d.h. insbesondere für Daten, die nicht an einem bestimmten Speicherplatz bzw. SPS-Adresse liegen müssen („Allgemeine“ Variable). Variable besitzen Eigenschaften, die durch den ihnen zugeordneten sogenannten Datentyp bestimmt werden. Während der Variablen-Name dem Speicherplatz einer Variable entspricht, gibt der Datentyp an, welche Werte die Variable annehmen kann. Datentypen legen Variablen-Eigenschaften wie Anfangswert, Wertebereich oder Anzahl der Bits (Datenbreite) fest. Eine Variable wird durch Zuordnung eines Datentyps zu einem Bezeichner (Variablen-Name) deklariert, d.h. der POE bzw. auch anderen POEs bekannt gemacht. In Bsp. 3.4 wird die Variable Start mit den Eigenschaften des Datentyps BYTE als lokale Variable deklariert. BYTE ist ein Standard-Datentyp („Elementarer Datentyp“) der IEC 61131-3, vgl. auch Anh. D. Eine mit BYTE deklarierte ganzzahlige Variable wie Start besitzt den Anfangswert 0, einen Wertebereich von 0 bis 255 und 8 Bits.

VAR Start : BYTE; END_VAR

(* Deklaration der Variable „Start“ mit Datentyp BYTE *)

Bsp. 3.4. Eine einfache Variablendeklaration, bestehend aus dem Bezeichner Start (Variablen-Name) und dem Doppelpunkt, gefolgt von der Angabe des Elementaren Datentyps BYTE. Sie wird mit einem Semikolon abgeschlossen.

Darüber hinaus hängen die Eigenschaften von Variablen von zusätzlichen Angaben bei ihrer Deklaration ab bzw. von Eigenschaften der Variablenart, in deren Block sie deklariert werden.

3.3.3 Typgerechte Verwendung von Variablen Beim Zugriff auf eine Variable kann das Programmiersystem die typgerechte Verwendung der Variablen überwachen, d.h. ob die Variable entsprechend ihrem Datentyp verarbeitet wird. Dies ist ein entscheidender Vorteil gegenüber früherer SPS-Programmierung, bei der solche Überprüfungen systemspezifisch nicht oder nur teilweise durchgeführt wurden. Diese Typüberprüfung wird durch das Programmiersystem bei der Übersetzung des SPS-Programms automatisch durchgeführt. Beispielsweise kann der Program-

80

3 Variablen, Datentypen und gemeinsame Elemente

mierer gewarnt werden, wenn eine Variable vom Typ BYTE (wie Start in Bsp. 3.4) einen Wert vom Typ REAL (Gleitpunktzahl) zugewiesen bekommt. Mit Hilfe der durch den Datentyp bestimmten Eigenschaften einer Variablen wird erreicht, dass Fehler durch falsche Verwendung des Datenformats (vgl. Abschn. 3.3.1) weitgehend vermieden werden können. Als weiteres Beispiel werden in Bsp. 3.5 Zählwerte als typischerweise Variablen vom Typ „Integer“ (Ganzzahl) mit oder ohne Vorzeichen deklariert.

ZaehlerRueckwaerts : ZaehlerVorwaerts :

INT; UINT;

(* Ganzzahl mit Vorzeichen *) (* Ganzzahl ohne Vorzeichen *)

Bsp. 3.5. Verwendung der vordefinierten Datentypen „Ganzzahl mit/ohne Vorzeichen“ (engl.: (un)signed integer) zur Deklaration von Zählvariablen

In Bsp. 3.5 werden den beiden Variablen ZaehlerVorwaerts und ZaehlerRückwaerts die Datentypen INT bzw. UINT zugeordnet. Dadurch ist eindeutig festgelegt, dass ZaehlerRückwaerts die Werte -32768 bis 32767 annehmen kann und ZaehlerVorwaerts den Wertebereich zwischen 0 und 65535 besitzt. Ein Programmiersystem gibt mindestens eine Warnung aus, wenn diese beiden Variablen beispielsweise durch Vergleich oder Addition miteinander verknüpft werden.

3.3.4 Automatische Abbildung von Variablen auf die SPS Für viele Variablen einer POE (temporäre Daten usw.) spielt es keine Rolle, in welchem SPS-Speicherbereich sie liegen, solange nur genug Speicherplatz vorhanden ist. Wie in Abschn. 3.3.1 bereits beschrieben, ist eine explizite „manuelle“ Speicheraufteilung bei früheren Programmiersystemen notwendig, wodurch vor allem bei komplexen Berechnungen bzw. großen Speicherbereichen Programmierfehler auftreten können. Durch das Variablenkonzept der IEC 61131-3 werden solche „Allgemeinen“ Variable, die bisher im globalen „Merkerbereich“ der SPS manuell verwaltet wurden, bei der Übersetzung eines Programms automatisch auf einen entsprechenden Speicherplatz der SPS abgebildet. Dabei muss sich der Programmierer nicht um die Zuordnung von Variablen zu physikalischen Adressen kümmern. Dies entspricht der Vorgehensweise von Compilern üblicher höherer Programmiersprachen. Allgemeine Variable wie MerkVar in Bsp. 3.3 oder die Variablen in Bsp. 3.4 und Bsp. 3.5 sind einfacher und sicherer zu handhaben als die direkte Verwendung von

3.4 Datentypen

81

Speicheradressen der SPS. Eine versehentliche Doppel- oder Fehlbelegung von Speicherbereichen durch den Programmierer wird automatisch ausgeschlossen.

3.4 Datentypen Frühere SPS-Programmiersprachen enthalten Datentypen wie Gleitpunktdarstellung, BCD-Codierung oder Zeit- und Zählerwerte, die oft völlig inkompatible Formate und Codierungen besitzen. Die Gleitpunktdarstellung beispielsweise, für die Schlüsselworte wie REAL, FLOAT etc. benutzt werden, wurde früher maschinenabhängig typischerweise durch 32 Bit breite Datenwörter implementiert, wobei zusätzlich unterschiedliche Wertebereiche für Mantisse und Exponent verwendet werden. Frühere Programmiersysteme besitzen meist auch eine einheitliche Verwendung von BIT, BYTE, WORD und DWORD. Doch bereits für einfache Integerwerte (Ganze Zahlen) gibt es feine, aber entscheidende Unterschiede (mit/ohne Vorzeichen, Anzahl Bits) zwischen den SPS-Systemen verschiedener Hersteller. Die Portierung von Programmen mit inkompatiblen Datentypen erfordert daher in den meisten Fällen größere Modifikationen und sind höchst fehleranfällig. Durch die IEC 61131-3 werden die bei der SPS-Programmierung gängigsten Datentypen vereinheitlicht, so dass deren Bedeutung und Verwendung eindeutig festgelegt sind. Dies ist besonders für diejenigen Maschinen- und Anlagenbauer oder Ingenieurbüros interessant, die mit mehreren SPS und Programmiersystemen unterschiedlicher Hersteller arbeiten. Einheitliche Datentypen bilden den ersten Schritt in Richtung portabler SPS-Programme.

3.4.1 Elementare Datentypen Die IEC 61131-3 bezeichnet eine Reihe vordefinierter, standardisierter Datentypen als Elementare Datentypen, die in Tab. 3.7 zusammengefasst sind, vgl. auch Anh. D.

82

3 Variablen, Datentypen und gemeinsame Elemente

Binär/Bitfolge

Ganzzahl mit Vorzeichen

Ganzzahl vorzeichenlos

Gleitpunkt

BOOL BYTE WORD DWORD LWORD

INT SINT DINT LINT

UINT USINT UDINT ULINT

REAL LREAL

Zeitpunkt, Zeitdauer, Datum und Zeichenfolge TIME DATE TIME_OF_DAY DATE_AND_TIME STRING, WSTRING

Bedeutung der Anfangsbuchstaben: D = double, L = long, S = short, U = unsigned

Tab. 3.7. Die Elementaren Datentypen der IEC 61131-3. Ihre Bezeichnungen sind Reservierte Schlüsselworte.

Die Elementaren Datentypen werden durch ihre Datenbreite (Anzahl der Bits) sowie durch ihren möglichen Wertebereich charakterisiert. Beide Größen werden von der IEC fest vorgegeben. Ausnahmen bilden Datenbreite und Wertebereich von Datum, Uhrzeit und String-Datentypen, die implementierungsabhängig realisiert werden können. In der Norm sind weder BCD-Datentypen noch Zähler-Datentypen festgelegt. BCD-Codierung besitzt heutzutage nicht mehr die Bedeutung wie früher und ist daher in einem SPS-System für Spezialzwecke individuell festzulegen. Zählwerte werden durch normale ganze Zahlen realisiert, ein spezielles Format wird zumindest für die Zähler-Standard-FBs der IEC 61131-3 nicht benötigt. In Anh. D sind sämtliche Datentypen mit ihren Eigenschaften (Wertebereich, Anfangswerte) aufgelistet. Beispiele zu Datentypen wurden bereits in Tab. 3.2 gezeigt.

3.4.2 Abgeleitete Datentypen (Typdefinition) Auf der Basis der Elementaren Datentypen kann sich der SPS-Programmierer eigene, „benutzerdefinierte“ Datentypen erstellen. Dieses Verfahren wird als Ableitung oder Typdefinition bezeichnet. Dadurch kann der Programmierer das für seine Aufgabenstellung günstigste Datenmodell realisieren. Solche Typdefinitionen werden global für ein SPS-Projekt vereinbart. Die mit neuem Namen definierten Datentypen heißen Abgeleitete Datentypen und werden wie die Elementaren Datentypen für Variablendeklarationen benutzt. Für Typdefinitionen ist die textuelle Darstellung zu verwenden, eine grafische ist durch die IEC 61131-3 nicht vorgesehen. Typdefinitionen werden wie in Bsp. 3.6 durch die Schlüsselworte TYPE ... END_TYPE geklammert.

3.4 Datentypen

TYPE LangGleitZahl Fliesskomma InitGleitZahl tSteuer END_TYPE

: : : :

LREAL; LangGleitZahl; LREAL := 1.0; BOOL := TRUE;

83

(* direkte Ableitung von IEC-Datentyp *) (* direkte Ableitung eines Anwender-Datentyps*) (* Ableitung mit neuem Anfangswert *) (* Ableitung mit neuem Anfangswert *)

Bsp. 3.6. Beispiel für einfache Typdefinitionen: „Direkte Ableitung“ eines Datentyps

In Bsp. 3.6 wird der neue Datentyp LangGleitZahl als Alternative für den Standard-Datentyp LREAL definiert. Nach dieser Vereinbarung können LangGleitZahl und LREAL gleichwertig zur Variablendeklaration benutzt werden. Wie das Beispiel zeigt, kann ein abgeleiteter Datentyp wiederum als Basis für eine weitere Ableitung dienen. Daher ist Fliesskomma ebenfalls gleichwertig mit LREAL. Der abgeleitete Datentyp InitGleitzahl besitzt einen gegenüber LREAL geänderten Anfangswert, 1.0 statt 0.0, ebenso wie tSteuer TRUE gegenüber Standard-Anfangswert FALSE. Typdefinitionen werden benötigt, um neue Datentypen mit erweiterten oder geänderten Eigenschaften zu erzeugen, wobei diese bei wiederholter Anwendung „weitervererbt“ werden. Durch die Verwendung von anwendungsbezogenen Datentypen kann eine zu programmierende Aufgabe effektiver implementiert werden. Anwender wie SPSHersteller können individuelle Datentypen entwerfen bzw. vordefinieren: -

vom Standard abweichende Anfangswerte, Datentypen für Bereich und Aufzählung, mehrdimensionale Felder, komplexe Datenstrukturen.

Diese miteinander kombinierbaren Möglichkeiten werden von der IEC 61131-3 unterstützt und im Folgenden weiter erläutert. Zusätzliche Eigenschaften für Elementare Datentypen. Einem Elementaren Datentyp können folgende zusätzliche Eigenschaften wie in Tab. 3.8 zugeordnet werden.

84

3 Variablen, Datentypen und gemeinsame Elemente

Eigenschaft Anfangswert Aufzählung

Bez.a initial enum

Bereichsangabe

range

Feldgrenzen

array

Datenstruktur

structure

a

Bedeutung Die Variable erhält einen spezifischen Anfangswert. Die Variable kann einen in einer Namensliste angegebenen Namen als Wert annehmen. Die Variable kann Werte annehmen, die innerhalb des angegebenen Bereichs liegen. Mehrere Elemente desselben Datentyps werden zu einem Feld zusammengefasst. Beim Zugriff auf die Feldvariable darf der maximal zulässige Index nicht überschritten werden. Mehrere Datentypen werden zu einem Datentyp kombiniert. Der Zugriff auf eine Strukturvariable erfolgt durch Angabe eines Punkts und Angabe der Strukturkomponente.

englische Bezeichnung

Tab. 3.8. Zusätzliche Eigenschaften für Elementare Datentypen

Die Eigenschaften Feldgrenzen und Datenstruktur können auch für bereits abgeleitete Datentypen, also „geschachtelt“ angewendet werden. Mehrfache Feldgrenzen eines Datentyps bilden einen mehrdimensionalen Feldtyp. Ein Wertebereich ist in der IEC 61131-3 nur für den Elementaren Datentyp Integer (ganze Zahlen) bzw. dessen direkten Ableitungen vorgesehen. Eine Ausdehnung auf weitere Datentypen ist (implementierungsabhängig) denkbar. Ein Aufzählungstyp stellt im eigentlichen Sinn keine Ableitung dar, da er offensichtlich von keinem Elementaren Datentyp „abgeleitet“ wird. Er wird in der IEC 61131-3 dennoch als solcher bezeichnet, denn zu seiner Realisierung setzt das Programmiersystem typischerweise ganze Zahlen ein, woraus sich die Vorstellung der Ableitung ergibt.

3.4 Datentypen

TYPE Farbtyp : (rot, gelb, gruen); Sensor : INT (-56..128); Messung : ARRAY [1..45] OF Sensor; Pruefstand : STRUCT Platz : UINT; Ampel : Farbtyp := rot; Mess1 : Messung; Mess2 : Messung; Mess3 : Messung; END_STRUCT; END_TYPE

85

(* Aufzaehlung *) (* Bereichsangabe *) (* Feldgrenzen *) (* Datenstruktur *) (* Elementarer Datentyp *) (* Aufzaehlungstyp mit Anfangswert *) (* Feldtyp *) (* Feldtyp *) (* Feldtyp *)

Bsp. 3.7. Beispiele für Elementare Datentypen mit zusätzlichen Eigenschaften als abgeleitete Datentypen

Die Beispiele in Bsp. 3.7 zeigen die Verwendung dieser Zusatzeigenschaften: Farbtyp kann der Wertebereich für eine Ampel mit drei Farben sein, Sensor enthält einen zulässigen Temperaturbereich und das Feld Messung ist für 45 Einzelwerte von Messungen geeignet. Pruefstand ist eine Datenstruktur, gebildet aus elementaren sowie bereits abgeleiteten Datentypen. Die Einhaltung der Eigenschaften in Tab. 3.8 für Wertebereich und Feldindex kann sowohl statisch (vom Programmiersystem) als auch dynamisch (zur Laufzeit) überwacht werden. Diese Zuweisung von Eigenschaften verbessert sowohl das Erkennung von Programmierfehlern bei der Programmerstellung und zur Laufzeit (sicherere Programme) als auch die Dokumentation. Die in runden Klammern eingeschlossenen Elemente beim Aufzählungstyp werden vom Programmierer namentlich angegeben, ohne dass weitere Angaben notwendig wären. Man kann sie daher als „Text-Konstanten“ verstehen. Das Programmiersystem setzt beispielsweise die drei Werte rot, gelb und gruen automatisch in geeignete Codierungen um. Meist erfolgt intern eine Abbildung auf ganzzahlige Werte, z.B. beginnend mit „1“, was für den Programmierer allerdings nicht sichtbar wird. Die Namen der Farbwerte können im Programm unmittelbar wie Konstanten verwendet werden. In Bsp. 3.7 erhält die Variable Ampel den Anfangswert „rot“. Die Verwendung von Aufzählungstypen vereinfacht die automatische Überprüfbarkeit durch das Programmiersystem. Außerdem werden die Programme besser lesbar. Falls für einen Datentyp ein Wertebereich wie für Sensor in Bsp. 3.7 festgelegt wird, erfolgt eine Fehlermeldung, wenn dieser Bereich bei der Programmierung oder zur Laufzeit unter- oder überschritten wird.

86

3 Variablen, Datentypen und gemeinsame Elemente

Wertebereiche können auch in CASE-Anweisungen der Sprache ST benutzt werden, um wertebereichsabhängige Aufgaben auszuführen, vgl. Abschn. 4.2.6. Felder. Felder sind im Speicher unmittelbar aufeinanderfolgende Datenelemente vom gleichen Datentyp. Auf ein Feldelement kann mit Hilfe eines Feldindex innerhalb der Feldgrenzen zugegriffen werden. Der Index gibt über seinen Wert an, welches Feldelement angesprochen werden soll. Dieser Sachverhalt wird durch Abb. 3.1 veranschaulicht. Leistungsfähige SPS-Systeme stellen sicher, dass bei Feld-Zugriffen mit einem Feldindex außerhalb der Feldgrenzen zur Laufzeit eine Fehlermeldung erfolgt.

Feld

Feldindex

0 1 2 3 . . .

Feldelement mit Feldindex 2

Elementare oder Abgeleitete Datentypen

Abb. 3.1. Veranschaulichung der Elemente eines eindimensionalen Felds (ARRAY)

Das in Abb. 3.1 gezeigte Feld ist eindimensional, d.h. besitzt genau einen Feldgrenzen-Bereich. Ebenso können durch Angabe weiterer, durch Kommata getrennte Feldgrenzen mehrdimensionale Felder gebildet werden, wie es Bsp. 3.8 zeigt. In diesem Fall liegen die Elemente dimensionsweise im Speicher hintereinander, wobei die weiter rechts angegebenen Feldgrenzen jeweils zusammenliegen. D.h. von rechts nach links werden höherwertige Dimensionen angegeben.

TYPE Mess_1Dim : ARRAY [1..45] OF Sensor; Mess_2Dim : ARRAY [1..10,1..45] OF Sensor; END_TYPE

(* 1-dimensionales Feld *) (* 2-dimensionales Feld *)

Bsp. 3.8. Typdefinitionen eines eindimensionalen und eines 2-dimensionalen Felds für die Aufnahme einer (Mess_1Dim) bzw. von zehn (Mess_2Dim) Messreihen.

3.4 Datentypen

87

Felder von FB-Instanznamen sind in der IEC 61131-3 nicht erlaubt, doch wäre dies eine sinnvolle Erweiterung der Norm, um z.B. leichter auf gleichartig vorkommende Zeiten und Zähler zugreifen zu können. Neben der Definition von Feldern als Datentyp können Felder auch direkt mit der Variablendeklaration vereinbart werden. Dies wird in Abschn. 3.5 erläutert. Dort werden Beispiele zur praktischen Benutzung für Variablen mit diesen Datentypen angegeben. Datenstrukturen. Mit Hilfe der Schlüsselworte STRUCT und END_STRUCT können – wie von höheren Programmiersprachen her bekannt (z.B. struct { } in der Sprache C) – hierarchisch Datenstrukturen aufgebaut werden, die beliebige Elementare oder bereits Abgeleitete Datentypen als Unterelemente enthalten dürfen. FB-Instanznamen sind in Datenstrukturen nicht erlaubt, was nur als Erweiterung gegenüber IEC 61131-3 möglich wäre. Ist ein Unterelement wiederum eine Struktur, entsteht eine Strukturhierarchie, wie in Abb. 3.2 verdeutlicht, deren unterste Strukturebene Elementare oder Abgeleitete Datentypen bilden.

Struktur

Unterstrukturen

Elementare oder Abgeleitete Datentypen

Komplexität der Datentypen

Abb. 3.2. Veranschaulichung des Aufbaus einer Struktur (STRUCT). Sie setzt sich aus (mehrfach) Abgeleiteten und Elementaren Datentypen zusammen. Die Komplexität der Datentypen steigt von rechts nach links.

Damit kann der SPS-Programmierer seine Datenstrukturen optimal an die Aufgabenstellung anpassen. In Bsp. 3.9 wird die Struktur MotorZustand definiert, die den realen Betriebszustand eines geregelten Motors widerspiegeln könnte. Zur Definition wurden Elementare Datentypen (davon Drehzahl mit Bereichsangabe) sowie ein Aufzählungstyp (Stufe) verwendet.

88

3 Variablen, Datentypen und gemeinsame Elemente

TYPE BegrenzDrehz : TypStufe : MotorZustand : STRUCT Drehzahl : Stufe : MaxErreicht : Stoerung : Bremse : END_STRUCT; END_TYPE

UINT (0..230); (Leerlauf, Beschl1, Beschl2, MaxLeistung);

BegrenzDrehz; TypStufe; BOOL; BOOL; BYTE;

(* Bereichsangabe *) (* Aufzählung *) (* Elementarer Datentyp *) (* Elementarer Datentyp *) (* Elementarer Datentyp *)

Bsp. 3.9. Typdefinition einer komplexen Struktur als abgeleiteter Datentyp auf der Basis von Elementaren Datentypen sowie Bereichsangabe und Aufzählung

Mit Hilfe des neuen Datentyps MotorZustand können entsprechende Variablen deklariert werden. Um beispielsweise mehrere Motoren desselben Typs zu beschreiben, kann ein Feld (als Variable oder wiederum als Datentyp) gebildet werden, das aus Elementen vom Typ MotorZustand besteht:

TYPE MehrMotZustand : ARRAY [1..4] OF MotorZustand;(* weitere Ableitung *) END_TYPE VAR (* Fall 1: *) Motor1 : (* Fall 2: *) Motoren : (* Fall 3: *) VierMotoren : END_VAR

MotorZustand;

(* Deklaration *)

ARRAY [1..4] OF MotorZustand;

(* Felddeklaration *)

MehrMotZustand;

(* Deklaration *)

Bsp. 3.10. Verwendung eines abgeleiteten Datentyps zur weiteren Ableitung (oben) bzw. Felddeklaration (unten)

Wie Bsp. 3.10 zeigt, kann eine Festlegung von vier Elementen vom Typ MotorZustand mit Hilfe einer Variablendeklaration erfolgen: Motoren hat vier Elemente (Fall 2). Eine Alternative dazu bildet Fall 3: hier wird der Datentyp MehrMotZustand definiert, der für jede Variable (wie VierMotoren) ein gleich großes Feld von vier Elementen des Weiteren Abgeleiteten Datentyps MotorZustand bereithält. Die Ableitung von Datentypen ist prinzipiell schachtelbar, d.h. von abgeleiteten Datentypen können wiederum weitere abgeleitet werden. Allerdings wird die Schachtelung unzulässig, wenn sie Rückbezüge enthält. Dies kann vorkommen,

3.4 Datentypen

89

wenn eine frühere Ableitung einen übergeordneten Namen (versehentlich) bereits enthält, der Datentyp also „durch sich selbst“ definiert wird. Eine solche unzulässige Schachtelung zeigt Bsp. 3.11.

TYPE StrukturA : STRUCT Element1 : INT; Element2 : StrukturB; (* zulässig: Unterstruktur *) Element3 : BYTE; END_STRUCT; StrukturB : STRUCT Element1 : LINT; Element2 : StrukturA; (* unzulässig: Rückbezug auf StrukturA *) Element3 : WORD; END_STRUCT; END_TYPE

Bsp. 3.11. Unzulässige Schachtelung bei der Ableitung von Datentypen: StrukturA wird in einer Unterstruktur verwendet, die sie selbst enthält (Rekursive Typdefinition).

In Abschn. 3.5 werden weitere Beispiele zur praktischen Benutzung entsprechender Variablen angegeben. Anfangswerte bei Typdefinition. Bereits im Datentyp kann der Programmierer Anfangswerte vergeben, die bei der entsprechenden Variablendeklaration automatisch eingesetzt werden. Falls bei der Variablendeklaration wie in Bsp. 3.6 ausdrücklich andere Werte (auch für einzelne Strukturelemente) als die Standard-Anfangswerte der IEC 61131-3 angegeben werden, wird das Programmiersystem jene vorrangig einsetzen. In Anh. D werden die Anfangswerte für die Datentypen der IEC 61131-3 mit angegeben.

90

3 Variablen, Datentypen und gemeinsame Elemente

TYPE MotorZustand : STRUCT Drehzahl : Stufe : MaxErreicht : Stoerung : Bremse : END_STRUCT; END_TYPE

BegrenzDrehz := 0; TypStufe := Leerlauf; BOOL := FALSE; BOOL := FALSE; BYTE := 16#FF;

Bsp. 3.12. Typdefinition der Struktur von Bsp. 3.9 mit Zuweisung von Anfangswerten (fett dargestellt)

In Bsp 3.12 werden die Strukturelemente des Abgeleiteten Datentyps MotorZustand aus Bsp 3.9 mit Anfangswerten versehen. Für Anfangswerte von Feldern können Werte-Reihen mit einem Faktor vor Klammerung einer Unterreihe abgekürzt werden. Beim Datentyp STRING kann ein initiale Zeichenfolge in einfachen Anführungszeichen angegeben werden.

VAR Feld1 : ARRAY [1..12] OF SINT := [3,16#FF,-5,-9,-5,-9,-5,-9,-5,-9,0,0]; Feld2 : ARRAY [1..12] OF SINT := [3,16#FF, 4(-5,-9), 2(0)]; Text : STRING [4] := 'Stop'; END_VAR

Bsp. 3.13. Beispiel für die Initialisierung von Feld-Variablen und Zeichenfolgen

In Bsp. 3.13 werden die beiden Felder Feld1 und Feld2 mit denselben Anfangswerten vorbesetzt. Dabei wird für Feld2 die abgekürzte Form mit Wiederholungszahlen vor den Unterreihen (-5,-9) und (0) verwendet.

3.4.3 Allgemeine Datentypen Die IEC 61131-3 definiert sogenannte Allgemeine Datentypen, um die Elementaren Datentypen zu einzelnen Gruppen hierarchisch zusammenzufassen. Diese Datentypen beginnen mit dem Kürzel ANY; z.B. werden alle ganzzahligen Datentypen (Integer, INT) als ANY_INT bezeichnet. Viele Standard-Funktionen der IEC 61131-3 können auf mehr als einen Datentyp angewendet werden. So kann beispielsweise die Addition (ADD) mit

3.4 Datentypen

91

sämtlichen Arten ganzer Zahlen (INT) durchgeführt werden, d.h. ADD unterstützt den Allgemeinen Datentyp ANY_INT. Mit Hilfe Allgemeiner Datentypen werden solche Standard-Funktionen beschrieben, um anzugeben, für welche ihrer Eingangs- oder Ausgangs-Variablen mehrere Datentypen zugelassen sind. Dieses Konzept heißt Überladen von Funktionen und wird in Abschn. 5.1.1 beschrieben. Tab. 3.9 zeigt, wie Elementare Datentypen Allgemeinen Datentypen zugeordnet werden. Der Datentyp ANY bildet die hier weitestmögliche Verallgemeinerung eines Datentyps.

ANY_DERIVED ANY_ELEMENTARY ANY_BIT

ANY_MAGNITUDE

BOOL BYTE WORD DWORD LWORD

ANY_MAGNITUDE ANY_NUM ANY_INT ANY_REAL INT UINT REAL SINT USINT LREAL DINT UDINT LINT ULINT

ANY_DATE

ANY_STRING

DATE TIME_OF_DAY DATE_AND_TIME

STRING WSTRING

TIME

Tab. 3.9. Übersicht über die Allgemeinen Datentypen ANY

Unterstützt die Standard-Funktion Multiplikation (MUL) beispielsweise den Allgemeinen Datentyp ANY_NUM, so lässt das Programmiersystem sämtliche Datentypen für MUL zu, die die Datentypen ANY_INT und ANY_REAL umfassen: alle ganzen Zahlen mit und ohne Vorzeichen sowie Gleitpunktzahlen. Auch die benutzerdefinierten (abgeleiteten) Datentypen werden unter dem Typ ANY erfasst. Für direkt abgeleitete Datentypen ist der Allgemeine Datentyp einer Variable derselbe wie der des abgeleiteten Datentyps. In Bsp. 3.6 besitzen die beiden Datentypen LangGleitZahl und Fliesskomma denselben Datentyp LREAL. Allgemeine Datentypen dienen zur Erläuterung der Aufrufschnittstelle von (Standard-) Funktionen und gehören zu den Reservierten Schlüsselworten. Ihre Verwendung in benutzerdefinierten POEs wie zur Variablendeklaration ist unzulässig bzw. nicht Gegenstand der Norm.

92

3 Variablen, Datentypen und gemeinsame Elemente

3.5 Variable Wie bereits in Abschn. 3.3 beschrieben, werden Variablen als Platzhalter für anwendungsspezifische Datenbereiche unter Angabe eines Datentyps deklariert. Ihre Eigenschaften sind bei der Deklaration bestimmbar durch: -

Eigenschaften des angegebenen (Elementaren oder Abgeleiteten) Datentyps, Angabe von zusätzlichen Anfangswerten, Angabe von zusätzlichen Feldgrenzen (Felddefinition), Variablenart des Deklarationsblocks der Variable (mit Attribut).

Die wichtigsten Elemente einer Variablendeklaration werden in Bsp. 3.14 exemplarisch zugeordnet:

Variablenart VAR_OUTPUT GepufferteVar

Attribut

RETAIN :

BYTE

Variablen-Name

:=

Datentyp

61;

Anfangswert

END_VAR

Ende der Variablenart Bsp. 3.14. Elemente einer Variablen-Deklaration mit Anfangswert-Zuweisung

In diesem Beispiel wird die Variable GepufferteVar vom Datentyp BYTE mit Anfangswert 61 deklariert. Durch die Angabe des Attributs RETAIN wird sie im batteriegepufferten Speicher der SPS abgelegt. Die Deklaration eines Instanznamens für Funktionsbausteine bildet einen Sonderfall der Variablendeklaration: Ein FB-Instanzname wird wie eine Variable deklariert mit dem Unterschied, dass anstelle des Datentyps der FB-Name angegeben wird, wie in Abschn. 2.4.1 bereits beschrieben wurde. Wie bei Typdefinitionen können Anfangswerte und Felder auch bei Deklaration vereinbart werden, indem anstelle des Datentyps eine „namenlose“ Typdefinition angegeben wird (vgl. Beispiele in Abschn. 3.5.2). Für die Eigenschaften Aufzählung, Wertebereich und Datenstruktur ist dies von der IEC 61131-3 nicht vorgesehen.

3.5 Variable

93

3.5.1 Eingänge, Ausgänge und Merker als besondere Variablen Die in der SPS-Welt bekannten Begriffe wie Eingänge, Ausgänge oder Merker werden in dem Variablenkonzept der IEC besonders behandelt. Dies wurde bereits in Abschn. 3.3.1 einleitend dargestellt. Damit der SPS-Programmierer im Programm Datenbereiche des SPS-Systems, d.h. der Prozessoren und ihrer Peripherie-Module direkt ansprechen kann, bietet die IEC 61131-3: -

Direkt dargestellte Variable, Symbolische Variable.

Bei der Deklaration solcher Variablen wird der physikalische Speicherort (SPSAdresse, z.B. der E/A-Peripherie) mit dem Schlüsselwort AT angegeben. Der Aufbau der Adressangabe ist Tab. 3.10 zu entnehmen. Diese direkten SPSAdressen werden auch Hierarchische Adressen genannt. Sie beginnen mit einem „%“, gefolgt von einem Buchstaben I (Eingang), Q (Ausgang) oder M (Merker). Daran schließt sich ein weiterer Buchstabe an, der die Datenbreite der SPS-Adresse festlegt. „X“ (Bitadresse) kann dabei auch weggelassen werden.

Direkte SPS-Adressen % I Q M kein

X B W D L * v.w.x.y.z

Erläuterungen einleitendes Zeichen Eingang Ausgang Merker Bit Bit (optional) Byte Wort Doppelwort Langwort (noch) nicht spezifizierter Speicherort mehrstellige hierarchische Adresse, von rechts nach links höherwertig. Anzahl und Interpretation der Stellen sind herstellerabhängig, z.B.: z - Bit, y - Wort, x - Modul, w- Bus, v – SPS

Tab. 3.10. Aufbau der direkten SPS-Adressen mit Beispielen. Sie werden zur Deklaration von „Direkt dargestellten“ und „Symbolischen“ Variablen benutzt. (wird fortgesetzt)

94

% % % % % % %

3 Variablen, Datentypen und gemeinsame Elemente

I Q M M I Q Q

W D X B *

7 3.1 5.2.0 5.2.0 80 4

Beispiele Eingangswort 7 Ausgangsdoppelwort 1 im Modul 3 Merkerbit 0 im Wort 2 des Moduls 5 Merkerbit 0 im Wort 2 des Moduls 5 Eingangsbit 80 Ausgangsbyte 4 Ausgang an einem noch nicht festgelegten Speicherort

Tab. 3.10. (Fortsetzung)

Bei Direkt dargestellten Variablen wird ein Datentyp (siehe Bsp. 3.15) einer Hierarchischen Adresse zugeordnet. Die Deklaration Symbolischer Variablen enthält außerdem einen Variablennamen, mit dem „symbolisch“ auf den gewünschten Eingang, Ausgang oder Merker zugegriffen werden kann.

VAR (* Direkt dargestellte Variable *) AT %IW6 : WORD; (* Eingangswort ab Adresse 6 *) AT %QD3 : DINT; (* Ausgangsdoppelwort ab Adresse 3 *) (* Symbolische Variable *) OUT_HG AT %QW7: WORD; (* Ausgangswort 7 *) AD_3 AT %QD3: DINT; (* Ausgangsdoppelwortmerker *) C2 AT %Q*: BYTE; (* Zuweisung C2 zum Ausgangs-Speicherort*) END_VAR ... LD %IW6 (* Verwendung Direkt dargestellter Variable *) ST OUT_HG (* Verwendung Symbolischer Variable *) ...

Bsp. 3.15. Beispiele für Direkt dargestellte und Symbolische Variable und deren Verwendung in AWL mit Hilfe Hierarchischer Adressen

Durch die Zuordnung eines Datentyps zu einer Merker- oder Peripherie-Adresse kann das Programmiersystem kontrollieren, ob die Zugriffe auf die Variable korrekt sind: beispielsweise kann auf eine mit „AT %QD3 : DINT;“ deklarierte Variable nicht versehentlich mit UINT oder REAL zugegriffen werden. Direkt dargestellte Variablen ersetzen die bisher oft direkt im Programm verwendeten SPS-Adressen (wie z.B. E 1.2). Bei ihnen dient die Adressangabe gleichzeitig als Variablenname (wie %IW6 in Bsp. 3.15). Symbolische Variablen werden wie gewöhnliche Variablen deklariert und verwendet mit dem Unterschied, dass ihr Speicherort vom Programmiersystem nicht frei vergeben werden darf, sondern durch die Angabe von „AT“ eine Adresse vom Benutzer vorgegeben wird (wie OUT_HG in Bsp. 3.15). Diese Variablen

3.5 Variable

95

entsprechen Adressen, denen bisher über eine Zuordnungsliste symbolische Namen zugeordnet wurden. Bei der Verwendung eines Sterns („Asterisk“) in Programmen und FB zur Kennzeichnung noch nicht genau spezifizierter Speicherorte erfordert diese Festlegung in Konfigurationen mit Hilfe VAR_CONFIG … END_VAR, vgl. auch Kap. 6. Direkt dargestellte und Symbolische Variablen dürfen für die Variablenarten VAR, VAR_GLOBAL, VAR_EXTERNAL und VAR_ACCESS von Programmen, Ressourcen und Konfigurationen deklariert werden. In Funktionsbausteinen können sie nur innerhalb von VAR_EXTERNAL importiert werden.

3.5.2 Multielement-Variable: Felder und Strukturen Die IEC 61131-3 bezeichnet Felder und Strukturen als Multielement-Variablen. Dementsprechend werden einfache Variablen als Einzelelement-Variable bezeichnet. Während in Abschn. 3.4.2 bereits die Typdefinitionen der MultielementVariablen erläutert wurden, wird im Folgenden deren Benutzung beschrieben. Bsp. 3.16 zeigt solche Felder und Strukturvariablen, welche die Typdefinitionen von Bsp. 3.9 und Bsp. 3.10 verwenden.

TYPE BandZustand : STRUCT Laeuft : BOOL; Antrieb : MehrMotZustand; END_STRUCT; END_TYPE VAR Eingabe AT %IB0 : ARRAY [0..4] OF BYTE; Index : UINT := 5; Motor1 : MotorZustand; VierMotoren : MehrMotZustand; MotorFeld : ARRAY [0..3, 0..9] OF MotorZustand; Band : ARRAY [0..2] OF BandZustand; END_VAR

Bsp. 3.16. Beispiele für Deklarationen von Multielement-Variablen

Auf Datenelemente eines Feldes wird zugegriffen, indem das Feldelement mit Hilfe eines ganzzahligen Feldindex (z.B. Index) in eckigen Klammern ausgewählt wird. Strukturelemente werden über den Variablennamen der Struktur, gefolgt von einem Punkt und dem Namen der Strukturkomponente, angesprochen. Tab. 3.11 zeigt Zugriffsbeispiele auf Einzelelement-Variable und MultielementVariablen aus Bsp. 3.16:

96

3 Variablen, Datentypen und gemeinsame Elemente

Zugriff auf Feldelemente

Bemerkungen

Eingabe [0] VierMotoren [Index] MotorFeld [Index, 2]

erstes Eingabefeld die 4. Struktur, falls Index gleich 4 ist die 34. Struktur MotorZustand, falls Index gleich 3 ist

Zugriff auf Strukturelemente Motor1.Drehzahl VierMotoren [1].Drehzahl MotorFeld [Index, 2].Stufe Band[1].Antrieb[1].Drehzahl

Komponente Drehzahl Komponente Drehzahl der 2. Struktur

Tab. 3.11. Beispiele für die Benutzung der Multielement-Variablen der Bsp. 3.16, 3.9 und 3.10 mit Zugriffen auf Felder und Strukturen

In Bsp. 3.10 wurde ein Feld innerhalb eines Datentyps definiert. Wie Bsp. 3.16 anhand Eingabe oder des zweidimensionalen Feld MotorFeld zeigt, kann bei einer Variablendeklaration ebenfalls eine Felddefinition angegeben werden. Das Anlegen von Feldern ist allerdings weder für Aufzählungstyp und Bereichsangabe noch für Datenstrukturen in der IEC 61131-3 vorgesehen, wäre allerdings eine für die Programmierung hilfreiche Erweiterung der Norm. Wie Tab. 3.11 zeigt, können die Zugriffe mit Feldindex und Punkt für komplexe Variablen mit Unterstrukturen geschachtelt angewendet werden, wie bei der Variablen Band gezeigt. Die Definition von Anfangswerten bei Variablendeklaration erfolgt für einfache und Multielement-Variablen nach denselben Regeln, wie sie in Bsp 3.12 und Bsp. 3.13 innerhalb Typdefinitionen gezeigt wurden.

3.5.3 Zuweisung von Anfangswerten bei Programmstart Variablen werden beim Start der Ressource oder Konfiguration (vgl. Kap. 6) mit Anfangswerten besetzt. Diese Anfangswerte sind davon abhängig, welche Angaben der SPS-Programmierer im entsprechenden Deklarationsteil für die Variable bzw. zu dem dazugehörigen Datentyp machte. Da Elementare Datentypen vordefinierte Anfangswerte besitzen (und damit auch abgeleitete), ist sichergestellt, dass jede Variable definierte Anfangswerte besitzt. Eine Variable kann Anfangswerte nach den in Tab. 3.12 aufgeführten Regeln annehmen, deren tatsächlich verwendbarer Umfang ist allerdings typischerweise abhängig von der Implementierung des Programmiersystems.

3.5 Variable

Vorgabe batteriegepuffert durch RETAIN

Prior.a 1

Anfangswert bei Deklaration

2

Anfangswert bei Datentyp

3

a

Programmstart Warmstart: Restaurierung der zuletzt zugewiesenen Werte bei Spannungswiederkehr oder nach Halt (Wiederanlauf). Kaltstart: Anfangswerte für einen definierten Neustart des Programms, wie nach dem Laden.

97

Bemerkungen

Diese Werte werden bei der Variablendeklaration angegeben. Elementare Datentypen werden mit 0 für numerische Werte und Zeiten, 01-01-01 für Datum und der leeren Zeichenfolge für Strings initialisiert. Für Abgeleitete Datentypen können bei der Typdefinition individuelle Anfangswerte verwendet werden.

Priorität: 1=höchste Priorität, 3= niedrigste Priorität

Tab. 3.12. Vergabe von Anfangswerten nach Prioritäten bei Warmstart und bei Kaltstart. Die linke Spalte gibt die drei Möglichkeiten an, nach denen Variablen Anfangswerte zugewiesen bekommen.

Werden mehrere Möglichkeiten zur Vergabe von Anfangswerten von Variablen gleichzeitig benutzt, gilt bei Warm- bzw. Kaltstart diejenige mit der höheren Priorität. Ein gepufferter Wert hat bei Warmstart Vorrang gegenüber den Anfangswerten bei Variablendeklaration oder Typdefinition. Der Anfangswert des Datentyps wird nur dann verwendet, wenn in der Deklaration weder eine Batteriepufferung noch ein Anfangswert angegeben ist. Falls ein SPS-Programm durch einen Warmstart (bei Spannungswiederkehr) angestoßen wird, nehmen seine gepufferten Variablen wieder die Werte an, die sie vor der Unterbrechung besaßen. Dieses Verhalten wird auch als Wiederanlauf bezeichnet. Nach einem Kaltstart (nach Laden des Programms in die SPS oder nach einem Halt durch Fehler oder Anwender) werden die Variablen auf die Anfangswerte gesetzt, die bei der Definition des Datentyps (vordefiniert bzw. benutzerdefiniert) oder der Variablendeklaration (benutzerdefiniert) verwendet wurden (Neustart). Die Ein- und Ausgänge eines SPS-Systems (E/A-Peripherie) sowie sonstige Speicherbereiche werden implementierungsspezifisch initialisiert. Anfangswerte sind bei jeder Variablenart bis auf VAR_IN_OUT und VAR_EXTERNAL zulässig. Externe Variablen werden dort initialisiert, wo sie als

98

3 Variablen, Datentypen und gemeinsame Elemente

global deklariert werden – im dazugehörigen VAR_GLOBAL. Bei VAR_IN_OUT wird keine Initialisierung zugelassen, da diese Variablenart Zeiger auf Variablen und nicht die Variablen selbst beinhaltet.

3.5.4 Attribute der Variablenarten Die IEC 61131-3 definiert Attribute, mit denen Variablen weitere Eigenschaften zugeordnet werden können: -

RETAIN NON_RETAIN CONSTANT R_EDGE F_EDGE READ_ONLY READ_WRITE

(Batterie-) gepuffert nicht (Batterie-) gepuffert Konstante steigende Flanke fallende Flanke schreibgeschützt schreib- und lesbar

Die Attribute RETAIN, NON_RETAIN und CONSTANT werden in der IEC 61131-3 Bestimmungszeichen1 genannt und unmittelbar hinter dem Schlüsselwort der Variablenart angegeben. Daher beziehen sich diese drei Attribute jeweils auf den gesamten Abschnitt der Variablendeklaration (bis END_VAR). Die vier anderen Attribute werden individuell für einzelne Variablendeklarationen vergeben, können jedoch nicht mit den drei Bestimmungszeichen kombiniert werden. Tab. 3.13 zeigt, für welche Variablenarten diese Attribute zulässig sind:

Variablenart

RETAIN NON_RETAIN VAR ja VAR_INPUT ja VAR_OUTPUT ja VAR_IN_OUT nein VAR_EXTERNAL nein VAR_GLOBAL ja VAR_ACCESS nein VAR_TEMP nein VAR_CONFIG nein

CONSTANT ja nein nein nein ja ja nein ja nein

R_EDGE, F_EDGE nein ja nein nein nein nein nein ja nein

READ_ONLY, READ_WRITE nein nein nein nein nein nein ja nein nein

Tab. 3.13. Verwendung von Attributen für Variablenarten

1

nicht zu verwechseln mit den Bestimmungszeichen der Aktionsblöcke in Ablaufsprache!

3.5 Variable

99

Mit RETAIN werden Variablen gekennzeichnet, deren Werte (über Batterie bzw. Akku) gepuffert werden sollen, also bei Spannungsunterbrechung erhalten bleiben müssen. NON_RETAIN bewirkt das Gegenteil, wenn man ausdrücklich möchte, dass Variablen nicht durch Pufferung erhalten bleiben sollen. Sind Variablen weder mit RETAIN noch mit NON_RETAIN gekennzeichnet, ist ihr Zustand nach Spannungsunterbrechung implementierungsabhängig, siehe auch Tab. 3.12. Die Attribute RETAIN bzw. NON_RETAIN sind für VAR, VAR_INPUT, VAR_OUTPUT und VAR_GLOBAL erlaubt und ebenfalls sinnvoll, um Variablen in einer Instanz von FBs oder PROGs oder um Instanzen strukturierter Variablentypen zu puffern. Die Anwendung auf einzelne Elemente von Strukturen ist dagegen unzulässig. Mit CONSTANT werden „Variablen“ beschrieben, deren Werte während des Programmablaufs nicht verändert werden dürfen, also schreibgeschützte Konstanten (und keine Variablen im eigentlichen Sinne) darstellen. Das Bestimmungszeichen CONSTANT ist für die Variablenarten VAR, VAR_EXTERNAL und VAR_GLOBAL zugelassen. Zu beachten ist hier, dass als global deklarierte Konstanten auch bei externer Verwendung als Konstanten deklariert sein müssen. Die gleichzeitige Verwendung von RETAIN und CONSTANT macht keinen Sinn und wird durch die IEC 61131-3 nicht zugelassen, denn Konstante müssen nach einem Stromausfall in der SPS auf jeden Fall (statisch) restauriert werden, also auch ohne die Angabe von RETAIN. Das Attribut R_EDGE bzw. F_EDGE kennzeichnet boolesche Variable, die steigende bzw. fallende Flanken erkennen können. Sie sind von der IEC 61131-3 ausschließlich für die Variablenart VAR_INPUT zugelassen. Es ist denkbar, diesen Mechanismus auch auf die Variablenarten VAR und VAR_GLOBAL auszudehnen. Flankenerkennung erfolgt implizit durch Standard-FBs der IEC 61131-3 und wird in Abschn. 5.2 näher beschrieben.

VAR_OUTPUT RETAIN GepufferteVar : BYTE; END_VAR VAR CONSTANT Konstante : BYTE := 16#FF; END_VAR VAR_INPUT FallendeFlanke : BOOL F_EDGE; END_VAR VAR_ACCESS BandLeer : CPU_BAND.%IX1.0 : BOOL READ_ONLY; END_VAR

Bsp. 3.17. Beispiele für die Verwendung von Attributen (fett dargestellt) bei Variablenarten

100

3 Variablen, Datentypen und gemeinsame Elemente

Die Attribute READ_ONLY und READ_WRITE sind ausschließlich der Variablenart VAR_ACCESS vorbehalten, vgl. dazu Kap. 6. VAR_ACCESS lässt auf Konfigurationsebene keine Bestimmungszeichen zu.

3.5.5 Grafische Darstellung von Variablen-Deklarationen Der Deklarationsteil von POEs kann – ebenso wie der Anweisungsteil – sowohl in grafischer als auch in textueller Form programmiert werden. Die grafische Darstellung dient der anschaulichen Visualisierung der Aufrufschnittstelle und der Rückgabewerte der POE mit ihren Ein- und Ausgangsvariablen. Die durch die IEC 61131-3 vorgegebenen grafischen Möglichkeiten reichen für einfache Variablendeklarationen der POE-Schnittstelle aus, doch für Angaben wie Felddeklarationen, Batteriepufferung oder Anfangswerte muss auf die textuelle Darstellung zurückgegriffen werden. Tab. 3.14 zeigt, welche Variablenarten und Attribute einer POE zusätzlich zur textuellen Darstellung auch grafisch darstellbar (und damit deklarierbar) sind:

grafisch darstellbar Variablenarten VAR VAR_INPUT VAR_IN_OUT VAR_OUTPUT VAR_EXTERNAL VAR_GLOBAL VAR_ACCESS Attribute bei Variablenarten RETAIN, NON_RETAIN CONSTANT R_EDGE, F_EDGE READ_ONLY, READ_WRITE a

nein ja ja ja nein nein nein nein nein jaa nein

nur für Variablenart VAR_INPUT vorgesehen

Tab. 3.14. Grafische Darstellbarkeit für Variablenarten und deren Attribute

Bsp. 3.18 zeigt einen Deklarationsteil in grafischer Darstellung mit einigen in dieser Tabelle angegebenen Möglichkeiten sowie der textuellen Entsprechung. Die grafische Umsetzung der Bestimmungszeichen RETAIN und CONSTANT ist ebenso wie die übrigen Attribute in der IEC 61131-3 nicht vorgesehen. Dies

3.5 Variable

101

könnte für ein Programmiersystem zusätzlich realisiert werden. Ebenso wäre eine grafische Darstellung für sämtliche Variablenarten denkbar. Wie Bsp. 3.18 verdeutlicht, visualisiert die grafische Darstellung von Deklarationen die Aufrufschnittstelle (Formalparameter) und Rückgabewerte der POEs.

BOOL BOOL BOOL BOOL

Ein EinAus Ein1 Ein2

VAR_INPUT Ein : BOOL; Ein1 : BOOL R_EDGE; Ein2 : BOOL F_EDGE; END_VAR EinAus

BOOL

Aus

BOOL

VAR_OUTPUT Aus : BOOL; END_VAR VAR_IN_OUT EinAus : BOOL; END_VAR

Bsp. 3.18. Grafische und textuelle Darstellung des Deklarationteils. Die Flankenerkennung wird durch „>“ und „<“ symbolisiert, VAR_IN_OUT mit einer durchgehenden Linie.

Der Aufruf einer POE kann ebenfalls grafisch dargestellt werden, dabei werden die Formalparameter mit Aktualparametern belegt und die Rückgabewerte weiterverarbeitet. Dadurch ergibt sich eine bei Deklaration und Aufruf einheitliche grafische Sicht auf eine POE, wie es in Bsp. 3.19 für den Funktionsbaustein EA_Bsp dargestellt wird.

102

3 Variablen, Datentypen und gemeinsame Elemente

FUNCTION_BLOCK EA_Bsp

InstanzName EA_Bsp

INT

Ein1

Aus1

BYTE

BOOL

Ein2

Aus2

BYTE

Formalparameter

Rückgabewerte

Zaehl

Ein1

Aus1

Ergebnis1

NotAus

Ein2

Aus2

Ergebnis2

Aktualparameter

Weiterverarbeitung

END_FUNCTION_BLOCK

Bsp. 3.19. Formalparameter und Rückgabewerte bei der FB-Deklaration (links) und Versorgung mit Aktualparametern beim FB-Aufruf sowie Weiterverarbeitung der Ergebnisse (rechts).

Zur Beschreibung von Formalparametern und Rückgabewerten siehe auch Abschn. 2.3.2.

4 Die Programmiersprachen der IEC 61131-3

Um ein Anwenderprogramm zu formulieren, stehen in der IEC 61131-3 drei textuelle Sprachen: -

Anweisungsliste AWL, Strukturierter Text ST, Ablaufsprache AS (textuelle Variante)

und drei grafische Sprachen zur Verfügung: -

Kontaktplan KOP, Funktionsbausteinsprache FBS, Ablaufsprache AS (grafische Variante).

Der Anweisungsteil der textuellen Sprachen besteht aus einer Aneinanderreihung von Anweisungen. Eine Anweisung in ST, einer Hochsprache, setzt sich aus Anweisungen zum Programmablauf und sogenannten Ausdrücken zusammen, die wiederum aus Operatoren/ Funktionen und Operanden bestehen. In AWL beschreibt ein Operator oder eine Funktion mit den jeweiligen Operanden (Parametern) eine Anweisung. Die grafischen Sprachen benutzen grafische Elemente, über die das gewünschte Verhalten der SPS formuliert wird. Verbindungslinien oder sogenannte Konnektoren kennzeichnen den Wertefluss zwischen Funktionen und Funktionsbausteinen. In den folgenden Abschnitten wird für jede Sprache der grundsätzliche Aufbau der Sprach- bzw. Grafik-Konstrukte vorgestellt, dann die einzelnen Teile erläutert und schließlich an einem größeren Beispiel (POE in der entsprechenden Sprache) präsentiert.

104

4 Die Programmiersprachen der IEC 61131-3

4.1 Anweisungsliste AWL Anweisungsliste AWL ist eine maschinennahe Programmiersprache, vergleichbar mit einem komfortablen Assembler. Sie ist universell einsetzbar und wird häufig als gemeinsame Zwischensprache verwendet, auf welche die übrigen textuellen und grafischen Sprachen abgebildet werden.

4.1.1 Anweisung in AWL AWL ist eine zeilenorientierte Sprache. Eine Anweisung, d.h. eine Ausführungsanweisung an die SPS, wird in genau einer Zeile beschrieben. Leere Anweisungen in Form von Leerzeilen sind ebenfalls erlaubt. Eine Anweisung in AWL besteht aus den in Abb. 4.1 dargestellten Elementen:

Sprungmarke :

Operator/Funktion Operand(enliste)

Keine, eine oder mehrere Konstanten oder Variablen für den Operator oder Eingangsparameter für eine Funktion, durch Kommata getrennt AWL-Operator oder Funktionsname Begrenzungszeichen Sprungmarke, um diese Anweisungszeile zu erreichen; kann auch (zusammen mit dem Doppelpunkt) entfallen

Abb. 4.1. Anweisung in AWL; zwischen Operator und Operand muss mindestens ein Leerzeichen zur Trennung stehen. Kommentar mit (* ... *) Klammerung ist an allen Stellen, an denen ein Leerzeichen stehen kann, erlaubt.

MLauf:

LD AND ST CALC JMPCN

Marke

%IX3.0 (* Lade Bit aus Peripherieanschluß *) (* Maskiere mit Variable: Freigabe *) Timer_1 PLauf (* Speichere den Wert ab: Prozeß starten *) (* Leeranweisung *) Prozess (* FB Prozess aufrufen, wenn PLauf = TRUE *) MLauf (* Springe, wenn PLauf = FALSE *)

Operator/ Funktion

Operand

Bsp. 4.1. Verschiedene AWL-Anweisungen

Kommentar

4.1 Anweisungsliste AWL

105

Die Sprungmarke und der Kommentar einer AWL-Zeile können entfallen. Seit der Ed 2 [DIN EN 61131-3] darf Kommentar nicht nur am Ende der Zeile, sondern auch, wie bei den restlichen Sprachen, an allen Stellen eingefügt werden, an denen ein Leerzeichen stehen kann. Die Konvention, den Kommentar nur am Zeilenende zu schreiben, erhöht allerdings die Übersichtlichkeit und wird deshalb im Buch weiter verwendet. Sprungmarken werden dann angegeben, wenn diese Anweisungszeile von einer anderen Programmzeile angesprungen werden soll. Die alleinige Angabe einer Sprungmarke in einer Zeile ist erlaubt; es kommen die nachfolgenden Zeilen zur Ausführung. Die einzelnen Operatoren/Funktionen beschreiben die gewünschte Operation; sie sind in Abschn. 4.1.3 und 4.1.4 zusammengestellt. Die Operanden und Eingangsparameter sind dem Kap. 3 bzw. Anh. A und B zu entnehmen. Kommentare werden durchgängig in allen Sprachen mit (* ... *) geklammert. Hiermit erfolgt eine informelle Kommentierung der Zeile. Es gibt keinerlei Spaltenformatierung; die Operatoren und Operanden aus Bsp. 4.1 können beispielsweise nur durch ein Leerzeichen getrennt sein oder die Operatoren in der ersten Spalte stehen. Bemerkung: Der Strichpunkt ”;” ist in AWL nicht erlaubt, weder als Kommentaranfangszeichen (wie oft in Assemblersprachen) noch als Endekennung einer Anweisung (wie in ST).

4.1.2 Der universelle Akkumulator Übliche Assemblersprachen gehen meist von einem physikalisch vorhandenen Akkumulator im Prozessor aus; d.h. es wird ein Wert in diesen Akkumulator geladen, weitere Werte dazuaddiert, subtrahiert, ... und anschließend abgespeichert. AWL kennt ebenfalls einen solchen Akkumulator mit Namen ”Aktuelles Ergebnis (AE)”1. Es handelt sich aber um keinen Speicherbereich mit fest definierten Registerlängen. Der AWL-Compiler sorgt vielmehr dafür, dass abhängig von dem zu bearbeitenden Datentyp ein abstrakter Akkumulator (einschließlich Akkumulator-Keller) beliebiger Speicherbreite zur Verfügung steht. In Abweichung zu anderen Assemblersprachen gibt es keine speziellen Prozessor-Statusbits. Das Ergebnis von Vergleichen wird als boolesche 0 (FALSE) oder 1 (TRUE) in diesen Akkumulator AE geschrieben; nachfolgende bedingte

1

Englisch: CURRENT RESULT. Im bisherigen SPS-Sprachgebrauch oft als VKE (Verknüpfungsergebnis) bezeichnet

106

4 Die Programmiersprachen der IEC 61131-3

Sprünge und Aufrufe werten das aktuelle AE zur Bestimmung der Sprungvoraussetzung aus.

VAR ErstOperand, ZweitOperand, Ergebnis: INT := 10; StringOp: String[30] := ‘12345678901234567890’; StringErg: String[25]; END_VAR ... B1: LD ErstOperand (* 10 {INT} *) ADD ZweitOperand (* 20 {INT} *) ST Ergebnis (* 20 {INT} *) GT 0 (* TRUE, da 20 > 0 {BOOL} *) JMPC B2 (* springe, da AE=TRUE; alter Wert AE bleibt {BOOL} *) JMP WeitWeg (* AE undefiniert o. alter Wert AE bleibt; impl.abhängig *) B2: LD StringOp (* 12345678901234567890 {STRING} *) ST StringErg (* 12345678901234567890 {STRING} *)

Bsp. 4.2. Akkumulator-Modell von AWL. Im Kommentar ist jeweils der Wert des ”aktuellen Ergebnisses (AE)” sowie der Datentyp {} nach Ausführung der Anweisung festgehalten.

Ein AE kann vom Typ -

Allgemeiner Datentyp, Abgeleiteter Datentyp (Struktur, Feld, Aufzählungstyp, ...), Funktionsbaustein (-typ)

sein. Die Datenbreite des AE (Anzahl der Bits) spielt dabei keine Rolle, wie man an der Zeichenketten-Operation in Bsp. 4.2 sieht. AWL schreibt vor, dass zwei aufeinanderfolgende Operationen typverträglich sein müssen; d.h. der Datentyp des aktuellen AE muss mit der nachfolgenden Anweisung verträglich sein. Ein ADD-Operator mit einem INT-Operanden benötigt wie in Bsp. 4.3 einen Wert vom gleichen Typ im AE (von der Vorgängeranweisung), mit dem die Verknüpfung erfolgen kann.

4.1 Anweisungsliste AWL

107

VAR_INPUT ErstOperand: INT; END_VAR VAR ZweitOperand, DrittOperand: INT := 10; WordVar: WORD; END_VAR LD 1 (* 1 {INT} *) ADD ErstOperand (* 11 {INT} *) ST ZweitOperand (* 11 {INT} *) LT DrittOperand (* FALSE {BOOL} *) AND WordVar (* Fehler: Typ ist vom Typ WORD, nicht BOOL wie AE *) ...

Bsp. 4.3. AWL-Programm mit Fehler: Der Datentyp im AE (BOOL) entspricht nicht dem von AND WordVar geforderten Typ (WORD).

Wie aus Bsp. 4.2 und 4.3 zu ersehen ist, gibt es Operatoren, die ein AE unterschiedlich beeinflussen.

Einfluss der Operator- Kurzform gruppe auf das AE erzeugen E weiterverarbeiten W unverändert lassen U undefiniert setzen -

Beispieloperatoren LD GT ST; JMPC Unbedingter Bausteinaufruf CAL (die nachfolgende Anweisung muss das AE neu laden, da es nach der FB-Rückkehr keinen eindeutig definierten Wert besitzt)

Tab. 4.1. Modifikation des AE durch verschiedene Operatorgruppen

Die Zusammenstellung der Tab. 4.1 dient der näheren Erklärung des AE. Auf diese Darstellung wird später im Text verwiesen. Unverändert lassen bedeutet, eine Anweisung reicht das AE der Vorgängeranweisung an die folgende weiter, ohne eine Änderung von Wert und Typ vorgenommen zu haben. Undefiniert setzen bedeutet, dass die nachfolgende Operation das AE nicht zur Verknüpfung verwenden darf. So darf der erste Befehl eines FBs (der über CAL aufgerufen wurde) nur ein Lade LD, Sprung JMP, FB-Aufruf CAL oder Rückkehr RET sein, da diese Befehle kein AE benötigen. Die IEC 61131-3 selbst kennt keine Operatorgruppen, sie tragen aber wesentlich zum Verständnis bei. Die Beeinflussung und Auswertung des AE wird dort nur teilweise beschrieben. Bei Operationen wie AND sind Typ und Inhalt des AE vor und nach Ausführung intuitiv verständlich; die Norm lässt aber offen, wie das AE nach einem unbedingten Sprung definiert ist. So sind die in den

108

4 Die Programmiersprachen der IEC 61131-3

nachfolgenden Tabellen aufgeführten Operatorgruppen als sinnvolle Interpretationen und Folgerungen, nicht als bindende Norm zu sehen; sie können durchaus zwischen Programmiersystemen differieren.

4.1.3 Anweisungsteil: Operatoren Im Folgenden werden die für AWL definierten Operatoren zusammengefasst. Einige dieser Operatoren können mit den ”Modifizierern” N, ( und C zu einem neuen Operator kombiniert werden, wodurch dessen Bedeutung erweitert wird. Die Modifizierer bedeuten im Einzelnen: -

N ( C

Negierung des Operanden, Schachtelungsebenen durch Klammerung, Bedingte Ausführung des Operators (falls AE=TRUE).

Die Funktionalität der Modifizierer wird durch die nachfolgenden Beispiele näher erklärt. Negierung des Operanden. Vor Ausführung der Anweisung wird der Operand negiert:

VAR LDN ANDN

Var1: BOOL := FALSE; END_VAR FALSE (* TRUE {BOOL} ; entspricht LD 1 *) Var1 (* TRUE {BOOL} *)

Bsp. 4.4. Negierung von Operanden über den Operator-Modifizierer. Im Kommentar ist jeweils der Wert des ”aktuellen Ergebnisses (AE)” sowie der Datentyp {} nach Ausführung der Anweisung festgehalten.

Schachtelungsebenen durch Klammerung. Mit Hilfe der Klammeroperatoren lässt sich das AE mit dem Ergebnis einer Anweisungsfolge verknüpfen. Beim Erscheinen des Modifizierers „(“ werden der zugehörige Operator, der Wert des AE sowie der Datentyp des AE zwischengespeichert; der in der Zeile folgende Datentyp und Wert werden in das AE geladen. Beim Erscheinen des „)“ Operators werden der zwischengespeicherte Werte und Datentyp - gemäß des Operators mit dem Modifizierer – und das aktuelle Ergebnis verknüpft. Das Ergebnis landet wieder im AE. Die Norm schreibt nicht vor, in welcher Weise eine solche Zwischenspeicherung erfolgt; typischer Weise wird dies über einen temporären Datenstack realisiert.

4.1 Anweisungsliste AWL LD AND( OR ) ST

Var1 Var2 Var3

(* Lade Wert von Var1 *) (* Berechne den gesamten Klammerausdruck und *) (* verknüpfe ihn mit dem Aktuellen Ergebnis (Var1) *)

Var4

(* Speichere Gesamtverknüpfung *)

109

Bsp. 4.5. Blockweise Berechnung von Klammeroperatoren des booleschen Ausdrucks Var4 := Var1 š (Var2 › Var3)

Klammerausdrücke können auch geschachtelt werden, wie folgendes Bsp. zeigt:

LD 1 ADD( 2 ADD( 3 ADD 4 ) ) ST Var1

(* 1 *) (* 2 *) (* 3 *) (* 7 *) (* 9 *) (* 10 *) (* 10 *)

Bsp. 4.6. Berechnung von geschachtelten Klammerausdrücken. Im Kommentar wird der Wert des aktuellen Ergebnisses nach der Ausführung der Anweisung angegeben.

Die Norm lässt 2 Schreibweisen bei Verwendung des Klammeroperators zu; siehe Tab. 4.2

a) Kurzform Klammerausdruck LD 1 ADD( 2 … )

b) Langform Klammerausdruck LD 1 ADD( LD 2 … )

Tab. 4.2. Klammeroperatoren in Kurz- (a) und Langform (b)

Bemerkung: Die in Bsp. 4.6 gezeigte Spaltenformatierung (”Einrücken”) ist nicht vorgeschrieben. Die Möglichkeit, Schachtelungsebenen durch Einrücken zu dokumentieren, verbessert aber wesentlich die Übersichtlichkeit und damit die Qualität des Programms. Bemerkung: Es reicht nicht aus, den Wert des AE beim Erscheinen eines Klammerausdrucks zu speichern. Um die Datentyp-Konsistenz der kompletten Befehlssequenz sicherzustellen, muss auch der Datentyp mit abgelegt werden. Für diese Konsistenzüberprüfung ist das Programmiersystem verantwortlich.

110

4 Die Programmiersprachen der IEC 61131-3

Bedingte Ausführung von Operatoren. Verschiedene Operatoren wie GT liefern als AE einen booleschen Wert, der von nachfolgenden Operatoren als Ausführungsbedingung geprüft werden kann. Ist der boolesche Wert TRUE, erfolgt die Ausführung des Operators, sonst wird mit dem nächsten Befehl fortgefahren:

LD GT JMPC JMP

ErstOperand 20 B2 WeitWeg

(* Erzeuge AE = TRUE bei AE > 20, sonst FALSE *) (* Springe nach B2, wenn AE TRUE, sonst nächster Befehl *) (* Springe nach WeitWeg, unabhängig vom aktuellen AE *)

Bsp. 4.7. Bedingte und unbedingte Variante des Sprungbefehls JMP

In den nachfolgenden Tabellen werden alle möglichen Kombinationen von Operatoren mit Modifizierern angegeben. Bestimmte Operatoren sind für logische inklusive boolesche (ANY_BIT) Datentypen reserviert, weitere für allgemeine Datentypen, sowie Sprünge und Aufrufe. Soweit gleichnamige Standard-Funktionen (wie ADD, ...) in der IEC 61131-3 vorhanden sind (siehe Anh. A), ist die dort beschriebene TypVerträglichkeit zu beachten.

Operatoren LD LDN AND ANDN AND( ANDN( OR OR ( XOR XOR( NOT

ORN ORN ( XORN XORN(

ST S R

STN

Operatorgruppe a E W

W W

) a

W

U U U W

Erklärung Lädt Operand (negiert) in AE UND-Verknüpfung des (negierten) Operanden mit AE; Ersatzdarstellung „&“ für AND ist statthaft. ODER-Verknüpfung des (negierten) Operanden mit AE Exklusiv-ODER-Verknüpfung des (negierten) Operanden mit AE Bitweise boolesche Negierung (1er Komplement) Speichert AE in den Operand Setzt Operand auf TRUE, wenn AE=1 Setzt Operand auf FALSE zurück, wenn AE=1 Schließen der Klammerebene

Erklärung siehe Tab. 4.1.

Tab. 4.3. Operatoren mit logischen inklusive booleschen Operanden (Typ ANY_BIT)

Weshalb erfolgte die Definition der Klammeroperatoren? Die IEC 61131-3 bietet zwar Standard-Funktionen wie AND, die den Datentyp ANY_BIT zulassen und

4.1 Anweisungsliste AWL

111

damit die Funktionalität der Operatoren geeignet erweitern. Es gibt aber in AWL keine Möglichkeit, ein Verknüpfungsergebnis als Operand in einer Funktion anzugeben, was in ST oder FBS möglich ist. Um solche Berechnungen dennoch durchführen zu können, wurde der Klammeroperator definiert.

V3 := V0 AND (V1 OR V2)

LD V0 AND V1 OR V2 (* FEHLER *) ST V3 (* Vorsicht: Ergebnis nicht *) (* identisch mit: *) (* LD V0 *) (* AND V1 *) (* OR V2 *) (* ST V3 *)

LD V0 AND( V1 OR V2 ) ST V3

a) Aufruf über Std. Funktion/Operator

b) Operator

V0 V1

>=1

V2

c) ST

&

V3

d) FBS

Bsp. 4.8. Um zusammengesetzte Ausdrücke als Operand von logischen Operatoren / Standard-Funktionen verwenden zu können, wurden die Klammeroperatoren definiert.

Die Operatoren S und R sind verkürzte Schreibweisen für bedingtes Speichern. Der Operator S steht für STC, R steht für STCN.

Operatoren LD ST ADD ADD( SUB SUB( MUL MUL( DIV DIV( MOD MOD( GT GT( GE GE( EQ EQ( NE NE( LE LE( LT LT( ) a

Operatorgruppe a E U W W W W W W W W W W W W

Erklärung Lädt Operand als AE Speichert AE als Operand Addiert Operand auf AE Subtrahiert Operand von AE Multipliziert Operand mit AE Dividiert AE durch Operand Modulo Division AE größer Operand AE größer gleich Operand AE gleich Operand AE ungleich Operand AE kleiner gleich Operand AE kleiner Operand Schließen der Klammerebene

Erklärung siehe Tab. 4.1.

Tab. 4.4. Operatoren mit Operanden vom Datentyp (Typ ANY_NUM)

112

4 Die Programmiersprachen der IEC 61131-3

Tab. 4.4 enthält die Operatoren LD und ST, die nicht nur für logische oder numerische Verknüpfungen, sondern für alle Datentypen (Datentyp ANY) zulässig sind. Die Eigenschaft der Operatoren, auf mehrere Datentypen anwendbar zu sein, entspricht dem Überladen von Standard-Funktionen. Die Operatoren müssen deshalb überladen oder typisiert sein. Bei Vergleichsoperatoren besitzt das AE nach der Ausführung den Wert TRUE, falls die Vergleichsbedingung erfüllt ist, sonst FALSE.

Operatoren JMP JMPC JMPCN CAL CALC CALCN RET RETC RETCN Fun-Name

Operatorgruppe a - oder U b U Uc - oder U d U Wc

a

Erklärung siehe Tab. 4.1.

c

b

Implementierungsabhängig

d

Erklärung (Un-) bedingter Sprung zu einer Sprungmarke (Un-) bedingter Aufruf eines Funktionsbausteins (Un-) bedingter Rücksprung aus Funktion oder Funktionsbaustein Aufruf einer Funktion gilt für folgenden Operator (beim Funktionsoder FB-Einsprung aber undefiniert!) bei Funktionen: Funktionswert (”U”)

Tab. 4.5. Operatoren für Sprünge und Aufrufe

Die Operanden von Sprunganweisungen sind Sprungmarken, der Operand eines Funktionsbaustein-Aufrufs (CAL, CALC, CALCN) ist der Name der FB-Instanz.

4.1.4 Verwendung von Funktionen und Funktionsbausteinen

Aufruf von Funktionen. Funktionen werden in AWL durch Angabe des Namens aufgerufen. Ihre Aktualparameter werden durch Kommata getrennt angehängt. Dies entspricht der Schreibweise von Operatoren mit mehreren Operanden. Aktuelle Werte können auch unter Verwendung von ":=" den entsprechenden Formalparametern zeilenweise zugewiesen werden. Dies gilt jedoch nicht für die in AWL gültigen Operatoren, die nur die erste Variante der Wertzuweisung erlauben. Der erste Parameter einer Funktion ist im Falle eines Aufrufs ohne Formalparameter das AE, das zuvor geladen wurde. Daher ist der erste Operand hinter dem Funktionsnamen in dieser Variante der zweite Aktualparameter; sie dazu Bsp. 4.9.

4.1 Anweisungsliste AWL

Aktualparameter

mit Formalparametern

mit Formalparametern

LD LIMIT

LIMIT( MN := 1, IN := 2, MX := 3 )

LIMIT( MX := 3, IN :=2, MN :=1 )

1 2, 3

113

Bsp. 4.9. Äquivalenter Aufruf einer Funktion mit Aktualparametern und Formalparametern, letztere in beliebiger Reihenfolge

Eine Funktion hat mindestens einen Ausgangsparameter (Funktionswert), der das AE ersetzt. Besitzt die Funktion weitere Ausgangsparameter, werden diese über entsprechende Parameterzuweisungen, siehe Abschnitt 2.5 und Bsp. 4.10, zurückgeliefert. Ein Aufruf ohne Formalparameter erfolgt in einer Zeile, dabei ist die Reihenfolge der Deklarationen einzuhalten. Im Falle von Formalparameterzuweisungen geschieht dies zeilenweise mit abschließender Klammerzeile.

LIMIT( EN:= ErrorCond, MN :=1, IN :=2, MX := 3, ENO => ErrorCondLim )

(* => zeigt: ENO ist Ausgangsparameter *)

Bsp. 4.10. Äquivalenter Aufruf einer Funktion zu Bsp. 4.9 mit Formalparametern mit EN/ENO Ausführungssteuerung und Ausgangsparameter ENO. Auch hier ist das Ergebnis von LIMIT im AE.

Der Funktionswert wird vom Programmiersystem einer Variablen mit dem Funktionsnamen zugewiesen; dieser Name ist automatisch deklariert und muss nicht gesondert vom Anwender im Deklarationsteil des aufrufenden Bausteins angegeben werden. Die Verwendung von EN/ENO entspricht der in Abschnitt 2.7 dargelegten Funktionalität. Der Aufruf einer POE mit EN/ENO Parameter kann nicht über Aktualparameter, sondern muss mit Formalparameter erfolgen.

114

4 Die Programmiersprachen der IEC 61131-3

Aufruf einer Funktion:

Definition

VAR ErstFunPar: INT:=10; Par2: INT:= 20; Par3: INT:= 30; Erg: INT; END_VAR

FUNCTION AnwenFun: INT VAR _INPUT FunPar1, Fun Par2 , FunPar3 : INT; END_VAR

LD AnwenFun (* Zweiter Aufruf: *) AnwenFun ST

ErstFunPar Par2, Par3

LD ADD

300 AnwenFun

Par2, Par3 Erg

der Funktion:

LD FunPar1 ADD FunPar2 ADD FunPar3 RET (* kann am Ende auch entfallen *) END_FUNCTION

Bsp. 4.11. Zweimaliger Aufruf einer Anwenderfunktion. FunPar1 erhält beim ersten Aufruf 10, beim zweiten 60, FunPar2 jeweils 20 und FunPar3 30 zugewiesen. In Erg ist nach der Ausführung der Wert 110 zu finden. Dieser Wert wird anschließend auf 300 addiert.

Aufruf von Funktionsbausteinen. FBs werden aufgerufen, indem der Operator CAL (bzw. CALC bedingt oder CALCN bedingt negiert) verwendet wird. Die IEC 61131-3 stellt in AWL drei Methoden zur Verfügung, um einen FB aufzurufen: 1) Aufruf mit der Liste der Ein- und Ausgangsparameter in Klammern, 2) Aufruf mit vorausgegangenem Laden und Speichern der Eingangsparameter, 3) Aufruf implizit durch Benutzung der Eingangsvariablen als Operatoren. Methode 3 kann nicht für anwenderdefinierte, sondern nur für Standard-Funktionsbausteine verwendet werden, da das Programmiersystem die Namen der FBEingangsvariablen wie Operatoren behandeln muss. Für Ausgangs-Operatoren ist nichts Vergleichbares vorgesehen. Im folgenden Beispiel werden diese drei Aufrufarten am Beispiel eines FBs Zeit1 demonstriert.

4.1 Anweisungsliste AWL

115

Zeit1 TON IN

Q

PT

ET

Abb. 4.2. Standard-Funktionsbaustein TON

VAR Frei, Aus: Zeit1: Wert: END_VAR

BOOL := 0; (* Freigabe - Eingang; Ausgang *) TON; (* Std - FB TON besitzt als Formalparameter *) (* IN, PT (Eingang) und Q, ET (Ausgang *) TIME; (* Setz - Eingang *)

(* Methode 1 *)

(* Methode 2 *)

(* Methode 3 *)

LD ST LD ST

t#500ms Zeit1.PT Frei Zeit1.IN

LD PT LD

t#500ms Zeit1 Frei

CAL

Zeit1

IN

Zeit1

(* Parameterversorgung: *)

(* Aufruf: *) CAL Zeit1 ( IN:=Frei, PT:= t#500ms, Q=>Aus, (* Ausgangsp. 1 *) ET=>WERT (* Ausgangsp. 2 *) )

(* Auswertung der Ausgangsparameter *) LD Zeit1.Q ST Aus LD Zeit1.ET ST Wert

Bsp. 4.12. Zeit1 als Instanz des FBs TON, seine Eingangsparameter-Versorgung, Aufruf und Auswertung der Ausgangsparameter

Der Deklarationsteil ist bei allen Methoden gleich. Sie unterscheiden sich in der Versorgung der Eingangsparameter und im Aufruf; siehe auch Abschn. 2.8.4Soweit ein Programmiersystem mehrere Methoden unterstützt, können die Methoden für Versorgung, Aufruf und Auswertung auch gemischt werden.

116

4 Die Programmiersprachen der IEC 61131-3

In Abwandlung von Methode 1 kann ein Aufruf mit Aktualparametern, wie bei Funktionen, erfolgen. Hierbei werden die Übergabewerte der Parameter in ihrer definierten Reihenfolge, durch Komma getrennt, hintereinander geschrieben. Bei Methode 3 führt der PT-Operator zur Initialisierung der PRESET-Zeit, der IN-Operator zum Aufruf des FBs Zeit1, also zum Starten der Zeit. In einer Befehlszeile nicht angesprochene Eingangsparameter werden bei Methode 3 nicht geändert, d.h. es werden die Werte aus vorausgegangenen Zuweisungen verwendet. Methode 3 ist mit Vorsicht zu verwenden, da es beim Aufruf des FBs nicht intuitiv ersichtlich ist, ob nur eine Parametrierung eines Eingangparameters oder die Ausführung des Funktionsbausteins erfolgt.

4.2.5 Beispiel AWL: Bergbahn Das folgende Beispiel stellt die vereinfachte Steuerung einer Bergbahn dar. Es wird hier zunächst in AWL programmiert. Im Beispiel-Abschnitt von Kontaktplan 4.4.5 ist die grafische Variante zu finden.

Bergstation S3

Mittelstation S2

Talstation S1

Abb. 4.3. Beispiel einer Bergbahn, bestehend aus drei Stationen.

Die Steuerung hat folgende Anforderungen zu berücksichtigen: 1) Die Sensoren S1, S2, S3 melden TRUE (1), wenn sich die Gondel in einer der Stationen befindet. In dem Zähler StationStopp ist die Gesamtsumme aller Stations-Einfahrten zu registrieren. 2) Der Motor zur Gondelbewegung kennt die Eingangsgrößen: * Richtung: Vorwärts (TRUE) / Rückwärts (FALSE) (gepuffert deklariert) * StartStop: Start (TRUE), Stop (FALSE)

4.1 Anweisungsliste AWL

117

3) In der Gondel befindet sich ein Schalter TuerAuf. Schalter auf 1 bedeutet: ”Tür öffnen”, FALSE bedeutet: ”Tür schließen”. 4) Der Motor zur Türsteuerung besitzt zwei Aktoren TuerOeffnen und TuerSchliessen (aktiv: bei Flanke von FALSE nach TRUE), die ihn jeweils zum Öffnen und Schließen der Tür veranlassen. 5) Eine Taste BahnAn setzt die Bahn in Betrieb; mit Schalter BahnAus kann das Betriebsende veranlasst werden. 6) Ein Warnsignal ist in der Zeit zwischen Abschalten der Bahn und dem Neustart anzusteuern. In Abschn. 4.4.5 erfolgt eine Kommentierung dieser Steuerung am Beispiel der Netzwerke.

FUNCTION_BLOCK BBSteuer VAR_INPUT BahnAn: BOOL R_EDGE; BahnAus: BOOL; S1, S2, S3: BOOL R_EDGE; TuerAuf: BOOL; END_VAR VAR_IN_OUT StartStopp: BOOL; END_VAR VAR_OUTPUT TuerOeffnen: BOOL; TuerSchliessen: BOOL; END_VAR VAR_OUTPUT RETAIN EndeSignal: BOOL; END_VAR VAR StationStopp: CTU; TuerZeit: TON; END_VAR VAR RETAIN Richtung: BOOL; END_VAR

(* Flankengesteuer. Taste zum Bergbahn Start *) (* Schalter zum Einleiten des Betriebsendes *) (* Flankengesteuer. Sensor fuer Stationsaufenthalt *) (* Schalter fuer Tueroeffnen. 1: oeffnen; 0: zu! *)

(* Kabine faehrt: 1; steht: 0 *)

(* Motor zur Tuer Oeffnung *) (* Motor zum Tuerverschluss *)

(* Warnsignal fuer Power Off gepuffert *)

(* Standard-FB (Zaehler) fuer Stationseinfahrten *) (* Standard-FB (Zeitverzoeger.) fuer Kabinenstart *)

(* aktuelle Richt: auf- oder abwaerts *)

(* System gestartet ? Das beim letzten Beenden aktivierte Endesignal *) (* wird nach Spannungswiederkehr und Aufnahme der Aktivitaet geloescht *) LD BahnAn (* Der erste Aufruf ? *) R EndeSignal (* Falls Ja: Reset *) JMPC RueckZaehl (* bereits oefters aufgerufen !*) JMP Einfahrt (* Ruecksetzen Zaehler *) RueckZaehl: LD 1 ST StationStopp.RESET LD 9999 ST StationStopp.PV CAL StationStopp JMP KabineVerschliessen

(* Parameterversorgung für spaeteren Aufruf *) (* Parameterversorgung für spaeteren Aufruf *) (* Aufruf der FB-Instanz StationStopp *)

118

4 Die Programmiersprachen der IEC 61131-3

(* Beim Einfahren der Kabine wird der Zaehler StationStopp hochgezaehlt *) Einfahrt: LD S1 (* Alle 3 flankengesteuert ! *) OR S2 OR S3 (* Halt, wenn nun das AE gleich 1 *) R StartStopp (* Stopp Kabine *) CALC StationStopp ( RESET:= 0, CU:=1 ) (* Falls Halt-> Hochzaehlen *) (* Evtl. Richtungswechsel *) LD S1 XOR S3 JMPCN KeinUmschalten

(* Eines der beiden 1 geworden ? *)

(* Kabinen-Richtung umdrehen *) LD Richtung STN Richtung (* Oeffnen nur nach Kabinenstopp und nach Betaetigen des Tuerschalters *) KeinUmschalten: LD TuerAuf ANDN StartStopp ST TuerOeffnen (* Bahnende + in Station -> POE-Ende *) LD BahnAus (* Ausschalter betaetigt? *) ANDN StartStopp S EndeSignal JMPC PoeEnde (* Tuerschliessen nach Betaetigen des Tuerschalters *) KabineVerschliessen: LD TuerAuf STN TuerSchliessen (* Weiterfahrt 10 Sek. nach Betaetigen des Tuerschalters *) LDN TuerAuf ANDN StartStopp ST TuerZeit.IN LD T#10s ST TuerZeit.PT CAL TuerZeit LD TuerZeit.Q (* Zeit abgelaufen ? *) S StartStopp RET (* Kehre zur aufrufenden POE zurueck *) PoeEnde: END_FUNCTION_BLOCK

Bsp. 4.13. Bergbahn-Steuerung mit dem FB BBSteuer als AWL-Beispiel. Eine mögliche Variante des aufrufenden PROGRAM kann der CD entnommen werden (BBHAUPT.POE)

4.2 Strukturierter Text ST

119

4.2 Strukturierter Text ST Die Programmiersprache Strukturierter Text ST ist eine weitere textuelle Programmiersprache der IEC 61131-3. Man spricht bei ihr von einer höheren Programmiersprache, da nicht wie bei AWL „maschinennahe” Befehle verwendet werden, sondern über abstraktere Befehle mächtige Sprachkonstrukte aufgebaut werden können. Vorteile dieser Sprache (im Vergleich zu AWL): -

sehr kompakte Formulierung der Programmieraufgabe, übersichtlicher Aufbau des Programms durch Anweisungsblöcke, mächtige Konstrukte zur Steuerung des Befehlsflusses.

Diesen Vorteilen stehen auch Nachteile gegenüber: -

Die Übersetzung in den Maschinencode ist nicht direkt beeinflussbar, da dieser mittels eines Compilers (Übersetzerprogramm) erzeugt wird. Durch die höhere Abstraktionsstufe kommt es u.U. zu einem Effizienzverlust (übersetzte Programme sind i.a. länger und langsamer).

Die Lösung einer Programmieraufgabe wird in einzelne Schritte (Anweisungen) zerlegt. Eine Anweisung dient dem Berechnen und Zuweisen eines Werts, der Steuerung des Befehlsflusses, dem Aufruf oder Verlassen einer POE. PASCAL oder C sind vergleichbare höhere Programmiersprachen aus dem PCBereich.

4.2.1 Anweisung in ST Ein ST-Programm setzt sich aus einer Anzahl von Anweisungen zusammen. Anweisungen sind durch Strichpunkt getrennt. Im Gegensatz zu AWL spielt das Zeilenende als Anweisungsende keine Rolle; syntaktisch wird das Zeilenende (Zeilenumbruch) wie ein Leerzeichen interpretiert. Damit kann sich eine Anweisung über mehrere Zeilen erstrecken oder mehrere Anweisungen können in einer einzigen Zeile stehen. Kommentare werden durch Klammern und Stern (* Kommentar *) gekennzeichnet und dürfen auch innerhalb von Anweisungen stehen (an allen Stellen, an denen Leerzeichen erlaubt sind): A := B (* Dehnung *) + C (* Temperatur *);

In ST gibt es folgende Anweisungen, die Tab. 4.6 zusammenfasst.

120

4 Die Programmiersprachen der IEC 61131-3

Schlüssel- Beschreibung wort := Zuweisung

Erklärung

d := 10;

Zuweisung des rechts berechneten Wertes an den links stehenden Bezeichner Aufruf einer anderen POE vom Typ FB, sowie deren Parameterversorgung. „:=“ für Eingangs-, „=>“ für Ausgangsparameter Rückkehr in die aufrufende POE Auswahl von Alternativen durch boolesche Ausdrücke

Aufruf und Gebrauch von FBs a

FBName( Par1:=10, Par2:=20, Par3=>Erg);

RETURN

Rücksprung

RETURN;

IF

Verzweigung

CASE

Multiauswahl

FOR

Wiederholungsanweisung (1)

WHILE

Wiederholungsanweisung (2)

REPEAT

Wiederholungsanweisung (3)

EXIT

SchleifenAbbruch Leeranweisung

IF d < e THEN f:=1; ELSIF d=e THEN f:=2; ELSE f:= 3; END_IF; CASE f OF 1: g:=11; 2: g:=12; ELSE g:=FunName(); END_CASE; FOR h:=1 TO 10 BY 2 DO f[h/2] := h; END_FOR; WHILE m > 1 DO n := n / 2; END_WHILE; REPEAT i := i*j; UNTIL i > 10000 END_REPEAT; EXIT;

; a

Beispiel

Auswahl eines Anweisungsblocks, abhängig vom Wert des Ausdrucks f

Mehrfachdurchlauf eines Anweisungsblocks mit Startund Endebedingung Mehrfachdurchlauf eines Anweisungsblocks mit Endebedingung Mehrfachdurchlauf eines Anweisungsblocks mit nachgeschalteter Endebedingung Abbruch einer Wiederholungsanweisung

;;

Funktionsaufrufe bilden keine Anweisungen, sondern können nur innerhalb eines Ausdrucks als Operanden verwendet werden

Tab. 4.6. Anweisungen in ST

ST kennt keine Sprunganweisung (GOTO). Dies stellt zwar keine funktionelle Einschränkung dar, zumal Sprunganweisungen zu unstrukturierten Programmen verführen. Jeder bedingte Sprung kann auch über eine IF-Abfrage programmiert werden. Durch die besondere Umgebung der SPS, wie ihre Echtzeitanforderung, könnten Sprünge allerdings zur Effizienzsteigerung beitragen, um z.B. nach der Feststellung einer Fehlerbedingung stark verschachtelte Anweisungen schnell verlassen zu können.

4.2 Strukturierter Text ST

121

Wie in Tab. 4.6 zu sehen ist, benötigen die Anweisungen den Wert einzelner Variablen (h, e), Konstanten (10) oder den Gesamtwert der Verknüpfung mehrerer Variablen (z.B. bei der Multiplikation: i * j). Eine Teilanweisung, die als Ergebnis einen Wert liefert, nennt man Ausdruck. Dieses Grundelement von ST wird im folgenden Abschnitt vorgestellt und dient als Voraussetzung für die weitere Beschreibung der Anweisung.

4.2.2 Ausdruck als Teilanweisung in ST Ausdrücke liefern die zur Bearbeitung von Anweisungen nötigen Werte. Ein Wert kann von einem einzelnen Operanden stammen oder sich aus der Verknüpfung mehrerer Operanden ergeben. Beispiele für Ausdrücke (aus Tab. 4.6): 10

n/2

i < 10000

FunName()

Ein Ausdruck besteht aus Operanden und verknüpfenden ST-Operatoren. Der grundsätzliche Aufbau ist im folgenden Bild zusammengestellt:

ST-Programm

Anweisung_1 ... Anweisung_x

Ausdruck_1 ... Schlüsselwort ... Ausdruck_y

Operand_1 ... ST-Operator ... Operand_z

Abb. 4.4. Ein ST-Programm setzt sich aus Anweisungen zusammen. Diese bestehen aus Schlüsselworten und Ausdrücken. Letztere werden über Operanden und ST-Operatoren beschrieben.

Operanden. Als Operanden sind zugelassen: -

Literal (numerische, Zeichen, Zeit), Beispiele: 10, 'abcdef', t#3d_7h, “10“, UINT#9, UINT#8#11 Variable (Einzel-/ Multielement-Variable), Beispiele: Var1, Var[1,2], Var1.Unterstruc, Funktionsaufruf bzw. der errechnete Funktionswert, Beispiel: FunName(Par1, Par2, Par3), weiterer Ausdruck, Beispiel: 10 + 20.

122

4 Die Programmiersprachen der IEC 61131-3

Operatoren. Zur Verknüpfung der Operanden innerhalb von Ausdrücken gibt es in ST folgende Operatoren:

Operator

Beschreibung

( )

Klammerung Funktionsaufruf

-

Negation

NOT

Komplement

**

Potenzierung

*

Multiplikation

/

Division

MOD

Modulo

+

Addition

-

Subtraktion

<, > , <=, >= =

Vergleich Gleichheit

<>

Ungleichheit

&, AND

Boolesches UND

XOR

Exklusives Boolesches OR

OR

Boolesches ODER

Beispiel mit Wert des Ausdrucks (2 * 3) + (4 * 5) Wert: 26 CONCAT ('AB', 'CD') Wert: 'ABCD' -10 Wert: -10 NOT TRUE Wert: FALSE 3 ** 4 Wert: 81 10 * 20 Wert: 200 20 / 10 Wert: 2 17 MOD 10 Wert: 7 .4 + 2.5 Wert: 3.9 3-2-1 Wert: 0 10 > 20 Wert: FALSE T#26h = T#1d2h Wert: TRUE 8#15 <> 13 Wert: FALSE TRUE AND FALSE Wert: FALSE TRUE XOR FALSE Wert: TRUE TRUE OR FALSE Wert: TRUE

Rangfolge Hoch

niedrig

Tab. 4.7. Operatoren von ST als Elemente von Ausdrücken

Der Aufruf eines Funktionsbausteins ist selbst eine Anweisung und besitzt im Gegensatz zur Funktion keinen Rückgabewert (nur über Parameter). FB-Aufrufe sind somit nicht innerhalb eines Ausdrucks erlaubt.

4.2 Strukturierter Text ST

123

Existieren zu den oben genannten Operatoren Standard-Funktionen (wie Potenzierung, Multiplikation, ...), gelten bzgl. der Datentypen der Eingangsparameter und des Typs des Funktionswerts die dort beschriebenen Regeln. Wie man sieht, kann ein Ausdruck sowohl mit Hilfe eines Operators x + y als auch einer Standard-Funktion ADD(x, y) beschreiben werden (identisches Verhalten). Besteht ein Ausdruck aus mehr als einem Operator, sind die Rangfolgeregeln zu beachten. Sie werden am folgenden Beispiel erläutert:

(115 - (15 + 20 * 2)) MOD 24 MOD 10 + 10 Bsp. 4.14. Abarbeitung von Operatoren gemäß der vorgegebenen Rangfolge

1) In einem Ausdruck sind die Operatoren gemäß der in Abb. 4.7 vorgegebenen Rangfolge abzuarbeiten: Berechne den innersten Klammerausdruck, da Klammern die höchste Priorität der Operatoren besitzen. Berechne Multiplikation (20 * 2 = 40) Berechne Addition (15 + 40 = 55) ergibt 55 Berechne nächst höheren Klammerausdruck Berechne Subtraktion (115 - 55 = 60) ergibt 60 Berechne den Modulo- Operator (60 MOD 24 = 12) 2) Sind in einem Ausdruck mehrere Operatoren mit derselben Rangfolge vorhanden, erfolgt die Bearbeitung von links nach rechts. Berechne 60 MOD 24 MOD 10 = 2 3) Operanden eines Operators werden von links nach rechts abgearbeitet. Berechne zuerst den links vom Additionszeichen stehenden Ausdruck: Berechne (115 - (15 + 20 * 2)) MOD 24 MOD 10 (siehe 2) ergibt 2 Berechne den rechts vom Additionszeichen stehenden Ausdruck Berechne 10 Berechne den Additions-Operator ergibt 12 Der Datentyp dieses Wertes hängt von der Variablen ab, der dieser Wert zugewiesen wird (in Bsp. 4.14 muss sie aufgrund der Operatoren vom Typ ANY_INT sein). Klammerung sollte nicht nur dazu verwendet werden, bestimmte Vorgaben bzgl. der Abarbeitungsreihenfolge zu machen. Die Verwendung von Klammern eignet sich auch sehr gut, um die Lesbarkeit eines komplizierten Ausdrucks zu erhöhen; weiterhin lassen sich damit falsche Annahmen über Vorrangregeln vermeiden.

124

4 Die Programmiersprachen der IEC 61131-3

Funktionen als Operatoren. Funktionen werden über ihre Namen und in Klammern, durch Kommata getrennt, die Aktualparameter aufgerufen. Wahlweise können Formalparameter über den Zuweisungsoperator „:=“ (Eingangsparameter) oder „=>“ (Ausgangsparameter) mit angegeben werden, dann ist die Reihenfolge der Parameteraufzählung ohne Bedeutung. Nicht relevante oder Parameter mit Initialwert können weggelassen werden.

ADD (1, 2, 3); (* Vollständige Angabe der Aktualparameter *) LIMIT (MN := 0, MX := 10, IN := 4); (* Angabe mit Formalparameter *) AWFUN(EinP1:=10, AusPar=>Erg); (* Anwenderfunktion mit 1 Eingangsparameter, 1 Funktionswert (Rückgabewert) und 1 zusätzlichen Ausgangsparameter *)

Bsp. 4.15. Aufruf der Std.-FUN ADD mit Aktualparametern, LIMIT mit Formalparametern und AWFUN als Beispiel mit zusätzlichem Ausgangsparameter

Neben den Standard-Funktionen können auch benutzerdefinierte Funktionen aufgerufen werden. Funktionsaufrufe werden im Gegensatz zu FB-Aufrufen (Anweisung) zu den Ausdrücken gerechnet, da sie seiteneffektfrei sind. Eine Funktion liefert stets, wie die Operatoren, bei gleichen Eingangsparametern denselben Ausgangswert. Globale Variable innerhalb von Funktionen sind verboten.

4.2.3 Anweisung: Zuweisung Eine Zuweisung kopiert den rechts vom Gleichheitszeichen stehenden Wert (Wert des Ausdrucks) in die links stehende Einzel- oder Multielement-Variable.

Bezeichner

:=

Ausdruck; Ausdruck, wie oben beschrieben. Zuweisungszeichen Variable, die den Wert zugewiesen erhält.

Abb. 4.5. Zuweisung in ST

4.2 Strukturierter Text ST

125

TYPE MulVar: STRUCT Var1: INT; Var2: REAL; END_STRUCT; END_TYPE VAR

d: INT; e: ARRAY [0..9] OF INT; f: REAL; g: MulVar (Var1:=10, Var2 := 2.3); h: MulVar; END_VAR d := 10; (* Zuweisung *) e[0] := d ** 2; h := g; (* Zwei Zuweisungen in einer Zeile *) d := REAL_TO_INT(f); (* Zuweisung mit Funktionsaufruf *)

Bsp. 4.16. Beispiele für Anweisungen vom Typ Zuweisung ”:=”

Die erste Zuweisung in Bsp. 4.16 weist der Variablen d den Integer-Wert 10 zu; die nächste Anweisung kopiert den Wert 100 in das erste Element des Felds e. Die Multielement-Variable h erhält alle in g gespeicherten Datenwerte (10 für Var1 und 2.3 für Var2). Wie man in der zweiten Anweisungszeile dieses Beispiels sieht, kann man mehrere Anweisungen in eine Zeile schreiben. Dies sollte aber aus Gründen der Übersichtlichkeit vermieden werden, denn Kompaktheit ist kein Gütekriterium für Quellcode. Durch ein geeignetes Umbrechen und Einrücken einer Anweisung in die nächste Zeile(n) (z.B. bei komplizierten IF-Abfragen) erhöht sich die Übersichtlichkeit und Wartbarkeit des Programms wesentlich. Bei Zuweisungen ist auf die Typ-Verträglichkeit zu achten. Sind auf der rechten und linken Seite der Zuweisung unterschiedliche Datentypen, muss mit Hilfe einer Funktion zur Typwandlung eine Angleichung vorgenommen werden. Eine besondere Rolle spielt die Funktionswertzuweisung. Vor der Rückkehr einer Funktion muss mindestens eine Zuweisungs-Anweisung erfolgt sein, die dem Funktionsnamen (auf der linken Seite) einen Wert mit passendem Datentyp zuweist. Es können auch mehrere solcher Zuweisungen in einer Funktion erfolgen. Der zuletzt an den Funktionsnamen zugewiesene Wert gilt nach der Rückkehr als Funktionswert.

126

4 Die Programmiersprachen der IEC 61131-3

FUNCTION Xyz: MulVar VAR_INPUT Faktor1, Faktor2:INT; END_VAR VAR_TEMP Tmp: MulVar; END_VAR

Aufruf (Verwendung) der Funktion Xyz: ... VAR i: INT; z: MulVar; END_VAR

Tmp.Var1 := 10 * Faktor1; Tmp.Var2 := 4.5 * INT_TO_REAL(Faktor2); Xyz := Tmp; END_FUNCTION

z := Xyz (20, 3); i := z.Var1; ...

Bsp. 4.17. Funktionsdefinition mit Wertzuweisung an den Funktionsnamen, sowie die Verwendung (Aufruf) der Funktion (Typdefinition von MulVar siehe Bsp. 4.16).

4.2.4 Anweisung: Aufruf von Funktionsbausteinen In ST wird ein FB über seinen Namen und seine in Klammern stehenden Formalparameter, die über ”:=” den Wert des Aktualparameters zugewiesen bekommen, aufgerufen. Im Fall eines Ausgangsparameters erfolgt die Zuweisung über „=>“. Die Reihenfolge der Parameter ist irrelevant. Werden beim Aufruf Parameter weggelassen, so verwendet der Funktionsbaustein den Initialwert oder den beim letzten Aufruf zugewiesenen Wert. ST kennt auch den Aufruf über Aktualparameter. Wie bei AWL werden die aktuellen Werte, durch Kommata getrennt, übergeben. FUNCTION_BLOCK FbTyp VAR_INPUT VarEin: INT, VarH: INT := 1; END_VAR VAR_OUTPUT VarAus: INT := 5; END_VAR IF (VarEin > VarH) THEN VarAus := 10; END_IF; END_FUNCTION_BLOCK

Aufruf (Verwendung) des FBs FbName: ... VAR FbName: FbTyp; ERG: INT; END_VAR FbName(); (* FbName.VarAus besitzt den Wert 5 *) FbName(VarEin := 3, VarAus=>Erg); (* Alternativaufruf: FbName(3, 1, Erg *); (* FbName.VarAus besitzt den Wert 10, welcher nach ERG kopiert wird *) ...

Bsp. 4.18. FB-Definition mit Wertzuweisung an die Ausgangsparameter, sowie die Verwendung (Aufruf) des FBs.

4.2.5 Anweisung: Rücksprung (RETURN) Soll eine Funktion, FB oder Programm verlassen werden, auch bevor das POEEnde erreicht ist, kann dies durch die Anweisung RETURN erreicht werden. Es ist zu beachten, dass zu diesem Zeitpunkt bei Funktionen der Funktionswert (Variable mit dem Namen der Funktion) zugewiesen sein muss. Werden Ausgangsparameter von FBs innerhalb des FBs nicht mit Werten belegt, besitzen sie die voreingestellten Werte ihrer Datentypen.

4.2 Strukturierter Text ST

127

... (* Falls die Variable x kleiner als y, verlasse die POE *) IF x < y THEN RETURN; END_IF; ...

Bsp. 4.19. Rücksprung in die aufrufende POE, ohne das POE-Ende erreicht zu haben.

4.2.6 Anweisung: Verzweigung, Multiauswahl Diese beiden Anweisungstypen dienen dazu, abhängig von einer Bedingung bestimmte Anweisungen auszuführen. In den folgenden Beispielen stehen Anweisungen jeweils für keine, eine oder mehrere Anweisungen (Anweisungsblock). Bedingungen bezeichnen boolesche Ausdrücke, die als Ergebnis TRUE oder FALSE liefern. Alternativ-Verzweigung.

Bedingung1 TRUE

FALSE

Anweisungen1

Bedingung2 TRUE

FALSE

Anweisungen2

Bedingung3 TRUE

...

FALSE

... Anweisungen

Abb. 4.6. Abfrage-Baum mit einer IF-Anweisung, bestehend aus Bedingungen mit booleschen Ausdrücken und ST-Anweisungen.

Die Bedingung1 liefert den booleschen Wert TRUE oder FALSE. Bei TRUE werden eine Reihe von Anweisung (Anweisungen1) ausgeführt, bei FALSE die nächste Bedingung Bedingung2 geprüft. Ein letzter Anweisungsblock (Anweisungen) schließt die IF-Anweisung ab. Er wird dann ausgeführt, wenn alle Bedingungen mit FALSE berechnet wurden. IF-Anweisungen können beliebig geschachtelt werden.

128

4 Die Programmiersprachen der IEC 61131-3

IF Ausdruck THEN Anweisungsblock;

Ausführung des Anweisungsblocks nur, wenn der boolesche Ausdruck gleich TRUE. ELSIF Ausdruck THEN Anweisungsblock; Ausführung nur, wenn vorausgegangene Ausdrücke gleich FALSE und dieser boolesche Ausdruck gleich TRUE. Diese Teilanweisung kann entfallen oder beliebig oft wiederholt werden. ELSE Anweisungsblock; Ausführung nur, wenn vorausgegangene Ausdrücke gleich FALSE. Teilanweisung kann entfallen. END_IF; Schließende Klammer der IF-Anweisung

Abb. 4.7. IF-Abfrage. Der Anweisungsblock besteht aus keiner, einer oder mehreren Anweisungen (Schlüsselworte fett).

Der in Abb. 4.6 gezeigte Baum wird wie folgt in ST programmiert:

IF Bedingung1 THEN Anweisungen1; (* Führe Anweisungen1 aus, falls Bedingung1 TRUE, gehe dann zu Weiter; sonst: *) ELSIF Bedingung2 THEN Anweisungen2; (* Führe Anweisungen2 aus, falls Bedingung2 TRUE, gehe dann zu Weiter; sonst: *) ELSIF Bedingung3 THEN ... ELSE Anweisungen; (* Führe Anweisungen aus, falls keine der bisherigen Bedingungen zutrafen *) END_IF; (* Weiter *)

Bsp. 4.20. Programmierbeispiel für eine IF-Abfrage

Multiauswahl.

Ausdruck ... Wert1: Anweisungen1 Wert2 : Anweisungen2

...

ELSE Anweisungen

Abb. 4.8. Fallunterscheidung einer CASE-Abfrage mit einem Ausdruck vom Typ ANY_INT oder Aufzählungstyp, einer Liste von Werten bzw. Wertebereichen und die dazugehörenden Anweisungen; am Ende einer Alternative für alle restlichen Werte (ELSE).

4.2 Strukturierter Text ST

129

Nimmt der ganzzahlige Ausdruck einen Wert (Wert1, Wert2, ...) an bzw. einen Wert aus dem jeweiligen Aufzählungstyp, werden die diesem Wert zugeordneten Anweisungen ausgeführt. Trifft keiner der Werte zu, kann eine Default-Auswahl (ELSE) festgelegt werden (diese steht somit für alle nicht aufgeführten Werte). Liefert der Ausdruck keinen der angegebenen Werte und fehlt die Default-Angabe, wird keine Anweisung ausgeführt.

CASE Ausdruck OF case_wert : Anweisungsblock;

ELSE Anweisungsblock; END_CASE;

Ausführung nur, wenn der Ausdruck gleich dem angegebenen case-Wert. Diese Teilanweisung kann einmal oder mehrfach aufgeführt werden. case_wert ist ein- oder mehrfacher ganzzahliger Integerwert (SINT, INT, DINT, LINT), ein Aufzählungswert oder eine entsprechende Bereichsangabe: ”Wert1..Wert2”. Ausführung nur, wenn der Ausdruck keinem case_wert entspricht. Teilanweisung kann entfallen. Schließende Klammer der CASE-Anweisung

Abb. 4.9. CASE-Anweisung. Der Anweisungsblock besteht aus keiner, einer oder mehreren Anweisungen (Schlüsselworte fett).

Die in Abb. 4.8 angesprochene Struktur kann folgendermaßen programmiert werden:

CASE VarInteger OF 1: Anweisungen1; (* Führe Anweisungen1 aus, falls VarInteger 1 liefert; gehe zu Weiter *) 2,3: Anweisungen2; (* Führe Anweisungen2 aus, falls VarInteger 2 oder 3 liefert; gehe zu Weiter *) 10..20: Anweisungen3; (* Führe Anweisungen3 aus, falls VarInteger zwischen 10 und 20 liegt *) (* gehe zu Weiter *) ELSE Anweisungen; (* Führe Anweisungen aus, falls keine der bisherigen Bedingungen zutraf *) END_CASE; ... (* Weiter *)

Bsp. 4.21. Programmierbeispiel für eine CASE-Abfrage

130

4 Die Programmiersprachen der IEC 61131-3

4.2.7 Anweisung: Wiederholung Um eine Anzahl von Anweisungen mehrfach auszuführen, stehen in ST drei Sprachkonstrukte zur Verfügung: WHILE, REPEAT und FOR. WHILE- und REPEAT-Anweisungen. Abhängig vom Wert eines booleschen Ausdrucks wird ein Anweisungsblock ausgeführt. Er wird durchlaufen, solange der Ausdruck den Wert TRUE (WHILE) bzw. FALSE (REPEAT) besitzt. WHILE prüft den Ausdruck vor der Ausführung der Anweisungen, REPEAT danach. Bei der REPEAT-Variante werden die Anweisungen somit mindestens einmal durchlaufen.

Bedingung = TRUE ? J Anweisung_1; Anweisung_2; ... Anweisung_n;

N

Anweisung_1; Anweisung_2; ... Anweisung_n;

Bedingung = TRUE ? N a) WHILE

b) REPEAT

J

Abb. 4.10. Zyklische Ausführung von Anweisungen mit den Varianten WHILE (a) und REPEAT (b). Die Bedingung ist ein boolescher Ausdruck.

WHILE Ausdruck DO Anweisungsblock; END_WHILE;

Ausführung solange, wie vorausgegangener boolescher Ausdruck gleich TRUE. Schließende Klammer der WHILE-Anweisung

Abb. 4.11. WHILE-Anweisung. Der Anweisungsblock besteht aus keiner, einer oder mehreren Anweisungen (Schlüsselworte fett).

4.2 Strukturierter Text ST REPEAT Anweisungsblock; UNTIL Ausdruck END_REPEAT;

131

Wiederhole Anweisungsblock erneut, bis der boolesche Ausdruck gleich TRUE. Schließende Klammer der REPEAT-Anweisung

Abb. 4.12. REPEAT-Anweisung. Der Anweisungsblock besteht aus keiner, einer oder mehreren Anweisungen (Schlüsselworte fett).

Die Wiederholungsanweisung wird an Bsp. 4.22 demonstriert. Es wird nach dem Vorkommen des höchsten Werts innerhalb eines Feldes gesucht und – falls vorhanden – sein Wert der Variablen Maximum zugewiesen.

VAR TestFeld: ARRAY [1..5] OF INT := [2, 16, 4, 7, 32]; Index: INT := 1; IndexMax: INT := 5; Maximum: INT := 0; END_VAR ... REPEAT WHILE Index <= IndexMax DO IF TestFeld[Index] > Maximum THEN IF TestFeld[Index] > Maximum THEN Maximum := TestFeld[Index]; Maximum := TestFeld[Index]; END_IF; END_IF; Index := Index + 1; Index := Index + 1; UNTIL Index > IndexMax END_REPEAT; END_WHILE;

... Bsp. 4.22. Wiederholte Bearbeitung desselben Anweisungsblocks (umrahmt) unter Verwendung der REPEAT- bzw. WHILE- Anweisung.

FOR-Anweisung. Die dritte Wiederholungsanweisung benutzt eine ganzzahlige Steuervariable, die vor dem ersten Durchlauf mit einem frei bestimmbaren Anfangswert initialisiert wird. Nach jedem Durchlauf des Anweisungsblocks wird sie um die Schrittweite erhöht bzw. (bei negativem Wert) erniedrigt. Der Endwert bildet die EndeBedingung der Wiederholung.

132

4 Die Programmiersprachen der IEC 61131-3

FOR Steuervariable := Ausdruck TO Ausdruck BY Ausdruck DO Anweisungsblock; Anfangswert Endwert Schrittweite END_FOR; Schließende Klammer der FOR - Anweisung

Abb. 4.13. FOR-Anweisung. Anfangswert, Endwert und Schrittweite der Steuervariablen erhalten ihre Werte durch Auswertung eines Ausdrucks. Der Anweisungsblock besteht aus keiner, einer oder mehreren Anweisungen (Schlüsselworte fett).

Die Ausführung erfolgt somit nur, wenn der Wert der Steuervariablen nicht außerhalb des Anfangs-/Endwertintervalls liegt. Bsp. 4.22 kann mit der FOR-Anweisung wie folgt programmiert werden:

VAR

TestFeld: ARRAY [1..5] OF INT := [2, 16, 4, 7, 32]; Index: INT; IndexMax: INT := 5; Maximum: INT := 0; END_VAR

... FOR Index := 1 TO IndexMax BY 1 DO IF TestFeld[Index] > Maximum THEN Maximum := TestFeld[Index]; END_IF; END_FOR; ...

Bsp. 4.23. Wiederholte Bearbeitung des Anweisungsblocks aus Bsp. 4.22 unter Verwendung der FOR-Anweisung. Der Feldindex wird hier durch die Schrittweite der Steuervariablen erhöht.

Die Steuervariable Index wird in diesem Beispiel mit 1 initialisiert und bei jedem Schleifendurchgang um 1 erhöht (BY 1). Die Schrittweite ”BY 1” kann auch weggelassen werden, da ihr Standardwert 1 beträgt. Bei negativer Schrittweite wird die Steuervariable in jedem Durchlauf erniedrigt. Eine FOR-Anweisungen wird in folgenden Schritten abgearbeitet: 1) 2) 3) 4) 5)

Initialisiere die Steuervariable beim ersten Durchlauf. Prüfe Abbruchbedingung und beende evtl. Wiederholungsbearbeitung. Führe Anweisungsblock aus. Erhöhe die Steuervariable um die Schrittweite (Standardwert ist 1). Gehe zu Schritt 2.

4.2 Strukturierter Text ST

133

Für FOR-Anweisungen gelten folgende Bedingungen: 1) Der Typ der Steuervariablen, ihr Anfangs- und Endwert sowie die Schrittweite besitzen denselben ganzzahligen Datentyp (SINT, INT oder DINT). 2) Die Steuervariable und Variablen, die ihren Anfangs- und Endwert beeinflussen, dürfen innerhalb des Anweisungsblocks nicht beschrieben werden. 3) Die Abbruchbedingung wird vor jedem Durchlauf überprüft. Obwohl die Forderung 2 nicht für die Schrittweite gilt, sollte man ihre Wertveränderung innerhalb des Anweisungsblocks vermeiden. Die IEC 61131-3 schreibt nämlich den Berechnungszeitpunkt der Schrittweite nicht vor, so dass er vor dem ersten Durchlauf liegen kann oder die Schrittweite vor/nach jedem Durchlauf neu bestimmt wird; dies kann zu unterschiedlichem Verhalten bei verschiedenen Programmiersystemen führen. Der Wert der Steuervariablen nach Beendigung der FOR-Schleife hängt von der jeweiligen Implementierung ab. Sie besitzt den im letzten Durchlauf zugewiesenen Wert oder einen um die Schrittweite erhöhten bzw. erniedrigten Wert. EXIT-Anweisung. Jede Wiederholungsanweisung (REPEAT, WHILE und FOR) kann vorzeitig mit der Anweisung EXIT verlassen werden. Bei geschachtelten Anweisungen wird mit EXIT die innerste Wiederholungsanweisung verlassen und mit dem nächsten Befehl in der darüber liegenden Anweisung fortgefahren.

WHILE (...) ... FOR ... TO ... BY ... DO ... IF ... THEN EXIT; END_IF; ... END_FOR; ... END_WHILE;

Fortsetzung bei EXIT-Abbruch

Bsp. 4.24. Abbruch einer Wiederholungsanweisung innerhalb eines Anweisungsblocks mit der Anweisung EXIT

134

4 Die Programmiersprachen der IEC 61131-3

4.2.8 Beispiel Stereo-Rekorder Das folgende Beispiel stellt die Steuerung eines Stereo-Rekorders in ST dar. Im Abschn. 4.3.5 ist die grafische Variante in FBS zu finden, bei der auch die zu berechnenden Formeln erklärt werden.

-5

0

5

BAL.

VOL. +5

BalRegler

0

L

10

LsRegler

R

Abb. 4.14. Beispiel eines Stereo-Rekorders, für den die Lautstärke-Regelung programmiert wird. Rechts das Modell der Balance- bzw. Lautstärkeregler.

Die Steuerung hat folgende Elemente zu berücksichtigen: 1) Einstellung der beiden Lautsprecher, abhängig vom Balance-Regler (liefert gemäß seiner Position einen Integerwert zwischen -5 und +5) und dem Lautstärkeregler (liefert Integerwert zwischen 0 und +10). Der Verstärker-Baustein wird über eine Gleitpunktzahl gesteuert. 2) Überwachung der Lautstärke. Überschreitet der Pegel über eine gewisse Zeitspanne hinweg eine Maximalgrenze, liegt eine „Übersteuerung” vor und eine LED ist anzusteuern; weiterhin ist eine Warnungsmeldung an das aufrufende Programm zurückzugeben. 3) Es sind zwei Rekorder-Varianten (Hersteller-Modelle) zu beachten, die unterschiedlich belastbar sind und deshalb verschiedene Basiswerte für die Ansteuerung besitzen.

4.2 Strukturierter Text ST FUNCTION_BLOCK Lautstaerke VAR_INPUT BalRegler: SINT (-5..5); LsRegler: SINT (0..10); ModellTyp: BOOL; END_VAR VAR_OUTPUT RechterVerstBaustein: REAL; LinkerVerstBaustein: REAL; LED: BOOL; END_VAR VAR_IN_OUT Kritisch: BOOL; END_VAR VAR MaxWert: REAL := 26.0; Schmortest: Uebersteuer: END_VAR

TON; BOOL;

(* Balance Regler mit dig. Werten -5 bis 5 *) (* Lautst. Regler mit dig. Werten 0 bis 10 *) (* 2 Typen; unterschieden mit TRUE / FALSE *)

(* Steuerungswert fuer rechten Verstaerker *) (* Steuerungswert fuer linken Verstaerker *) (* Warn-LED anschalten: 1; sonst FALSE *)

(* Rueckmeldung an Aufrufer *)

(* Max. Aussteuerungswert; liegt er länger an *) (* gibt die LED Warnung *) (* Standard-FB (Zeitverzoeger.) fuer erlaubte *) (* Uebersteuerungszeit *) (* Zustand der Uebersteuerung *)

(* Einstellen des rechten Verstaerker-Bausteins, abhaengig von Lautstaerke und Balance-Regler *) RechterVerstBaustein := Norm ( LStR := LsRegler, Typ := ModellTyp, BlR := BalRegler+5); (* Einstellen des linken Verstaerker-Bausteins, Balance-Regler verhaelt sich genau umgekehrt wie rechts *) LinkerVerstBaustein := Norm ( LStR := LsRegler, Typ := ModellTyp, BlR := ABS(BalRegler -5)); (* Liegt Uebersteuerung vor ? *) IF MAX(LinkerVerstBaustein, RechterVerstBaustein) >= Maxwert THEN Uebersteuer := TRUE; ELSE Uebersteuer := FALSE; END_IF; (* Liegt Uebersteuerung schon über zwei Sekunden vor? *) SchmorTest (IN := Uebersteuer, PT := T#2s); LED := SchmorTest.Q; IF SchmorTest.Q = TRUE THEN Kritisch := 1; END_IF; END_FUNCTION_BLOCK

135

136

4 Die Programmiersprachen der IEC 61131-3

FUNCTION Norm: REAL VAR_INPUT BlR: SINT; (* Normierter Balance-Regler *) LStR: SINT; (* Lautstaerke Regler *) Typ: BOOL; (* 2 Typen; unterschieden mit TRUE / FALSE *) END_VAR TYPE KalTyp : REAL := 5.0; (* Datentyp mit Initialwert *) END_TYPE VAR Kalibrier: KalTyp; (* Normgroesse fuer Verstaerkerausgang; mit 5.0 initialisiert *) END_VAR (* Abhaengig vom Verstaerkertyp werden aus den digitalen Reglergroessen *) (* passende Gleitpunktzahlen fuer den jeweiligen Verstaerkerbausteine errechnet *) Norm := SINT_TO_REAL(BlR) + (* Einfluss des Balance-Reglers *) Kalibrier + (* Allgemeiner Basiswert *) SEL(G := Typ, IN0 := 4.0, IN1 := 6.0) + (* Modellspezifischer Basiswert *) SINT_TO_REAL(LStR); (* Einfluss des Lautstaerke-Reglers *) END_FUNCTION

Bsp. 4.25. ST Programm zu der in Abb. 4.14 angesprochenen Steuerungsaufgabe, bestehend aus zwei POEs.

4.3 Funktionsbausteinsprache FBS

137

4.3 Funktionsbausteinsprache FBS Die Funktionsbausteinsprache FBS stammt aus dem Bereich der Signalverarbeitung, wo im Wesentlichen ganzzahlige und/oder Gleitpunktwerte verarbeitet werden. Inzwischen hat sie sich als eine universell einsetzbare Sprache im SPSBereich etabliert. Der folgende erste Abschnitt gilt auch für Kontaktplan KOP. Darin werden grundlegende, gemeinsame Elemente von FBS- und KOP-Netzwerken beschrieben.

4.3.1 Netzwerke, grafische Elemente mit Verbindungen (KOP, FBS) Die Darstellung einer POE mit Hilfe der grafischen Sprachen FBS und KOP besteht wie bei den textuellen aus 1) einer POE-Anfangs- und Endebezeichnung, 2) einem Deklarationsteil, 3) einem Anweisungsteil. Der Deklarationsteil kann grafisch oder textuell dargestellt werden. Der Anweisungsteil unterteilt sich in sogenannte Netzwerke, die zur Strukturierung der Grafik dienen. Ein Netzwerk gliedert sich in: 1) Netzwerkmarke, 2) Netzwerkkommentar, 3) Netzwerkgrafik. Netzwerkmarke. Jedes Netzwerk (bzw. jede Gruppe von Netzwerken), das von einem anderen Netzwerk aus angesprungen wird, erhält einen vorangestellten alphanumerischen Bezeichner oder eine vorzeichenlose dezimale Ganzzahl. Üblicherweise nummerieren Programmiersysteme zusätzlich die Netzwerke durch. Diese durchgehende Nummerierung aller Netzwerke wird beim Einfügen eines neuen Netzwerks automatisch aktualisiert. Sie dient dem schnellen Finden von Netzwerken (GeheZu; Positionierung auf die vom Compiler gemeldete Fehlerstelle) und entspricht damit den Zeilennummern der textuellen Sprachen. Die Norm fordert aber nur die Sprung-Netzwerkmarke. Diese Marke ist ein POE-lokaler Bezeichner.

138

4 Die Programmiersprachen der IEC 61131-3 0010

Netzwerkmarke: vom Anwender eingegeben automatische Durchnumerierung

(* Dies ist ein Netzwerkkommentar *) (* ........ *)

Netzwerkgrafik

Bsp. 4.26. Vergabe von Netzwerkmarken zur Identifizierung und Kennzeichnung von Sprungzielen

Netzwerkkommentar. Zwischen Netzwerkmarke und Netzwerkgrafik erlauben die meisten Programmiersysteme die Eingabe eines Kommentars, der wie in den textuellen Sprachen mit (*...*) geklammert wird. Die IEC 61131-3 selbst kennt keinen Netzwerkkommentar (und damit weder die Ausgabestelle noch die Form). Netzwerkgrafik. Die Netzwerkgrafik besteht aus grafischen Objekten, die sich in grafische (Einzel-) Elemente sowie Verbindungen und Konnektoren unterteilen. Über Verbindungen fließen Daten in die grafischen Elemente, werden verarbeitet und an ihre Ausgänge weitergeleitet. Zur Darstellung dieses Informationsflusses werden die Elemente grafisch über Linien verbunden, die sich auch kreuzen können. Dabei treten berührungsfreie Kreuzungen auf (die Linien sind voneinander unabhängig, d.h. die Verbindungen beeinflussen sich nicht gegenseitig) und Kreuzungen, bei denen Linien zusammengeführt oder geteilt (die Information fließt zusammen, bzw. wird vervielfacht) werden:

4.3 Funktionsbausteinsprache FBS

Elem. E1

Elem. A1

Elem. E2 Elem. A2

a) berührungsfreie Kreuzung (2 unabhängige Verbindungen)

Elem. E1

Elem. A1

Elem. E2

Elem. A2

139

Elem. A3 b) Kreuzung (n:m Verbindung)

Abb. 4.15. Kreuzung von Verbindungslinien in KOP bzw. FBS. Eine Zusammenführung (rechts: E1 - E2) ist in FBS nicht möglich.

Der Austausch der Information von E1 zu A2 bzw. von E2 nach A1 erfolgt im Fall a) der Abb. 4.15 ohne gegenseitige Beeinflussung. Im Fall b) erhalten die Elemente A1, A2, A3 dieselbe Information von E1 und E2, was durch das „+”Zeichen bzw. eine direkte Verbindung gekennzeichnet wird. Dabei werden die Ausgangslinien von E1 und E2 zusammengeführt und der Wert an die Eingangslinien von A1, A2 und A3 verteilt. Eine Zusammenführung wie im Fall b) (E1/E2) ist nur in KOP zulässig (gestrichelt), da es sich dabei um das sogenannte „verdrahtete ODER” (engl.: wired or) handelt. Können Linien nicht weiter dargestellt werden, wenn z.B. der rechte Seitenrand am Bildschirm (bei Programmiersystemen mit begrenzter Netzwerktiefe, die kein „horizontales Scrolling” erlauben) oder beim Drucken erreicht ist, kann die Weiterführung einer Linie am linken Rand über sogenannte Konnektoren dargestellt werden. Sie sind nicht mit den Netzwerkmarken zu verwechseln. Konnektoren dienen nicht der Ausführungskontrolle, sondern stellen eine Art „Zeilenumbruch” dar. Um z.B. bei einer Druckausgabe beliebig tiefe Verknüpfungen zuzulassen, können Linien am „rechten” Rand mit einem Konnektornamen versehen werden, der als Eingangslinie auf der linken Seite wieder einfließt. In Abb. 4.16 wird der Konnektor konn1 benutzt, um das Netzwerk netzwerk_x in die beiden Teilnetzwerke aufzuteilen.

140

4 Die Programmiersprachen der IEC 61131-3

netzwerk_x: Teilnetzwerk1

konn1 Konnektor

konn1

Teilnetzwerk2 Bildschirm- oder Druckausschnitt

Abb. 4.16. Konnektor für den „Zeilenumbruch” in KOP und FBS

Konnektornamen sind POE-lokale Bezeichner und dürfen weder als Netzmarke noch als sonstige Bezeichner verwendet werden. Solche Konnektoren können vom Anwender selbst eingegeben werden („fester Zeilenumbruch”) oder vom Programmiersystem bei der Darstellung auf dem Bildschirm oder Drucker automatisch erzeugt werden. Alle Netzwerkelemente, die direkt miteinander verbunden sind oder indirekt über Konnektoren, gehören zu demselben Netzwerk.

4.3.2 Netzwerkaufbau in FBS Die grafischen Elemente eines FBS-Netzwerks bestehen aus Rechtecken und Anweisungen der Ausführungssteuerung, die durch horizontale und vertikale Linien verbunden sind. Nicht verbundene Eingänge dieser Rechtecke können mit Variablen oder Konstanten beschaltet werden. Ihre Ein- und Ausgänge können auch offen, d.h. unbeschaltet bleiben.

4.3 Funktionsbausteinsprache FBS

141

0001 StartNetzwerk: (* Netzwerk - Kommentar *) Funktion VarAnd1 AND

Zaehler_1 Wertweitergabe

VarAnd2 Var_Anf 1000

Ausgangsvariable

CTU CU R

Funktionsbaustein

Q

VarAus

CV

PV

Negation von binären FunktionsEin- und Ausgängen

Bsp. 4.27. Elemente eines FBS-Netzwerks

Bsp. 4.27 verknüpft die Eingangsvariablen VarAnd1 (negiert) und VarAnd2 mit der UND-Funktion AND, verbindet das (negierte) Ergebnis mit dem Zähl-Eingangsparameter CU der FB-Instanz Zaehler_1 vom FB-Typ CTU. Der Ausgang Zaehler_1.Q wird direkt der Variablen VarAus zugewiesen. Negierte boolesche Ein- und Ausgänge von Funktionen und FBs werden durch einen Kreis „o” gekennzeichnet. Flankengesteuerte Eingänge beim FB-Aufruf werden mit einem „>”- Zeichen (Erkennung einer steigenden Flanke) oder „<”- Zeichen (Erkennung einer fallenden Flanke) gekennzeichnet. Die IEC 61131-3 lässt offen, ob die ausgehende Verbindungslinie das Rechteck oben oder unten (siehe AND aus Bsp. 4.27) verlässt. Ebenso ist implementierungsabhängig, ob die Variablennamen grundsätzlich am linken Rand zu finden sind oder der Name vor statt auf die Verbindungslinie geschrieben wird. Bsp. 4.28 zeigt dazu eine Darstellungsvariante zu Bsp. 4.27.

142

4 Die Programmiersprachen der IEC 61131-3

0001 StartNetzwerk: (* Netzwerk - Kommentar *)

Zaehler_1 CTU

AND

VarAnd1

CU

Q

VarAus

CV VarAnd2 Var_Anf

R

1000

PV

Bsp. 4.28. FBS-Darstellungsvariante von Bsp. 4.27

Durch die grafische Verknüpfung lassen sich logische und arithmetische Beziehungen gut darstellen, wie man an nachfolgenden Beispielen sieht: d := c š (a › b) a

d := c + (a * b) a

>=1 b

b

&

c

*

d

+

c

d

Bsp. 4.29. Darstellung eines booleschen und eines arithmetischen Ausdrucks mit den grafischen Mitteln von FBS

4.3.3 Grafische Objekte in FBS Man unterscheidet in FBS folgende Grafikobjekte: 1) Verbindungen, 2) Grafikelemente zur Ausführungssteuerung (Sprünge), 3) Grafikelement zum Aufruf von Funktionen und Funktionsbausteinen (Standard und Anwenderdefiniert), sowie die in Abschn. 4.3.1 genannten 4) Konnektoren. FBS kennt darüber hinaus keine weiteren grafischen Elemente wie z.B. Öffner/Schließer in KOP; siehe dazu Abschn. 4.4.3.

4.3 Funktionsbausteinsprache FBS

143

Die Grafikobjekte von FBS werden in den folgenden Abschnitten erläutert und in Bsp. 4.33 (FB Lautstaerke) in Zusammenhang gestellt. Verbindungen. FBS verwendet horizontale und vertikale Verbindungslinien, die sich auch verzweigen dürfen. Ausgänge eines Rechtecks bzw. die Ausgänge mehrerer Rechtecke dürfen allerdings nicht miteinander verbunden werden (Zusammenführung), denn damit wäre unklar, welcher Wert weitergeleitet werden soll. Diese in KOP „verdrahtetes ODER” genannte Verbindung ist in FBS nicht zulässig. Somit erfolgt ein Wertefluss ausschließlich von einem Ausgang bzw. einer Variablen/Konstanten zu einem oder mehreren Eingängen des nachfolgenden Rechtecks bzw. nachfolgender Rechtecke. Dabei können Variablen mit Elementaren oder Abgeleiteten Datentypen weitergeleitet werden. Der Datentyp des Ausgangs muss mit den EingangsDatentypen übereinstimmen.

Grafikobjekt

a

Bezeichnung Horizontale Verbindung Vertikale Verbindung mit horizontalen Verbindungen unzulässige Verbindung („wired or”)

Erklärung Die horizontale Verbindung reicht den links stehenden Wert nach rechts weiter. Die horizontale Verbindung reicht den links stehenden Wert an alle rechts angeschlossenen Elemente weiter (Verzweigung).

Bsp. a alle [0004]

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.33 FB Lautstaerke

Tab. 4.8. Verbindungen in FBS

Ausführungssteuerung (Sprünge). Um die Programmausführung zu beeinflussen, stehen sowohl Aufrufe zum Verlassen der POE (Rücksprünge) als auch zur gezielten Abarbeitung einer NetzwerkReihenfolge (Sprünge auf Netzwerkmarken) zur Verfügung.

144

4 Die Programmiersprachen der IEC 61131-3

Grafikobjekt 1

RETURN

Bezeichnung (Unbedingter) Rücksprung

(Ersatzdarstellung)

b

tnw

RETURN

1

Marke b

tnw

a b

Marke

Bedingter Rücksprung

(Unbedingter) Sprung Bedingter Sprung

Erklärung Es existiert kein spezielles Grafikelement. Vom Anwender kann ein sofortiges Verlassen der POE beim Erreichen dieses Netzwerks und Rückkehr zum aufrufenden Programm erzwungen werden, indem als Eingangsbedingung für den bedingten Rücksprung 1 geschrieben wird. Beim Erreichen des POE-Endes erfolgt ebenfalls ein unbedingter Rücksprung. LinkeVerbindung des RETURN-Elements == TRUE::Verlasse POE und Rückkehr zum aufrufenden Programm, sonst: ohne Bedeutung. Springe zu dem mit dem Bezeichner „Marke” gekennzeichneten Netzwerk. LinkeVerbindung des Sprung-Elements == TRUE::Springe zu dem mit dem Bezeichner „Marke” gekennzeichneten Netzwerk, sonst: ohne Bedeutung.

Bsp. a [0005]

[0005]

[0004]

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.33 FB Lautstaerke tnw steht für Teilnetzwerk und liefert dem Grafikelement einen booleschen Wert

Tab. 4.9. Grafikelemente zur Ausführungssteuerung in FBS

Aufruf von Funktionen und Funktionsbausteinen. Beide POE-Typen können von einem in FBS dargestellten Programm aufgerufen werden. FBs und Funktionen können mehrere Ein- und Ausgangsparameter besitzen, . Diese Ein- und Ausgangsparameter sind innerhalb eines Rechtecks aufgeführt, bei erweiterbaren / überladbaren Funktionen entfällt dies; siehe dazu Bsp. 4.27. Die zugeordneten Linien werden außen mit Aktualparametern (Variablennamen, Konstanten) versehen oder mit anderen Aus- bzw. Eingängen verbunden. FBs müssen nicht wie in KOP mindestens einen booleschen Ein- und Ausgang besitzen. Nach IEC 61131-3 ist der Gebrauch der EN/ENO- Ein-/ Ausgänge bei Funktionsaufrufen in FBS möglich, aber nicht unbedingt notwendig (vgl. Abschn. 2.7). Ihre Realisierung hängt von der Implementierung des Programmiersystems ab; in vielen FBS-Systemen sind sie nicht vorhanden.

4.3 Funktionsbausteinsprache FBS

145

Der Funktionswert einer Funktion wird in der POE durch eine Wertzuweisung an den Funktionsnamen festgelegt (vgl. Ausgang der Addition in Netzwerk

146

4 Die Programmiersprachen der IEC 61131-3

0001 von Funktion Norm des Bsp. 4.33). Werden mehrere Zuweisungen an den

Funktionsnamen vorgenommen, gilt der zuletzt zugewiesene Wert. Im darstellenden Rechteck einer Funktion wird der Funktionswert rechts weitergereicht; sein Anschluss besitzt kein Formalparameternamen. Die restlichen Ausgangsparameter werden zur besseren Unterscheidbarkeit mit Formalparameternamen (im Rechteck) dargestellt. Handelt es sich um eine VAR_IN_OUT Deklaration, verbindet eine horizontale Linie den formalen Eingangs- mit dem Ausgangsparameter.

0001

Beispiel_Netzwerk:

AW_FUN Var1

IN

Var1

IO

Erg IO

Stat

Bsp. 4.30. Funktionsaufruf in FBS mit einer VAR_IN_OUT deklarierten Variablen IO und einem Funktionswert, welcher an die Variable Erg übergeben wird.

4.3.4 Programmiertechnik in FBS

Werteberechnung. Netzwerke werden in der Regel der Reihe nach berechnet; d.h. am Bildschirm von oben nach unten. Soll davon abgewichen werden, kann dies der Anwender über (Rück-) Sprunganweisungen programmieren. Es gibt auch abweichende Implementierungen, bei denen beispielweise die Auswertung aller Netzwerke gleichzeitig erfolgt oder über Ausführungsnummern geregelt ist. Die IEC 61131-3 überlässt die Reihenfolge der Netzwerkauswertung dem Programmiersystemhersteller, der seine Methode im Handbuch zu dokumentieren hat. An folgende Regelung haben sich alle Systeme zu halten: Die SPS arbeitet ein einzelnes KOP / FBS-Netzwerk bzw. Netzwerkelement nach folgenden Regeln („Auswertung“) ab:

4.3 Funktionsbausteinsprache FBS

147

1) Ein Element eines Netzwerks darf erst dann berechnet bzw. ausgeführt werden, wenn alle seine Eingänge berechnet sind. 2) Die Auswertung eines Netzwerkelements ist erst dann abgeschlossen, wenn alle seine Ausgangswerte berechnet sind. 3) Die Auswertung eines Netzwerks ist erst dann abgeschlossen, wenn die Ausgangswerte aller Elemente berechnet sind. Hierbei sind Besonderheiten bei der Querübersetzbarkeit zu beachten, siehe dazu Abschn. 7.3.1. In einem Netzwerk werden zunächst alle Eingänge jedes Rechtecks bestimmt, dann berechnet und weitergereicht.

1

+

2

a

3 4

*

+

5 6

b

Var1

c 9

/ Var2

Bsp. 4.31. Werteberechnung in einem FBS-Netzwerk. a, b und c sind Zwischenwerte, die im Text erläutert werden.

Im Bsp. 4.31 heißt dies für die Verbindungen a, b und c, dass c erst nach der Multiplikation (und damit nach a und b) berechnet werden kann. Die Addition vor a ergibt 6, vor b 15. Die Multiplikation errechnet sich auf 90; der Wert wird Var1 zugewiesen. Var2 wird nach der Division 10 zugewiesen. Die Reihenfolge der Wertzuweisung von Var1 und Var2 – welcher der beiden erhält als erstes seinen Wert – ist nicht festgelegt. Auf den Verbindungslinien eines Netzwerks können beliebige Datentypen weitergereicht werden, selbst Zeichenketten. Dies ähnelt dem Aktuellen Ergebnis (AE) in AWL.

148

4 Die Programmiersprachen der IEC 61131-3

Rückkopplungsvariable. FBS erlaubt die Verwendung einer Ausgangsvariablen als erneuten Eingangswert eines Netzwerks. Solche Variablen werden Rückkopplungsvariablen genannt. Bei der ersten Berechnung des Netzwerks wird ihr Anfangswert, danach ihr Wert nach der letzten Netzwerkberechnung verwendet.

Var1

Var2

Var1 *

* Var3

+

Var2

Var3

+

Var2

Bsp. 4.32. FBS-Netzwerk mit der Rückkopplungsvariablen Var2. Links implizite Verbindung und rechts explizite Rückkopplung mit direkter Verbindung. Beide sind möglich.

Es gibt einige Einschränkungen bei der Verwendung von Rückkopplungsvariablen im Zusammenhang mit FB-Aufrufen. Sie gelten gleichermaßen auch für KOP und werden im Abschn. 4.4.4 erläutert.

4.3.5 Beispiel Stereo-Rekorder in FBS Das folgende Beispiel beschreibt das Stereo-Rekorder-Beispiel aus dem Abschnitt 4.2.8, wo auch die Aufgabenbeschreibung sowie das äquivalente ST-Programm zu finden sind. Die Netzwerke werden im Anschluss an ihre grafische Darstellung kommentiert. FUNCTION_BLOCK Lautstaerke VAR_INPUT BalRegler: SINT (-5..5); LsRegler: SINT (0..10); ModellTyp: BOOL; END_VAR VAR_OUTPUT RechterVerstBaustein: REAL; LinkerVerstBaustein: REAL; LED: BOOL; END_VAR VAR_IN_OUT Kritisch: BOOL; END_VAR

(* Balance Regler mit dig. Werten -5 bis 5 *) (* Lautst. Regler mit dig. Werten 0 bis 10 *) (* 2 Typen; unterschieden mit TRUE / FALSE *)

(* Steuerungswert fuer rechten Verstaerker *) (* Steuerungswert fuer linken Verstaerker *) (* Warn-LED anschalten: 1; sonst FALSE *)

(* Rueckmeldung an Aufrufer *)

4.3 Funktionsbausteinsprache FBS VAR MaxWert:

REAL := 26.0;

Schmortest:

TON;

Uebersteuer: END_VAR

BOOL;

(* Max. Aussteuerungswert; liegt er länger an *) (* gibt die LED Warnung *) (* Standard-FB (Zeitverzoeger.) fuer erlaubte *) (* Uebersteuerungszeit *) (* Zustand der Uebersteuerung *)

0001: (* Einstellen des rechten Verstaerker-Bausteins, *) (* abhaengig von Lautstaerke und Balance-Regler *) BalRegler

+

5

Norm BIR

LsRegler ModellTyp

LStR Typ

RechterVerstBaustein

0002: (* Einstellen des linken Verstaerker-Bausteins, *) (* Balance-Regler verhaelt sich genau umgekehrt wie rechts *) BalRegler

-

5

Norm ABS LsRegler

ModellTyp

BIR LStR

Typ

LinkerVerstBaustein

0003: (* Liegt Uebersteuerung vor ? *) LinkerVerstBaustein

MAX

RechterVerstBaustein

>= MaxWert

Uebersteuer

149

150

4 Die Programmiersprachen der IEC 61131-3

0004: (* Liegt Uebersteuerung schon über zwei Sekunden vor? *) SchmorTest TON Uebersteuer

T#2s

IN

Q

PT

LED

Sicherheit

0005: (* verlasse FB *) 1

RETURN

0006 Sicherheit: (* Alternative zur direkten Verbindung: Rechteck mit Zuweisungszeichen „:=” *) 1

Kritisch

END_FUNCTION_BLOCK

_________________________________________________________________ FUNCTION Norm: REAL VAR_INPUT BlR: SINT; (* Normierter Balance-Regler *) LStR: SINT; (* Lautstaerke Regler *) Typ: BOOL; (* 2 Typen; unterschieden mit TRUE / FALSE *) END_VAR TYPE KalTyp : REAL := 5.0; (* Datentyp mit Initialwert *) END_TYPE VAR Kalibrier: KalTyp; (* Normgroesse fuer Verstaerkerausgang; mit 5.0 initialisiert *) END_VAR

4.3 Funktionsbausteinsprache FBS

151

0001: (* Abhaengig vom Verstaerkertyp werden aus den digitalen Reglergroessen *) (* passende Gleitpunktzahlen fuer die Verstaerkerbausteine errechnet *) BlR

SINT_TO_REAL

+ Kalibrier

Typ

SEL

4.0 6.0

LStR

SINT_TO_REAL

Norm

END_FUNCTION

Bsp. 4.33. FBS Programm zu der Stereo-Rekorder-Steuerung, bestehend aus zwei POEs. Siehe auch ST äquivalente Beschreibung in Abschn. 4.2.8.

Kommentierung der Netzwerke der Bsp. 4.25 und Bsp. 4.33 NetzwerkNummer

Kommentierung

FB Lautstaerke: 0001

Das Netzwerk ruft die Funktion Norm auf, die als Aktualparameter die Summe aus BalRegler und 5 erhält (Normierung von -5..5 auf 0..10), den Wert des Lautstärkereglers und die boolesche Kennung über den ModellTyp. Müssten mehr als zwei Modelltypen ausgesteuert werden, wäre für ModellTyp ein Aufzählungsdatentyp die bessere Wahl. Als Ergebnis (Rechter/Linker VerstBaustein) ergibt sich eine Gleitpunktzahl.

0002

siehe Netzwerk 0001. Da der Balance-Regler nun genau einen umgekehrten Effekt wie beim rechten Verstärker besitzt, wird eine Normierung von -5..5 auf 10..0 durchgeführt.

0003

Prüfung, ob einer der beiden Verstärkerwerte einen Maximalwert übersteigt. Übersteuer erhält den booleschen Wert der Überprüfung.

152

4 Die Programmiersprachen der IEC 61131-3

0004

Besitzt Uebersteuer den Wert TRUE, wird die Instanz SchmorTest des Standard-Zeitbausteins (FB) TON gestartet bzw. läuft weiter. Sie liefert nach 2 Sekunden am Ausgang Q den Wert TRUE. Schmortest wird rückgesetzt, sobald am Eingang IN FALSE anliegt. Somit wird in diesem Netzwerk LED an- und ausgeschaltet. Ist der Ausgang Q TRUE, springt das Programm nach Sicherheit (über die Ausführungssteuerung Springe bedingt).

0005

Rückkehr zum aufrufenden Programm.

0006

Rückmeldung von TRUE an das aufrufende Programm über die IN_OUT Variable Kritisch, dass sich die Lautstärke im kritischen Bereich befindet.

Funktion Norm: 0001

Die Addition setzt sich aus den von Short-Integer nach Real konvertierten Lautstärke- und Balancewerten, einer Kalibriergröße und, abhängig vom Eingangsparameter Typ, zwei Alternativwerten zusammen. Das Ergebnis ist eine Gleitpunktzahl als Funktionswert.

4.4 Kontaktplan KOP Die Sprache Kontaktplan (KOP) kommt aus dem Bereich der elektromechanischen Relaissysteme und beschreibt den Stromfluss durch die einzelnen Netzwerke der POE. Diese Programmiersprache beschränkt sich im Wesentlichen auf die Bearbeitung boolescher Signale (1 { TRUE oder 0 { FALSE).

4.4.1 Netzwerke, grafische Elemente mit Verbindungen (KOP) Wie in FBS gibt es auch bei KOP Netzwerke. Sie werden immer der Reihe nach von oben nach unten berechnet, soweit der Anwender keine andere Reihenfolge vorgibt. Die Beschreibung der Grundelemente und deren Verbindungen kann dem Abschn. 4.3.1 entnommen werden.

4.4 Kontaktplan KOP

153

4.4.2 Netzwerkaufbau in KOP Ein KOP-Netzwerk wird an seiner linken und rechten Seite durch sogenannte Stromschienen begrenzt. Von der linken Schiene, sie besitzt den logischen Zustand 1 („Strom fließt”), führen Verbindungen den „Strom” zu Elementen (Variablen), die abhängig von ihrem logischen Zustand die Weiterführung des Stroms zu den Ausgängen gestatten oder unterbinden.

0001

StartNetzwerk: (* Netzwerk - Kommentar *)

Var1

Var2

VarAus

Anweisungsteil mit linker und rechter Stromschiene

Bsp. 4.34. Grafikelemente eines KOP-Netzwerks

4.4.3 Grafikobjekte in KOP In KOP ergibt sich das Berechnungsergebnis durch die Anordnung der Einzelelemente (inklusiv Variablennamen), sowie die Art ihrer Verbindung. Diese Elemente können hintereinander („in Serie”) oder parallel verbunden sein.

Var1

Var2

Var3

VarAus

Var4

Bsp. 4.35. Die Elemente Var1, Var2 sind mit der Parallelschaltung aus Var3, Var4 in Serie geschaltet. Var1 bis Var4 werden als „Kontakte”, VarAus als „Spule” bezeichnet.

Die in Bsp. 4.35 gezeigte Schaltung entspricht dem logischen Ausdruck: VarAus := Var1 š Var2 š (Var3 › Var4).

KOP-Netzwerke bestehen aus folgenden grafischen Objekten: 1) Verbindungen, 2) Kontakte und Spulen,

154

4 Die Programmiersprachen der IEC 61131-3

3) Grafikelemente zur Ausführungssteuerung (Sprünge), 4) Grafikelement zum Aufrufe von Funktionen und Funktionsbausteinen (Standard und Anwenderdefiniert), sowie die in Abschn. 4.3.1 genannten 5) Konnektoren. Diese Grafikobjekte werden im Folgenden erläutert. Verbindungen. KOP kennt ähnlich wie FBS horizontale und vertikale Linien als Verbindungselemente sowie deren Kreuzungspunkte.

Grafikobjekt

Bezeichnung Horizontale Verbindung Vertikale Verbindung mit horizontalen Verbindungen

a

Erklärung Die horizontale Verbindung reicht den links stehenden Wert (FALSE oder TRUE) nach rechts weiter. Eine vertikale Verbindung verknüpft alle linken horizontalen Linien mit einem logischen OR- und reicht diesen Wert an alle rechten horizontalen Verbindungen weiter.

Bsp. a

[0005]

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44

Tab. 4.10. Verbindungen in KOP

Kontakte und Spulen. Ein Kontakt verknüpft den Wert einer eingehenden Verbindung mit dem Wert der zugewiesenen Variablen. Die Art der Verknüpfung hängt von der Variante des Kontakts ab. Der errechnete Wert wird an die rechte Verbindung weitergegeben.

Var1

Var2

a

b

c

Var1 0 1 0 1

Var2 0 0 1 1

Not Var2 Wert von b 1 0 1 1 0 0 0 1

Wert von c 0 1 0 0

Bsp. 4.36. Ein Schließer und ein Öffner als UND-Verknüpfung: Die Verbindung a besitzt den Wert TRUE (Stromschiene immer auf 1). b berechnet sich aus „Var1 AND 1”, c aus „b AND NOT Var2”.

4.4 Kontaktplan KOP

Var1

155

Var2

Var3

a b

Var1 0 1 0 1 0 1 0 1

Var2 0 0 1 1 0 0 1 1

Var3 0 0 0 0 1 1 1 1

Wert von a 0 0 0 1 0 1 0 1

Wert von b 0 0 0 0 0 1 0 1

Bsp. 4.37. Drei Schließer als UND/ODER-Verknüpfung: Die Verbindung a besitzt den Wert „Var1 AND (Var2 OR Var3)”, b den Wert „Var1 AND Var3”.

Kontakte (Öffner und Schließer) regeln, abhängig vom Wert ihrer Variablen sowie ihrer Lage im Netzwerk, die Weitergabe von Werten in einem Netzwerk (die Variablen werden nicht geändert!). Die Zuweisung von Werten an die Ausgangsvariablen der Netzwerke übernehmen Spulen (den Variablen wird ein Wert zugewiesen). Der Name der zum Kontakt gehörenden Variablen ist jeweils über dem Grafikelement zu finden. Die Variablen sind vom Datentyp BOOL (TRUE / FALSE). Die dazugehörigen Verbindungen leiten ebenfalls nur boolesche Werte weiter. Kontakte werden unterschieden in Öffner und Schließer. Einen Schließer kann man sich als schließenden elektromechanischen Kontakt vorstellen: wird der in Ruhestellung (FALSE) offene Kontakt „aktiviert” (TRUE), so schließt er sich und Strom kann fließen. Ein Öffner verhält sich genau umgekehrt: durch ihn fließt im Ruhezustand Strom. Wird er mit TRUE aktiviert, öffnet er den Kontakt und unterbricht damit den Stromfluss.

156

4 Die Programmiersprachen der IEC 61131-3

Grafikobjekt VarName

VarName

VarName P

VarName N

a

Bezeichnung Schließer

Öffner

Kontakt mit positiver Flankenerkennung

Kontakt mit negativer Flankenerkennung

Erklärung RechteVerbindung := LinkeVerbindung AND VarName, (kopiert den Wert von LinkeVerbindung nach RechteVerbindung, wenn der Wert der Variablen gleich TRUE; sonst FALSE). RechteVerbindung := LinkeVerbindung AND NOT VarName, (kopiert den Wert von LinkeVerbindung nach RechteVerbindung, wenn der Wert der Variablen gleich FALSE; sonst FALSE). RechteVerbindung := TRUE, wenn * die Variable bei der letzten Auswertung den Wert FALSE besaß und * die Variable bei der aktuellen Auswertung den Wert TRUE besitzt und * LinkeVerbindung den Wert TRUE besitzt, := FALSE in allen anderen Fällen, (liefert genau (und nur dann) bei einem FALSE o TRUE Übergang der Variablen den Wert von LinkeVerbindung; sonst FALSE). RechteVerbindung := TRUE, wenn * die Variable bei der letzten Auswertung den Wert TRUE besaß und * die Variable bei der aktuellen Auswertung den Wert FALSE besitzt und * LinkeVerbindung den Wert TRUE besitzt := FALSE in allen anderen Fällen, (liefert genau (und nur dann) bei einem TRUE o FALSE Übergang der Variablen den Wert von LinkeVerbindung; sonst FALSE).

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44

Tab. 4.11. Kontakte in KOP

Bsp. a [0007], [0009]

[0007], [0008], [0010]

[0001], [0005], [0006]

4.4 Kontaktplan KOP

157

Spulen dienen dem Zuweisen von Werten an Variablen:

Grafikobjekt VarName

VarName

VarName S

VarName R

VarName P

a b

Bezeichnung Spule

Erklärung Variable b := LinkeVerbindung, (kopiert den Wert von LinkeVerbindung in die Variable). Negative Spule Variable b := NOT LinkeVerbindung, (kopiert den invertierten (Tausch FALSE <-> TRUE) Wert von LinkeVerbindung in die Variable). Setze Spule Variable b := TRUE, wenn LinkeVerbindung gleich TRUE, bleibt unverändert in allen anderen Fällen. Rücksetze Variable b Spule := FALSE, wenn LinkeVerbindung gleich TRUE, bleibt unverändert in allen anderen Fällen. Variable b Spule mit positiver := TRUE, wenn Flanken* LinkeVerbindung bei der letzten erkennung Auswertung den Wert FALSE besaß und * LinkeVerbindung bei der aktuellen Auswertung den Wert TRUE besitzt, bleibt unverändert in allen anderen Fällen, (speichert genau (und nur dann) bei einem FALSE o TRUE Übergang von LinkeVerbindung in die Variable TRUE, sonst keine Änderung der Variable).

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44 RechteVerbindung erhält stets den Wert von LinkeVerbindung

Tab. 4.12. Spulen in KOP (wird fortgesetzt)

Bsp. a [0007]

[0010]

[0005]

158

4 Die Programmiersprachen der IEC 61131-3

VarName N

a b

Spule mit negativer Flankenerkennung

[0009] Variable b := TRUE, wenn * LinkeVerbindung bei der letzten Auswertung den Wert TRUE besaß und * LinkeVerbindung bei der aktuellen Auswertung den Wert FALSE besitzt, bleibt unverändert in allen anderen Fällen, (speichert genau (und nur dann) bei einem TRUE o FALSE Übergang von LinkeVerbindung in die Variable TRUE, sonst keine Änderung der Variable).

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44 RechteVerbindung erhält stets den Wert von LinkeVerbindung

Tab. 4.12. (Fortsetzung)

Ausführungssteuerung. Um die Programmausführung zu beeinflussen, stehen sowohl Aufrufe zum Verlassen der POE, als auch zur gezielten Abarbeitung einer Netzwerk-Reihenfolge (Sprünge) zur Verfügung.

Grafikobjekt RETURN

b

tnw

a b

RETURN

Bezeichnung (Unbedingter) Rücksprung

Bedingter Rücksprung

Erklärung Bsp. a [0011] Verlasse POE und kehre zur aufrufenden POE zurück. Bei Erreichen des POE-Ende (Nach Ende des letzten Netzwerks) erfolgt ebenfalls ein Rücksprung. LinkeVerbindung des RETURN-Elements == TRUE.: Verlasse POE und kehre zur aufrufenden POE zurück, sonst: ohne Bedeutung.

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44 tnw steht für Teilnetzwerk und liefert der Anweisung einen booleschen Wert

Tab. 4.13. Grafikobjekte zur Ausführungssteuerung in KOP (wird fortgesetzt)

4.4 Kontaktplan KOP

Marke

b

tnw

a b

Marke

159

(Unbedingter) Sprung

Springe zu dem mit dem Bezeichner „Marke” gekennzeichneten Netzwerk.

[0002], [0004]

Bedingter Sprung

LinkeVerbindung des Sprung Elements == TRUE.: Springe zu dem mit dem Bezeichner „Marke” gekennzeichneten Netzwerk, sonst: ohne Bedeutung.

[0001], [0008]

Die in [...] stehende Nummer bezieht sich auf Netzwerknummern in Bsp. 4.44 tnw steht für Teilnetzwerk und liefert der Anweisung einen booleschen Wert

Tab. 4.13. (Fortsetzung)

Aufruf von Funktionen und Funktionsbausteinen. Die POE-Typen FUN und FB können von einem in KOP dargestellten Baustein aufgerufen werden. FBs und Funktionen können mehrere Ein- und Ausgangsparameter besitzen, Funktionen mindestens einen Ausgang (Funktionswert). Diese Ein- und Ausgänge, sie müssen nicht alle vom Typ BOOL sein, sind als Formalparameter innerhalb eines Rechtecks aufgeführt; bei erweiterbaren/ überladbaren Funktionen entfällt dies. Die zugeordneten Linien werden außen mit Aktualparametern (Variablennamen, Konstanten) versehen oder mit anderen Aus- bzw. Eingängen verbunden. Dies entspricht der Verwendung wie in FBS. Die Negation von Ein-/Ausgängen bzw. die Kennzeichnung von flankengetriggerten Eingängen bei FBs erfolgt wie in FBS; siehe Abschn. 4.3.2. Funktionsbausteine müssen mindestens einen booleschen Ein- und Ausgang besitzen, die eine direkte oder indirekte Verbindung zu den Stromschienen besitzen. Bei Standard-FBs sind dies der Ausgang Q und einer der booleschen Eingänge.

FB -Instanzname FB - Typname

Zaehl

Teilnetzwerk

CTU LoeschVar

tnw

CU R

Setzwert

Q CV

PV

Bsp. 4.38. Aufruf des Standard-FBs CTU in einem KOP-Netzwerk

tnw

160

4 Die Programmiersprachen der IEC 61131-3

Der Parameter PV erhält als Aktualparameter die Variable Setzwert zugewiesen. Der Eingang R ist vorbeschaltet mit dem Kontakt LoeschVar. Ausgang CV ist unbeschaltet. „tnw” kennzeichnet ein Teilnetzwerk, das ebenfalls zur Vor- und Nachbeschaltung von Ein- und Ausgängen zulässig ist. Das linke tnw in Bsp. 4.38 könnte syntaktisch entfallen (Zaehl.R ist bereits mit der Stromschiene verbunden); CU müsste dann mit einer Variablen verbunden sein, welche den Zähltrigger auslöst. Das rechte tnw muss dagegen vorhanden sein, da CV vom Typ INT ist und nicht mit der Stromschiene verbunden werden kann. Funktionen können den EN / ENO Ein- und Ausgang verwenden, soweit er vom Programmiersystem unterstützt wird, um die Ausführung der Funktion zu kontrollieren. Ist EN FALSE, erfolgt keine Ausführung der Funktion und ENO wird vom System auf FALSE gesetzt. ENO kann auch als Fehlerstatus der Funktion verwendet werden (vgl. Abschn. 2.7). Diese beiden Parameter müssen direkt oder über ein Teilnetzwerk mit den Stromschienen verbunden sein. Der Zustand der restlichen Ausgangsparameter bei ENO=FALSE ist herstellerspezifisch zu dokumentieren. Inwieweit die übrigen, vor allem nicht-booleschen Parameter (z.B. IN0 in Bsp. 4.39) vorbeschaltet oder nur über Variablennamen versorgt werden, ist wie bei den FBs implementierungsabhängig.

Funktionsname Teilnetzwerk

SEL

tnw

EN SelVar Var1 Var2

G

tnw

ENO Funktionswert

IN0 IN1

Bsp. 4.39. Aufruf der Standard-Funktion SEL in ein KOP-Netzwerk

Der Funktionswert einer benutzerdefinierten Funktion wird wie bei den übrigen Sprachen durch eine Zuweisung festgelegt; d.h. mindestens eine Spule besitzt den Namen der (Funktions-) POE.

4.4 Kontaktplan KOP

161

4.4.4 Programmiertechnik in KOP

Werteberechnung. Netzwerke werden der Reihe nach von oben nach unten abgearbeitet. Soll davon abgewichen werden, kann dies der Anwender über (Rück-) Sprunganweisungen programmieren. Die IEC 61131-3 erlaubt in einem Netzwerk die Weiterverarbeitung eines Wertes nach einer (Zwischen-) Zuweisung, wie in Bsp. 4.41 dargestellt. Bei den meisten Programmiersystemen besteht ein Netzwerk jedoch aus: -

einem linken Teil, in dem aus Variablen, Konstanten und Funktionen ein gewünschter Wert berechnet wird (Berechnung), einem rechten Teil, der das Ergebnis verwertet (Verwendung).

0001: Var1

Var2

0002: Var1

Var5

Var6

Var3

0003: Var1

Var4 Marke

Var3

Berechnung

Verwendung

Bsp. 4.40. Struktur eines KOP-Netzwerks

162

4 Die Programmiersprachen der IEC 61131-3

0000: Var1

Var2

Var4 Marke

Var3

Var5

Var6

Bsp. 4.41. Erlaubtes, aber unübliches KOP-Netzwerk mit Zwischenzuweisung, das die gleiche Funktion wie die drei Netzwerke von Bsp. 4.40 besitzt.

Wie man sieht, ist das in Bsp. 4.41 vorgestellte Netzwerk zwar kompakter als die 3 Netzwerke von Bsp. 4.40, seine Funktionalität jedoch wesentlich schwieriger zu interpretieren. KOP wurde zur Verarbeitung von booleschen Werten konzipiert. Beinhaltet die POE viel Integer-Verarbeitung u.ä., sollte man möglichst eine andere Sprache verwenden. Solche Netzwerke sind zwar grundsätzlich in KOP programmierbar, aber sehr unübersichtlich (Verbindung zu Stromlinien, EN/ENO, ...). Manche Systeme bieten deshalb Editoren an, die sowohl KOP als auch FBSNetzwerke darstellen können. Sie stellen boolesche Netzwerke in KOP, die restlichen Netzwerke einer POE in FBS dar. Rückkopplungsvariable. Soll der Wert einer Variablen in der nächsten Netzwerkberechnung als Eingang verwendet werden, spricht man wie in FBS von einer Rückkopplungsvariablen.

Var1

Var1

Var2

Bsp. 4.42. Rückkopplungsvariable (Var1) in KOP

Im Gegensatz zu FBS sind in KOP nur implizite Rückkopplungen, also keine expliziten Verbindungen von rechts nach links erlaubt; siehe dazu Bsp 4.32. Werden FBs und Rückkopplungsvariablen in einem Netzwerk verwendet, kann dies je nach SPS-System zu unterschiedlichem Verhalten führen:

4.4 Kontaktplan KOP

Var1

Var2

163

Var3

FBname FBtyp E1

A1 A2

Var2

Bsp. 4.43. Netzwerk mit FB und Rückkopplungsvariable (Var2) mit undefinierter Berechnungsreihenfolge; siehe dazu nachfolgenden Text.

In Bsp. 4.43 ist unklar, ob der Schließer Var2 den Parameterwert FBname.A2 der letzten oder aktuellen Netzwerkberechnung erhält. Eine vergleichbare Situation tritt auf, wenn die Variable Var4 in Bsp. 4.41 durch Var6 ersetzt wird. Auch dann ist unklar, ob der neue Schließer Var6 den aktuellen Wert der Spule Var6 erhält oder den der letzten Netzwerkauswertung. Die IEC 61131-3 macht hierüber keine weiteren Aussagen. Um solche Unterschiede auszuschließen, sollte ein FB als eigenes Netzwerk angesehen werden. Sind Vor- und Nachverknüpfungen der Parameter notwendig, so dürfen die Variablen jeweils in den Vor- und Nachverknüpfungen nur als Kontakte vorkommen oder, falls sie als Spulen (schreibender Zugriff) auftreten, nur einmal im gesamten Netzwerk verwendet werden. Netzwerke wie in Bsp. 4.41 sollten entfallen. Wie sich leicht ersehen lässt, kann das in Bsp. 4.43 beschriebene Reihenfolgeproblem auch für globale Daten zutreffen. Ist Var2 in FBname als EXTERNAL deklariert und wird innerhalb von FBname beschrieben, führt dies zu Berechnungsproblemen beim Schließer Var2. Beeinflusst ein FB durch EXTERNALVariablen seine Aufrufumgebung, so spricht man von einem FB mit Seiteneffekten (im Gegensatz zur Seiteneffekt-Freiheit). Ist kein „Gedächtnis” erforderlich und kann deshalb auf FBs verzichtet werden, sollten seiteneffektfreie Funktionen an Stelle der FBs verwendet werden. Ist dennoch ein FB erforderlich, sollte auf eine vorsichtige Verwendung von EXTERNAL-Variablen geachtet werden.

4.4.5 Beispiel KOP: Bergbahn Das folgende Beispiel gibt das Bergbahn-Beispiel aus Abschn. 4.2.5 (AWL) in der Darstellung KOP wieder. Dort ist auch die Funktionalität, die der FB leistet, beschrieben.

164

4 Die Programmiersprachen der IEC 61131-3

Die Netzwerke werden im Anschluss an ihre grafische Darstellung kommentiert.

FUNCTION_BLOCK BBSteuer VAR_INPUT BahnAn: BOOL; (* Schalter zum Bergbahn Start *) BahnAus: BOOL; (* Schalter zum Einleiten des Betriebsendes *) S1, S2, S3: BOOL; (* Sensor fuer Stationsaufenthalt *) TuerAuf: BOOL; (* Schalter fuer Tueroeffnen. 1: Tuer oeffnen; 0: zu! *) END_VAR VAR_IN_OUT StartStopp: BOOL; (* Kabine faehrt: 1; steht: 0 *) END_VAR VAR_OUTPUT TuerOeffnen: BOOL; (* Motor zur Tuer Oeffnung *) TuerSchliessen: BOOL; (* Motor zum Tuerverschluss *) END_VAR VAR_OUTPUT RETAIN EndeSignal: BOOL; (* Warnsignal fuer Power Off *) END_VAR VAR StationStopp: CTU; (* Standard-FB (Zaehler) fuer Stationseinfahrten *) TuerZeit: TON; (* Standard-FB (Zeitverzoeger.) fuer Kabinenstart *) RichtWeich: SR; (* Standard-FB (FlipFlop) zur Richtungsbestimmung *) END_VAR VAR RETAIN Richtung: BOOL; (* aktuelle Richt: auf- oder abwaerts *) END_VAR

0001: (* System gestartet ? Das beim letzten Beenden aktivierte Endesignal *) (* wird nach Spannungswiederkehr und Aufnahme der Aktivitaet geloescht *)

BahnAn P

EndeSignal R RueckZaehl

0002:

Einfahrt

4.4 Kontaktplan KOP 0003 RueckZaehl: (* Ruecksetzen Zaehler *) StationStopp CTU CU

Q

R 9999

PV

CV

0004:

KabineVerschliessen

0005 Einfahrt: (* Beim Einfahren der Kabine in eine Station wird *) (* der Zaehler hochgezaehlt und gestoppt *) S1 P

StartStopp R

S2 P

StationStopp CTU

S3 P

CU 0

Q

R PV

CV

165

166

4 Die Programmiersprachen der IEC 61131-3

0006: (* Evtl. Richtungswechsel *)

RichtWeich

S1 P

Richtung

S3 P

Richtung

SR S

Richtung Q1

R

0007: (* Tueroeffnen nur nach Kabinenstopp und *) (* nach Betaetigen des Tuerschalters *)

TuerAuf

StartStopp

TuerOeffnen

0008: (* Bahnende und in Station -> POE-Ende *)

BahnAus

StartStopp

EndeSignal S

PoeEnde

0009 KabineVerschliessen: (* Tuerschliessen nach Betaetigen des Tuerschalters *)

TuerAuf

TuerSchliessen N

4.4 Kontaktplan KOP

167

0010: (* Weiterfahrt 10 Sek. nach Betaetigen des Tuerschalters *) TuerZeit TuerAuf

StartStopp

TON T#10s

IN

Q

PT

ET

StartStopp S

0011: (* Kehre zur aufrufenden POE zurueck *)

RETURN

END_FUNCTION_BLOCK

Bsp. 4.44. KOP Programm zur Bergbahn-Steuerung, vgl. auch Bsp. 4.13.

Kommentierung der Bergbahn-Netzwerke. NetzwerkNummer 0001

Kommentierung Bei einer positiven Flanke an der Variablen BahnAn (und nur dann), fließt TRUE. Dadurch wird EndeSignal auf FALSE gesetzt (gemäß Deklaration in einem remanenten Bereich gepuffert); anschließend wird zum Netzwerk RueckZaehl gesprungen. Wurde keine Flanke erkannt, wird mit dem nächsten Netzwerk 0002 fortgefahren.

0002

Springe zu Netzwerk Einfahrt (Netzwerk 0005).

0003

Bei Erreichen dieses Netzwerks erhält der Eingang R fest TRUE. Damit wird die FB-Instanz StationStopp vom Typ CTU rückgesetzt. Die Überlaufvariable PV wird auf 9999 gesetzt. Ausgang Q wird nicht weiter abgeprüft. Fahre mit nächstem Netzwerk 0004 fort.

0004

Springe zu Netzwerk KabineVerschliessen (Netzwerk 0009).

168

4 Die Programmiersprachen der IEC 61131-3

0005

Sobald die Kabine in eine der drei Stationen einfährt, ändert sich eines der entsprechenden Signale S1, S2 oder S3 von FALSE nach TRUE (positive Flanke). Da eine OR-Verknüpfung vorliegt, wird genau in einem solchen Durchgang (und nur dann) CU auf TRUE gesetzt und zählt StationStopp um 1 hoch. Die 0 des ResetEingangs könnte auch weggelassen werden, da dieser Eingang in diesem Netzwerk nicht benötigt wird. Im Fall einer positiven Flanke wird die Kabine über StartStopp angehalten (durch „Rücksetze Spule” erhält die Variable FALSE zugewiesen). Liegt bei keinem der S1-S3 ein FALSEoTRUE-Übergang vor, erhält der CU Eingang des Zählers eine 0; StartStopp bleibt unverändert.

0006

Sobald die Kabine in die Tal- oder Bergstation einfährt, ändert sich eines der entsprechenden Signale S1 oder S3 von FALSEoTRUE. Da eine OR-Verknüpfung vorliegt, wird genau in einem solchen Durchgang (und nur dann) TRUE weitergeleitet. Besitzt Richtung den Wert 1, erhält der RESET-Eingang eine 1 und damit Richtung über den Flipflop-FB RichtWeich eine 0. Im anderen Fall ändert Richtung über den SET-Parameter seinen Wert.

0007

Logische AND-Verknüpfung von TuerAuf und dem negierten Wert von StartStopp. TuerAuf StartStopp Not StartStopp TuerOeffnen 0 0 1 0 1 0 1 1 0 1 0 0 1 1 0 0

Damit wird die Tür nur geöffnet, wenn der Türschalter auf 1 betätigt wurde und der Aufzugsmotor steht. 0008

Logische AND-Verknüpfung von BahnAus mit dem negierten Werte von StartStopp. BahnAus 0 1 0 1

StartStopp Not StartStopp 0 1 0 1 1 0 1 0

EndeSignal 0 1 0 0

Solange der BahnAus Schalter auf TRUE (ein) geschaltet ist und die Kabine in einer Station steht, ertönt das EndeSignal. Dann wird auch nach POE-Ende gesprungen.

4.5 Ladder: eine Variante der KOP Programmierung

169

In allen anderen Fällen wird mit dem nächsten Netzwerk 0009 fortgefahren. 0009

Sobald der Schalter TuerAuf auf FALSE geschaltet wird, erhält TuerSchliessen einen TRUEoFALSE-Übergang. In genau dieser Situation wird TuerSchliessen auf TRUE gesetzt, ansonsten immer auf FALSE.

0010

Sobald der Türschalter auf „zu” (TuerAuf auf FALSE) geschaltet wird und die Kabine sich dabei in einer Station (StartStopp auf FALSE) befindet, wird IN auf 1 gesetzt; damit startet die FB Instanz TuerZeit. Sind 10 Sekunden abgelaufen, ändert sich Q von FALSE auf TRUE. Ist die Tür immer noch geschlossen (TuerAuf auf FALSE), startet die Kabine (StartStopp auf TRUE); wurde die Tür vorher wieder geöffnet, wird TuerZeit rückgesetzt. Ist das Zeitglied nicht gestartet (Q-Ausgang ist FALSE) oder TuerAuf auf TRUE, bleibt StartStopp unverändert. Bei StartStopp handelt es sich um eine RückkopplungsVariable. Der im Öffner verwendete Wert stammt von einer Initialisierung oder einem vorher zugewiesenen Wert. Nach der Spulenzuweisung wird mit dem neuen Wert weitergearbeitet.

0011

Rückkehr zum aufrufenden Programm. Eine Schleifenprogrammierung zum POE-Anfang wäre falsch, da dieser FB (soweit parametriert) zyklisch mit neuen Eingangsparametern aufgerufen wird.

4.5 Ladder: eine Variante der KOP Programmierung Die IEC 61131-3 Sprachen werden länder- und kontinentspezifisch unterschiedlich bevorzugt. Deutsche Programmierer bevorzugen AWL und ST; viele SPSSpezialisten in Frankreich strukturieren ihre Programme mit AS. In Amerika und Asien hingegen ist eine Kombination von AS und KOP, dort Ladder genannt, die bevorzugte Programmierplattform. Der extensive Einsatz dieser beiden Sprachen in vielen Anwenderprogrammen beeinflusste damit nicht unwesentlich die Festlegung der IEC 61131-3. Eine komplette Integration war allerdings nicht möglich, da die IEC 61131-3 bestimmte Basisanforderungen besitzt wie die Instanziierung, welche in Ladder nicht vorgesehen sind. Somit gibt es durchaus eine Überdeckung zwischen der Nom und Ladder (nicht Teil der Norm!), aber auch Unterschiede; beides wird in diesem Kapitel behandelt.

170

4 Die Programmiersprachen der IEC 61131-3

Ladder ist nicht nur die Basissprache für Boolesche Ausdrücke wie in KOP; Ladder findet seinen Einsatz bei Algorithmen aller Datentypen. Dies bedeutet aber, dass eine zusätzliche Funktionalität notwendig ist, um die anderen Datentypen zu unterstützen.

4.5.1 Netzwerkaufbau Ladder Für die Programmierung von Integer und Real- Operationen, neben Bool die beiden wesentlichen Datentypen, kommt die EN/ENO Kombination in Einsatz, siehe dazu Abschnitt 2.7. Der Boolesche Eingangsparameter EN verhindert oder ermöglicht die Ausführung eines Bausteins. Der ENO Ausgangsparameter kontrolliert die Ausführung des Nachfolgebausteins im gleichen Netzwerk; dies entspricht weitgehend der Definition der IEC 61131-3.

Service Routine

Funktionsblock Kommentar

Testzyklus Zähler

Netzwerk Kommentar

Kontrollbit

Befehlskommentar

StBit

Symbolischer Name

B3.0 Physikalische Adresse

Counter UP

(CU)

0 Counter C3:0 Preset

(DN) 100

Bitnummer

Eingangsparameter mit Aktualparameter

Bsp. 4.45. Typisches Ladder Netzwerk mit Funktionsblock, gesteuert über den EN / ENO Mechanismus. Kontakt B3.0 ist mit dem EN Eingang verbunden; der Spule CU wird der Wert von ENO zugewiesen. EN / ENO sind implizit deklariert, d.h. die Bezeichner tauchen nicht im Baustein auf.

Wie bei KOP werden zwischen den beiden Stromschienen über sequentielle und parallele Verbindungen UND und ODER Verknüpfungen programmiert; siehe dazu Abschnitt 4.4.2. Es gibt Öffner, Schließer und Spulen. Statt eines dieser 3 Elemente kann auch ein Modul (FB oder Funktion) aufgerufen werden.

4.5 Ladder: eine Variante der KOP Programmierung

171

(Formal- und Aktual-) Eingangsparameter werden innerhalb des Bausteins platziert. Die Parameterzuweisung erfolgt namentlich (wie Preset in Bsp. 4.45), über eine Konstante (100) oder Speicheradresse (Counter -> C 3:0). Formal- und Aktualparameter werden innerhalb des Blocks angegeben. Einfachen Spulen auf der rechten Seite werden die Werte der Ausgangsparameter zugewiesen. Eine Vorund Nachverschaltung, welche über den ersten Eingangs- und Ausgangsparameter hinausgeht, ist nicht möglich. Ladder bietet eine ganze Reihe von Kommentierungsmöglichkeiten an. Überschriften und Kommentare sind möglich für: -

die Modulbeschreibung (Baustein) die Netzwerkbeschreibung Symbole, welche Hardwareadresse repräsentieren Befehle

4.5.2 Moduladressen und Speicherbereiche Der Instanzspeicherbereich eines Moduls, welches über den symbolischen Namen angesprochen werden kann, wird nicht automatisch generiert. Eine Zahl, nicht ein Symbol, identifiziert ein Modul, diese Zahl wird verwendet, um einen Baustein aufzurufen. Variable werden nicht automatisch verwaltet. Der Programmierer identifiziert den Speicherplatz durch die Vergabe spezieller alphanumerischer Zeichenfolgen; siehe unten. Diesen Speicherorten können symbolische Namen zugeordnet werden, um die Lesbarkeit zu verbessern. Weiterhin gibt es eine Anzahl von vordefinierten Systemvariablen; diese liefern Information und steuern das Systemverhalten, E/A Peripherie, Zähler und Zeitwerte. Der Name eines Speicherbereichs (für Peripherieadressen, Zwischenergebnisse, Parameter oder Standard- FB) besitzt eine mehrstufige Hierarchie.

Datentyp -> Bereichsnummer -> Element -> Unterelement Beispiele:

F5:11 R3:5.DN I:016/05

Bsp. 4.46. Hierarchische Adressierung des Speichers

Der Speicher ist Datentyp- spezifisch aufgeteilt (Elementare Datentypen Integer, Real, Bool; zusätzlich E/A Adressen, Zeiten, Zähler und Kontrollbereiche). Die 3

172

4 Die Programmiersprachen der IEC 61131-3

Beispiele in Bsp. 4.46 adressieren eine Realzahl (Floating Point) „F“, einen Kontrollbereicht „R“ und eine Eingangsbereich „I“. Jeder Datentyp besitzt eine vordefinierte Anzahl von Datenblöcken, „Bereich“ genannt, welcher Datenelemente des gleichen Typs beinhaltet. Solch ein Element kann in weitere Unterelemente aufgeteilt werden. Das erste Beispiel in Bsp. 4.46 spricht das 11. Element des 5. Datenbereichs der Realzahlen an. Das 2. Beispiel adressiert das 5. Element des 3. Kontrollbereichs, darin wird das DONE-Bit (DN) angesprochen. Das letzte Beispiel ist ein Eingangswert auf der Baugruppe 01, Gruppennummer 6, Endnummer 05. Wie man sieht, herrscht eine enge Kopplung zwischen der Namenskonvention und der Hardware Architektur. Wie man Bsp. 4.46 entnimmt, kann Speicher direkt adressiert werden. Weiterhin ist es möglich, mit indirekten Adressen zu arbeiten (Zeiger oder Pointer). Eine indirekte Adresse verweist auf einen Speicherort, in welchem die Adresse des gewünschten Zielspeicherorts zu finden ist.

R4.0

Quelle Ziel

N[N3:0]:2 N4:[N7:0]

8

Integer Datenblock 3, Element 0

DN

Speicher, Integer Datenblöcke

Operand

Integer Datenblock 8, Element 2

Bsp. 4.47. Indirekte Adressierung. Die Adresse verweist auf einen Speicher, welcher die aktuelle Adresse beinhaltet. „[ ]“ wird zur Kennzeichnung einer indirekten Adresse verwendet.

In Beispiel 4.47 enthält die über N3:0 indirekt angesprochene Integer Speicherzelle eine 8. Diese 8 ersetzt N[3:0] und man erhält N8:2 als gewünschte Quell- Operandenadresse. Das Ziel befindet sich im 4. Integer Datenblock; die zugehörige Elementnummer ist im Datenblock 7, Element 0 zu finden.

4.5 Ladder: eine Variante der KOP Programmierung

173

Durch die Festlegung der physikalischen Speicheradresse über den Namen ist es nicht, wie bei der IEC 61131-3, notwendig, Variable zu deklarieren. Der numerische Teil des Namens legt die physikalische Adresse fest und der führende Buchstabe legt den Datentyp fest: O: Ausgang (Output); I: Eingang (Input); S: Status; B: Binär; T: Zeitgeber (Timer); C: Zähler (Counter); R: Kontrolle (Control); N: Integer; F: Real (Floating Point). Wie man sieht, kann über den Namen nicht nur eine Variable mit einem elementaren Datentyp festgelegt werden. Auch Parameter von Zeitgebern (T5.0) und Zähler (C3:0) können referenziert werden. Die Instanzen der Zähler und Zeitgeber laufen asynchron zum Anwenderprogramm (separate Task). Es ist nicht notwendig, diese Instanzen in jedem Zyklus aufzurufen, sie werden vom System verwaltet, was einen wesentlichen Unterschied zur IEC 61131-3 darstellt. So ist es mit Ladder möglich, die Parameter dieser Standard-FBs zu verwenden, ohne die FBs vorher aufgerufen zu haben; es reicht, die FB- Nummer und den Parameternamen anzugeben. Alle Programme und Datenblöcke sind über Nummern identifiziert, was deutlich von der IEC 61131-3 abweicht. Wie bei der IEC 61131-3 ist es möglich, einen FB mit unterschiedlichen Datensätzen aufzurufen, was den verschiedenen Instanzen eines FBs entspricht. Bei Ladder wird dies durch das Konzept der indirekten Adressierung erreicht. Vor dem Aufruf des FBs wird die Basisadresse des gewünschten Datenblocks an eine vom Programm definierte Adresse geschrieben. Die POE verwendet bei ihrer Abarbeitung die jeweils gewünschte Basisadresse, festgelegt in diesem indirekten Speicherverweis, und addiert darauf für alle Instanzen den gleichen Index (offset). Wird beispielsweise in einer POE die Adresse N[N5:0]:7 verwendet, so ist vor dem Aufruf in die Speicherstelle N5:0 die Basisadresse des Datenblocks zu schreiben, welcher die Instanzdaten des aktuell gewünschten Bausteins enthält. Nach dem Auslesen der Basisadresse wird das 7. Element dieses indirekt spezifizierten Speicherbereichs angesprochen. Wird eine weitere Instanz des Bausteins benötigt, muss vorher die Adresse N5:0 mit der neuen Basisadresse beschrieben werden.

174

4 Die Programmiersprachen der IEC 61131-3

4.6 Ablaufsprache AS Die Ablaufsprache AS wurde definiert, um eine komplexe Aufgabe in überschaubare Einheiten zu zerlegen und den Kontrollfluss zwischen diesen Teilen zu beschreiben. Dabei können sequentiell und parallel ablaufende Prozesse formuliert werden. Die Ausführungszeitpunkte dieser Einheiten unterliegen statischen (durch das Programm vorgegeben) und/oder dynamischen (Änderung von Eingängen) Bedingungen. Die Einheiten selbst werden in einer der anderen vier Sprachen programmiert oder können auch wieder in AS dargestellt werden. AS ist eine Weiterentwicklung der Schrittkettenprogrammierung (mit „Schrittbausteinen”) und wurde von der Petrinetz-Programmierung stark beeinflusst. Das erste Programmiersystem, das weltweit das Prozessverhalten mit Hilfe von Zuständen und Übergängen beschrieb, war Grafcet (von Telemechanique, Frankreich). Diese Sprache war die Grundlage für die internationale Norm IEC 848 und wurde weiterführend in die IEC 61131-3 Sprache AS aufgenommen. Für eine AS-Strukturierung eignen sich besonders Prozesse mit schrittweisem Zustandsverhalten: z.B. ein chemischer Mischprozess, bei dem die Substanzen zugeführt werden, bis die Sensoren den gewünschten Füllstandsgrad melden (Schritt 1). Nach der Abschaltung der Zuführung wird ein Mischer angestoßen (Schritt 2). Ist der Mischungsgrad erreicht, wird der Motor gestoppt und der Leerungsprozess beginnt (Schritt 3). Ein weiteres typisches Beispiel für ein schrittweises Zustandsverhalten ist die Waschmaschine. Sie arbeitet in Phasen (Schritten) wie Vorwaschen, Hauptwäsche, Spülen usw., in denen jeweils unterschiedlich definierte Arbeiten verrichtet werden. Endet eine solche Phase (durch eine Zeit- oder Sensorbedingung), wird ein Nachfolgeschritt mit anderen seriellen und parallelen Vorgängen angestoßen. Diese werden solange (zyklisch) ausgeführt, bis die Endebedingung dieses Schritts eintritt. AS ist eigentlich eine grafische Programmiersprache, kann jedoch auch textuell programmiert werden. Der Anwender wird zur Darstellung der Programmstruktur die grafische Variante benutzen, da sie die Zusammenhänge wesentlich übersichtlicher wiedergibt. Die textuelle Darstellung dient eher der Archivierung und Portierung von ASstrukturierten POEs. Zur Formulierung der einzelnen Elemente (Transition, Aktion; siehe unten) werden sowohl die grafische als auch die textuelle Form verwendet.

4.6 Ablaufsprache AS

175

Funktionsbausteine und Programme können, müssen aber nicht in AS strukturiert sein, Funktionen dürfen aufgrund von statischer Information keine AS-Struktur besitzen. Falls AS-strukturiert, muss die gesamte POE in AS formuliert sein. Die Regeln über die Verwendung von Kommentar entsprechen den restlichen Sprachen. In der textuellen Form kann mit einem Klammer/Stern Konstrukt (* Kommentar *) an alle Stellen Kommentar geschrieben werden, an denen auch Leerzeichen erlaubt sind. Für die grafische Form gibt es keine Vorschriften; hier ist herstellerspezifisch Kommentar in den Zeichnungen zu finden.

4.6.1 Aufbau durch Schritte und Transitionen Wie die beiden anderen grafischen Sprachen KOP und FBS besteht auch AS aus Netzwerken. Eine POE kann ein oder mehrere Netzwerke besitzen. Die Elemente eines Netzwerks bestehen aus sogenannten Schritten und Transitionen. Ein Schritt ist entweder aktiv oder inaktiv. Er verweist auf eine Anzahl von Anweisungen, die durchzuführen sind, solange dieser Schritt aktiv ist. Wann ein solcher Schritt inaktiviert werden soll, entscheidet eine Transition am Ausgang des Schritts mit Hilfe der Transitionsbedingung, einem booleschen Ausdruck. Verbindungen mit definierter Richtung beschreiben, welcher Schritt oder Schritte danach aktiv geschaltet werden sollen. Das Bsp. 4.48 zeigt ein AS-Netzwerk aus Schritten (Rechtecke), Transitionen (Querstrich mit Bezeichner) und Verbindungen. Die rechte Hälfte beschreibt skizzenhaft den prinzipiellen Ablauf der Aktivitäten. Beim Aufruf der POE wird der gesondert gekennzeichnete Schritt (Ein) aktiv. Es werden alle ihm zugewiesenen Anweisungen (im Bild weggelassen) durchgeführt. Erhält die boolesche Variable EinFertig aufgrund einer Berechnung oder durch Änderungen der E/A Peripherie TRUE zugewiesen, wird Ein anschließend inaktiv geschaltet und die nachfolgenden Schritte Simultan1 und Simultan2 aktiviert. Nun werden deren Anweisungen bearbeitet und danach die Variable SimultanFertig auf TRUE abgefragt. Diese Abarbeitung erfolgt zyklisch, bis der TRUE-Zustand von SimultanFertig festgestellt wird. Danach sind die beiden Simultanschritte inaktiv und der Schritt Zusammen wird aktiv. NeueSchleife entscheidet nun über den Zeitpunkt eines erneuten Schleifendurchgangs, der bei Ein fortgesetzt wird. Mit der Freigabe einer Transition wird das Aktiv-Attribut (auch Token genannt) von einem aktiven Schritt an seine(n) Nachfolger weitergereicht. Dieses AktivAttribut “wandert” somit durch die einzelnen Schritte, vervielfältigt sich bei Parallelverzweigungen und kommt wieder zusammen. Es darf weder vollständig „verloren gehen”, noch ist eine unkontrollierte Verbreitung erlaubt. Die grafischen Objekte, über die dieses Attribut weitergereicht wird, sind Gegenstand des nächsten Abschnitts.

176

4 Die Programmiersprachen der IEC 61131-3

1)

Ein

2) TRUE

FALSE

EinFertig

Simultan1

Simultan2

3)

4)

SimultanFertig Zusammen FALSE

NeueSchleife

5)

TRUE

6)

FALSE

TRUE

Bsp. 4.48. Links: Ein einfaches AS-Netzwerk. Rechte Hälfte: Darstellung des Ablaufs in diesem Netzwerk in Schritten von 1) bis 6): Ein aktiver Schritt (1) wird inaktiv, sobald die Nachfolgetransition den Wert TRUE besitzt (2). Dadurch werden die nachfolgenden Schritte aktiviert (3) usw., bis das Netzwerk wieder beim Anfangsschritt (1) beginnt.

4.6.2 Ablaufketten Schritte und Transitionen müssen sich stets abwechseln; es dürfen keine zwei vom gleichen Typ direkt miteinander verbunden werden. Eine Transition kann mehrere Vorgänger- und Nachfolgeschritte besitzen. Eine einfache Folge von Schritten / Transitionen wird Ablaufkette genannt. Es ist möglich, nach einem Schritt eine von mehreren Ketten (Alternativketten) oder mehrere Ketten gleichzeitig (Simultanketten) zu aktivieren. Die dazugehörigen Regeln sind in folgender Tab. 4.14 zusammengestellt.

4.6 Ablaufsprache AS Grafische Darstellung

177

Namen mit Kommentierung Einfache Kette: Einzelelement Zusammenstellung von Schritt o Transition o Schritt in Folge SO a wird inaktiv, sobald Trans gleich TRUE. SU a wird aktiv, sobald Trans gleich TRUE.

SO Trans SU

Alternativ-Kettenauswahl: SO

*

Trans2

Trans1 SU1

SU2

T... SU3

Alternativ-Kettenauswahl, anwenderpriorisiert:

SO 2 SU1

a

*

Trans1

Auswahl einer Folgeschrittkette. Ist SO aktiv, erfolgt eine Auswertung der Transitionen von links nach rechts (durch den Stern * gekennzeichnet). Die erste Transition mit TRUE inaktiviert SO und schaltet ihren Nachfolgeschritt aktiv.

1 SU2

Trans2

3

T...

SU3

entspricht der Alternativ-Kettenauswahl mit der Ausnahme, dass der Anwender durch die Angabe von Zahlen die Reihenfolge der TransitionsAuswertungen steuern kann; die niedrigste Zahl besitzt die höchste Priorität.

SO: Schritt Oberhalb der Transition SU: Schritt Unterhalb der Transition

Tab. 4.14. Zusammenstellung von Schrittketten. Den Transitionen gehen Vorgängerschritte (SO) voraus und folgen Nachfolgeschritte (SU). Durch Kombination dieser Ketten können komplexe Netzwerke aufgebaut werden (wird fortgesetzt).

178

4 Die Programmiersprachen der IEC 61131-3

Kettenauswahl, willkürliche Reihenfolge: SO

Trans2

Trans1 SU1

SU2

T... SU3

entspricht der Alternativ-Kettenauswahl mit der Ausnahme, dass die Transitionen in keiner vorgegebenen Reihenfolge berechnet werden. Der Anwender muss dafür sorgen, dass sich die einzelnen Transitionen gegenseitig ausschließen und sich damit das Programm deterministisch verhält.

Zusammenführung Alternativ-Kettenauswahl: SO1

SO2 Trans1

SO3 Trans2

T...

SU

Die Pfade einer Alternativ-Kettenauswahl werden zusammengeführt. Sobald einer der SO aktiv ist und die zugehörige Transitionsbedingung TRUE liefert, erfolgt eine Deaktivierung des Schritts und die Aktivierung von SU.

Simultan-Verzweigung: Gemeinsame Freigabe von mehreren Schrittketten. Ist SO aktiv und Trans liefert TRUE, wird SO inaktiv. Alle von Trans abhängigen Schritte SU werden aktiviert. Die neu aktivierten Teilnetzwerke laufen unabhängig voneinander ab.

SO Trans

SU1

SU2

SU3

Zusammenführung Simultan-Verzweigung: SO1

SO2

SO3

Trans SU

a b

SO: Schritt Oberhalb der Transition SU: Schritt Unterhalb der Transition

Tab. 4.14. (Fortsetzung)

Die Pfade einer Simultan-Verzweigung werden zusammengeführt. Sobald alle der SO aktiv sind und die zugehörige Transitionsbedingung Trans TRUE liefert, erfolgt eine Deaktivierung der Schritte und die Aktivierung von SU.

4.6 Ablaufsprache AS

179

Kettenschleife (Rückführung): Eine Transition (im Beispiel TransM22) führt zu einem Vorgängerschritt zurück. Die Transitionsbearbeitung erfolgt in gleicher Weise wie bei der Alternativ-Kettenauswahl. Zusätzlich zum Beispiel links sind auch die Arten “anwenderpriorisiert” (mit *) und “willkürlich” möglich. Um den Kontrollfluss besser darstellen zu können (z.B. von TransM22 nach SM1), sind Richtungspfeile erlaubt.

SO TransO

SM1 TransM1 SM2

* TransM21

TransM22

SU

Kettensprung Trans1

Trans2

SU1

Trans3

a b

Enthält ein Pfad einer Kettenauswahl (gilt für alle drei Typen) keinen Schritt (sondern nur eine Transition), heißt dieser Pfad Kettensprung (rechts nach Trans2).

SO: Schritt Oberhalb der Transition SU: Schritt Unterhalb der Transition

Tab. 4.14. (Fortsetzung)

Wie später zu sehen ist, gibt es nur für die Alternativ-Kettenauswahl eine textuelle Repräsentation. Die anwenderpriorisierte und die willkürliche Variante lassen sich textuell nicht darstellen (keine Portierung in textueller Form möglich).

180

4 Die Programmiersprachen der IEC 61131-3

Näher zu betrachten sind die unsicheren Netzwerke. Darunter versteht man Netzwerke, in denen sich die Aktivierung von Schritten unkontrolliert außerhalb einer Simultanverzweigung verbreitet; siehe dazu Bsp. 4.49. Besitzt ein Netzwerk Teilbereiche, die aufgrund der Netzwerklogik nie aktiviert werden können, spricht man von unerreichbaren Netzwerken. Beide Arten sind mit den eben vorgestellten Schrittketten programmierbar. Sie werden in der Norm als fehlerhaft angesehen und müssen vom Programmiersystem oder dem SPS-Betriebssystem erkannt bzw. vermieden werden:

S1

S1

S2

S3

t4

S2

t5

S4

S3

S5

t5

t2_4 S4

t11

a) Unsicheres Netzwerk

S5

S6

t1

b) Netzwerk mit unerreichbarer Ablaufkette

Bsp. 4.49. Zwei Netzwerke, die zwar in AS syntaktisch definierbar sind, semantisch jedoch als fehlerhaft angesehen werden und deshalb vom Programmiersystem bzw. dem Laufzeitsystem der SPS nicht zugelassen werden dürfen.

Werden in Bsp. 4.49 a) nach S1 die Schritte S2 und S3 aktiviert, schaltet danach t5 und t11 sperrt (damit bleibt S2 aktiv), kann über eine S5 o S1 Aktivierung S2 erneut “aktiviert” werden, obwohl S2 diesen Zustand bereits besitzt. Das Aktiv-

4.6 Ablaufsprache AS

181

Attribut hat sich unkontrolliert vervielfältigt. Man spricht daher von einem unsicheren Netzwerk. In Bsp. 4.49 b) verklemmt sich das System nach einer Schrittfolge von S3 o S5, da t1 auf einen aktiven Schritt S6 wartet. Der kann nicht aktiv geschaltet werden, da t2_4 auf S4 wartet. t4 wird aber nicht freigeschaltet, da die andere Alternative gewählt wurde. Somit ist der benötigte Zustand mit aktiven Schritten S5 und S6 (damit t1 schalten kann) nicht erreichbar. Die Überprüfung der Sicherheit von Netzwerken wäre einfach, solange nur sicherzustellen ist, dass keine Verbindung aus einer Simultanverzweigung führt (außer der Simultanzusammenführung). Es gibt jedoch Netzwerke, die diese Einschränkung nicht besitzen und dennoch erreichbar und sicher sind. Die Norm beschränkt sich derzeit auf den Vorschlag eines Reduktions-Algorithmus ([DIN EN 61131-8 TR]), der unsichere bzw. unerreichbare Netzwerke erkennen kann. Es gibt jedoch Netzwerke, welche von diesem Algorithmus zurückgewiesen werden, die trotzdem erreichbar und sicher sind. Bsp. 4.50 zeigt ein solches Netz.

S1

S2

S4

S3

S5

S8

S6

S7

S9

Bsp. 4.50. Sicheres Netzwerk, trotz eines Sprungs aus einer Simultanverzweigung

182

4 Die Programmiersprachen der IEC 61131-3

4.6.3 Detail-Beschreibung der Schritte und Transitionen Die beiden Grundelemente von AS sind: 1) Schritte, 2) Transitionen. Der Schritt steht für eine Situation, in der Anweisungen bearbeitet werden, solange er aktiv ist. Den Zeitpunkt der (De-) Aktivierung bestimmt die zugehörige Transition mit ihrer Transitionsbedingung. Sie beschreibt, wann der aktuelle Schritt verlassen und ein (oder mehrere) Nachfolgeschritt aktiviert werden soll(en). Jeder Transition ist eine Transitionsbedingung zugewiesen. Dies ist eine Berechnungsvorschrift, programmiert in einer der anderen vier IEC 61131-3Sprachen, die einen booleschen Wert liefert. Schritt. Ein Schritt wird grafisch durch ein Rechteck dargestellt.

Bezeichner

Verbindung zum Aktionsblock (kann entfallen) Schritt-Name

liefert aktuellen Wert des Schrittmerkers

a) grafische Variante

STEP Bezeichner: (* Schrittrumpf, Aktionsbeschreibung siehe Bsp. 4.55 *) END_STEP b) textuelle Variante Abb. 4.17. Schritt (STEP) mit beiden Darstellungs-Varianten grafisch (a) und textuell (b)

4.6 Ablaufsprache AS

183

Der Schrittname identifiziert einen Schritt. Der Schrittmerker ist ein boolescher Wert, der vom System aus zur Verfügung steht und den Zustand (aktiv / nicht aktiv) des Schritts (Schrittmerker gleich TRUE / FALSE) beschreibt. Dieser Wert: -

wird zur Steuerung der im Schritt ablaufenden Aktionen verwendet (siehe nächster Abschnitt), kann vom Anwenderprogramm über eine Systemvariable, die implizit deklariert ist, abgefragt werden; siehe Abb. 4.18.

Eine zweite vom System zur Verfügung gestellte Variable liefert den Zeitwert, der seit dem Aktivierungszeitpunkt verstrichen ist (falls bisher nicht aktiv: 0; falls nicht mehr aktiv: Zeitdauer der letzten Aktivschaltung). Diese Variable Schrittzeit ist vom Typ TIME.

Schrittname.X Schrittname.T

Schrittmerker (Variable für Schrittzustand) Schrittzeit (Variable für bisherige Aktivzeit)

Abb. 4.18. Zugriff auf Schrittmerker und Schrittzeit über Variablennamen; der Wert wird vom System zur Verfügung gestellt.

Beim Einsprung in eine AS-strukturierte POE kann auf die alten Werte der Schrittzeit (Werte der letzten Ausführung) nur zugegriffen werden, wenn die POEInstanz als gepuffert deklariert wurde. Schrittname, -Merker und -Zeit sind in der gesamten (und nur in dieser) POE bekannt. Das Anwenderprogramm kann darauf nur lesend zugreifen. Ein Schritt wird aktiv, sobald ihn die Transition, mit der er an der oberen Eingangslinie verbunden ist, freischaltet (Transitionsbedingung ist TRUE). Er wird inaktiv, sobald der Berechnungswert der Transition, die mit der unteren Ausgangslinie des Schritts verbunden ist, den booleschen Wert TRUE liefert. Der in der IEC 61131-3 verwendete Begriff des “aktiven Schritts” ist etwas missverständlich. Ein aktiver Schritt kann z.B. eine Aktion mit Zeitverzögerung starten. Durch die Freigabe der Nachfolgetransition wird der nächste Schritt aktiviert. In dem nunmehr inaktiven Schritt beginnt nach der Zeitverzögerung die Aktion, es “passiert” also etwas in diesem Schritt, obwohl bereits sein Nachfolger aktiviert wurde. Eine besondere Stellung nimmt der Anfangsschritt jedes Netzwerks ein, der beim Aufruf einer POE bzw. beim Start über die Konfiguration zuerst aktiviert wird. Besitzt die POE mehrere Netzwerke, sind beim Aufruf mehrere Anfangsschritte aktiv; die Netzwerke laufen dann bis auf die vom Anwender programmierten Synchronisationspunkte unabhängig voneinander ab.

184

4 Die Programmiersprachen der IEC 61131-3 nur erforderlich, wenn Vorgänger (z.B. bei einer Netzschleife )

Bezeichner Schritt-Name

a) grafische Variante

INITIAL_STEP Bezeichner: (* Schrittrumpf, Aktionsbeschreibung siehe Bsp. 4.64 *) END_STEP b) textuelle Variante Abb. 4.19. Anfangsschritt in beiden Darstellungs-Varianten grafisch (a) und textuell (b)

Der Anfangsschritt kann ein beliebiger Schritt innerhalb des Netzwerks sein, solange damit keine der in Abschn. 4.6.2 beschriebenen Regeln verletzt wird (unsicheres oder unerreichbares Netzwerk). Besitzt er im Netzwerk keinen Vorgänger, entfällt die eingehende Linie. Transition. Eine Transition besteht (im grafischen Fall) aus einer eingehenden Linie (Verbindung von Schritten), einer Transitionsbedingung und einer ausgehenden Linie (Verbindung zu einem oder mehreren Schritten). Die Transitionsbedingung stellt eine Berechnungsvorschrift dar, die einen booleschen Wert liefert. Eine Transition schaltet (frei), wenn folgende Bedingungen erfüllt sind: 1) alle Schritte, die direkt mit der eingehenden (oberen) Linie verbunden sind, sind aktiv, 2) die Transitionsbedingung liefert den booleschen Wert TRUE. Bei einer grafischen Darstellung des Netzwerks kann die zugehörige Transitionsbedingung auf drei Arten angegeben werden, siehe auch nachfolgende Abbildungen: 1) Die Transitionsbedingung steht direkt neben der Transition (direkte Angabe), 2) Konnektoren verbinden die Transition und Transitionsbedingung, 3) Transitionsnamen identifizieren Transition und Transitionsbedingung.

4.6 Ablaufsprache AS

Grafische Darstellung:

185

Beispiel:

Vorgängerschritt(e)

Schritt_10

ST-Ausdruck

Var1 & Var2

Nachfolgeschritt(e)

Schritt_11

a) Transitionsbedingung in ST Vorgängerschritt(e)

Schritt_10 Var1

KOP Netzwerk

Var2

Nachfolgeschritt(e)

Schritt_11

b) Transitionsbedingung in KOP Vorgängerschritt(e) Var1

FBS Netzwerk

Nachfolgeschritt(e)

Schritt_10 &

Var2

Schritt_11

c) Transitionsbedingung in FBS d) Transitionsbedingung in AWL nicht formulierbar Abb. 4.20. Transition (grafisch), Darstellungsart: direkte Angabe. Die Transitionsbedingungen werden als boolesche Ausdrücke / Teilnetzwerke (ohne Marke) in einer der anderen IEC 61131-3 Sprachen (nicht AWL und AS) formuliert.

186

4 Die Programmiersprachen der IEC 61131-3

Die Transitionsbedingung kann, wie in Abb. 4.20 gezeigt, direkt angegeben werden. Es kann an Stelle der Bedingung auch ein Konnektor verwendet werden. Der von einem Teilnetzwerk erzeugte Wert wird über den Konnektor an die Transition „weitergeleitet”:

Grafische Darstellung:

Beispiel:

Var1

FBS &

Var2 Kon1 oder

KOP/FBS-Netzwerk

KOP

Konnektor Var1

Var2 Kon1

Vorgängerschritt(e) Schritt_10

Konnektor Kon1

Nachfolgeschritt(e)

Schritt_11

Abb. 4.21. Transition (grafisch); Darstellungsart mit Konnektoren. Der in einem KOP oder FBS-Netzwerk berechnete Wert wird über einen Konnektor mit der Schrittsequenz verbunden. Hier ist die Transitionsbedingung weder in AWL noch in ST formulierbar.

Bei der dritten Variante wird über den Transitionsnamen eine Verbindung zwischen der Transitionsbedingung und der Schrittsequenz hergestellt. Dies hat den Vorteil, dass auch AWL und ST zur Formulierung der Transitionsbedingung verwendet werden können. Außerdem kann eine Transitionsbedingung für mehrere Transitionen verwendet werden, soweit die gleichen Weiterschaltbedingungen vorliegen, vgl. Abb. 4.22.

4.6 Ablaufsprache AS

187

Grafische Darstellung: Textuelle Repräsentanz: SBezeichner (Vorgängerschritt(e))

TBezeichner

TRANSITION TBezeichner FROM SBezeichner TO SBezeichner: (* Boolescher Ausdruck, AE -Wert oder Teilnetzwerk, in ST, AWL KOP oder FBS formuliert *)

SBezeichner (Nachfolgeschritt(e))

Abb. 4.22. Transition (grafisch/textuell); Darstellungsart mit Transitionsnamen; SBezeichner steht für Schrittnamen, TBezeichner für Transitionsnamen.

Transitionsangabe in der Grafik:

Beschreibung der Transition:

TRANSITION TranName FROM Schritt_10 TO Schritt_11: Schritt_10

TranName

Schritt_11

Var1

&

FBS

Var2 TranName END_TRANSITION TRANSITION TranName FROM Schritt_10 TO Schritt_11: Var1

Var2 TranName

KOP

END_TRANSITION

TRANSITION TranName FROM Schritt_10 TO Schritt_11: LD Var1 AND Var2

AWL

END_TRANSITION TRANSITION TranName FROM Schritt_10 TO Step_11: := Var1 & Var2; ST END_TRANSITION

Bsp. 4.51. Beispiele für Transitionsbedingungen mit Angabe des Transitionsnamen

188

4 Die Programmiersprachen der IEC 61131-3

Bsp. 4.51 erklärt die Verwendung der Transitionsnamen für alle vier Programmiersprachen. Die IEC 61131-3 definiert 2 weitere Varianten für AWL und ST. Hierbei entfällt der Transitionsnamen. Es gilt zu beachten, dass in dieser AWL Variante das Programmiersystem bei einer grafischen Rückübersetzung aus der textuellen Beschreibung einen eigenen Transitionsnamen generieren muss, da in AWL keine direkte Angabe der AWL Zeilen neben der grafischen Transitionsbedingung erlaubt ist.

TRANSITION FROM Bezeichner TO Bezeichner : (* AWL-Anweisungen; letzte Zeile (AE) liefert booleschen Wert *) END_TRANSITION

Beispiel: TRANSITION FROM Schritt_10 TO Schritt_11 : LD Var1 AND Var2 (* AE liefert booleschen Wert *) END_TRANSITION

Abb. 4.23. Textuelle Transitionsbeschreibung in AWL. Es können auch mehrere Schritte in Klammern, durch Kommata getrennt, angegeben werden.

TRANSITION FROM Bezeichner TO Bezeichner := (* ST-Ausdruck *) END_TRANSITION

Beispiel 1: TRANSITION FROM Schritt_10 TO Schritt_11 := Var1 & Var2; END_TRANSITION

Beispiel 2 mit mehreren Vorgänger- und Nachfolgerschritten: TRANSITION FROM (S_1, S_2, S_3) TO (S_4, S_5) := Var1 & Var2; END_TRANSITION

Abb. 4.24. Textuelle Transitionsbeschreibung in ST. Es können auch mehrere Schritte in Klammern, durch Kommata getrennt, angegeben werden.

Innerhalb eines Blocks zur Bestimmung einer Transitionsbedingung darf keine andere Zuweisung als an den Transitionsnamen erfolgen (z.B. keine Zuweisung an eine Variable) und kein FB-Aufruf, der seinerseits schreibende Operatoren besitzen könnte; die Verwendung von Funktionen ist möglich. Transitionen werten Bedingungen aus; Zuweisungen werden in Aktionen vorgenommen.

4.6 Ablaufsprache AS

189

4.6.4 Schrittbearbeitung durch Aktionsblöcke und Aktionen Während bzw. auch nach der Aktivzeit eines Schritts sollen bestimmte Aktivitäten ablaufen. Diese Anweisungen sind in sogenannten Aktionsblöcken festgehalten. Ein Aktionsblock beschreibt, welche Aktion unter welcher Bedingung (Bestimmungszeichen: Anlauf sofort, mit Zeitverzögerung, ...) ausgeführt werden soll. In einfachen Aktionsblöcken werden boolesche Variablen (boolesche Aktionen) gesetzt oder rückgesetzt (dienen der Prozess-Synchronisation); siehe Bsp. 4.52. Komplexe Aktionsblöcke enthalten oder verweisen auf Befehlsfolgen oder Netzwerke, formuliert in einer der IEC 61131-3 Sprachen; siehe Bsp. 4.53.

S

Ein

Verriegel

Zwei

Not Verriegel . . .

Verriegel . . .

SimultanFertig Zusammen

NeueSchleife

Nw2Fertig Freischalten

R

Verriegel

Weiter

Bsp. 4.52. Zwei AS Netzwerke, die sich über die boolesche Aktion Verriegel mit den Bestimmungszeichen SET/RESET (Setze auf TRUE / Rücksetze auf FALSE) synchronisieren.

Beim Aufruf der POE setzt das linke Netzwerk die boolesche Variable Verriegel auf TRUE. Damit sperrt die nachfolgende Transition. Das rechte Netzwerk kann dagegen fortfahren. Im Schritt Freischalten wird Verriegel wieder auf FALSE rückgesetzt. Damit kann das linke Netzwerk fortfahren.

190

4 Die Programmiersprachen der IEC 61131-3

Schritt Bestimmungszeichen N Ein

ErsteAktion

Aktionsname

LD TRUE ST Led ST EinFertig

Aktion Aktionsblock

EinFertig

..

Transition

..

Bsp. 4.53. Ausschnitt aus dem AS-Netzwerk von Bsp. 4.48, erweitert um einen (nicht booleschen) Aktionsblock für den Schritt Ein.

Mit dem Aktionsblock von Bsp. 4.53 wird die Aktivität festgelegt, die bei der Aktivierung von Schritt Ein auszuführen ist. In die Variable Led wird TRUE gespeichert (um beispielsweise einen Lichtschalter anzuschalten), ebenso in die Variable EinFertig. Der Wert dieser Variablen ist die Transitionsbedingung am Ausgang des Schritts. Die Aktions-Anweisungen dieses Beispiels werden daher nicht zyklisch ausgeführt, sondern der Schritt inaktiv geschaltet und die nachfolgenden Schritte aktiviert. Somit ergibt sich in einem AS strukturierten Netzwerk folgende Hierarchie:

Netzwerk 1

Aktionsblock s

Zeitbedingung

. . .

Aktionsverweis

Schritt j

. . .

. . .

Trans. J

Aktionsblock t

Zeitbedingung

Schritt a Trans. A

. . . Netzwerk x

NetzwerkVerbindung

Hilfsvariable

Aktionsverweis Hilfsvariable

Abb. 4.25. Aufbauhierarchie einer AS-strukturierten POE

Aktion 1: ... Aktion 2: ... Aktion 3: ... . . .

4.6 Ablaufsprache AS

191

4.6.5 Detailbeschreibung Aktionen und Aktionsblöcke

Aktionen. Aktionen werden verwendet, um 1) die Berechnungsvorschrift für einen Schritt zu beschreiben oder 2) Aktivitäten in einem KOP- oder FBS-Netzwerk zu beschreiben, die unter besonderen Voraussetzungen ablaufen. Die meisten Programmiersysteme bieten nur die erste Beschreibungsart. Eine Aktion stellt dar: 1) eine Zuweisung an eine boolesche Variable (boolesche Aktion) oder 2) einen Anweisungsteil (Aktion oder Anweisungs-Aktion), formuliert in AWL, ST, KOP, FBS oder wieder als AS-strukturiertes Teilnetzwerk. Handelt es sich um eine boolesche Aktion, erfolgt eine Wertzuweisung an eine vom Anwender deklarierte Variable (VAR, VAR_OUTPUT, ...; sie muss gemäß Deklarationsblock beschreibbar sein), die den Namen der Aktion trägt. Im Fall einer Anweisungs-Aktion erfolgt solange die zyklische Bearbeitung des assoziierten Anweisungsstücks, wie die Ausführungsbedingung dies vorschreibt. Aktionsblock. Eine Aktion, zusammen mit ihrer Ausführungsbedingung (Bestimmungszeichen) und Rückkopplungsvariable wird in der grafischen Darstellung Aktionsblock genannt. Textuell gibt es ein entsprechendes Äquivalent; siehe dazu Abb. 4.26.

192

4 Die Programmiersprachen der IEC 61131-3

Bestimmungszeichen

Aktionsname

a) Einfacher grafischer Aktionsblock

Bestimmungszeichen

Aktionsname

Rückkopplungsvariable

Anweisungen der Aktion in KOP, FBS, AWL, ST, AS

b) Grafischer Aktionsblock mit angehängtem Anweisungsteil

Bestimmungszeichen

Aktionsname

Rückkopplungsvariable

Aktionsname Anweisungen der Aktion in KOP, FBS oder AS

c) Grafischer Aktionsblock mit separatem Anweisungsteil

Verwendung (Aufruf) der Aktion

Aktionsname (Bestimmungsz. ggfs. mit Parametern, Rückkopplungs-Var.) ... ACTION Aktionsname: (* Anweisung der Aktion; programmiert in einer der *) (* textuellen IEC 1131-3 Sprachen *) END_ACTION Definition der Aktion

d) Textueller Aktionsblock mit separatem Anweisungsteil Abb. 4.26. Vier Alternativen zur Aktionsblock- bzw. Aktions-Darstellung

4.6 Ablaufsprache AS

193

Zur Aktionsblock- bzw. Aktions-Darstellung gibt es die vier in Abb. 4.26 gezeigten Alternativen: a) Die Ausführungsbedingung (Bestimmungszeichen) und der Aktionsnamen wird Aktionsblock genannt. b) wie Variante a), erweitert um die (optionale) Rückkopplungsvariable und den Anweisungsteil, programmiert in KOP, FBS, AWL, ST oder AS. c) Äquivalente Darstellung zu b). Die Aktion wird allerdings nicht innerhalb des Blocks, sondern an einer anderen Stelle des Programms beschrieben (Darstellungsart für die grafischen Sprachen KOP, FBS oder AS). Die Verbindung erfolgt über den Aktionsnamen. d) Textuelle Entsprechung von c). Der Aktionsname mit Bestimmungszeichen und eventuellen Parametern steht innerhalb einer (INITIAL) STEP...END_STEP-Klammerung. Der ACTION...END_ACTION-Block muss dem STEP-Block nicht unmittelbar folgen. Ein Schritt kann ohne einen Aktionsblock (der Schritt wartet lediglich auf Transitionsfreigabe), einen oder mehrere Aktionsblöcke beschrieben werden; siehe Bsp. 4.54 und Bsp. 4.55. Der Gesamtblock der Aktionsblöcke besitzt aber nur eine gemeinsame (Aktivitäts-) Verbindung zum Schritt (Schrittmerker). Wird ein Schritt aktiv, erfolgt bis zur Deaktivierung durch die Folgetransition eine Überprüfung der Ausführungsbedingung. Die Ausführungsbedingung in einem Aktionsblock, Bestimmungszeichen genannt, entscheidet darüber, -

wann die Anweisung ausgeführt (Anfang oder Ende) werden soll oder welchen Wert die beigefügte boolesche Variable (boolesche Aktion) erhält.

Eine detaillierte Beschreibung des Bestimmungszeichens ist Abschn. 4.6.7 zu entnehmen. Der Aktionsname identifiziert eine Aktion mit einem POE-weit gültigen Bezeichner. Er stellt eine boolesche Aktion dar oder verweist auf eine Aktion. Letztere besteht aus Anweisungen. Wann Aktionen zur Ausführung kommen sollen, kann über mehrere Aktionsblöcke (von unterschiedlichen Schritten) gesteuert werden, die diesen Aktionsnamen im Aktionsblock beinhalten. Die Rückkopplungsvariable kann in der Aktion mit einem Zustandswert (z.B. TRUE für “Aktion ist aktiv”) beschrieben werden. Diese Variable wird zwar vom Anwender wie jede andere Variable deklariert, durch die exponierte Stelle im Aktionsblock soll aber gezeigt werden, dass es sich hierbei um eine Größe handelt, die Auskunft über den Schrittzustand geben kann. Meist wird sie verwendet, wenn der Anweisungsteil einer Aktion nicht direkt in der Grafik, sondern als Text an einer anderen Stelle hinterlegt ist oder die Aktion wieder eine AS-Struktur ist.

194

4 Die Programmiersprachen der IEC 61131-3

Es werden keinerlei automatische Wertzuweisungen durch das System durchgeführt; sie unterliegt allein der Kontrolle des Programmierers, der sie in einer Anweisungs-Aktion explizit oder als boolesche Aktion über das Bestimmungszeichen ändern kann. Im Anweisungsteil eines Aktionsblocks werden Anweisungen formuliert. Die Rückkopplungsvariable und der Anweisungsteil können entfallen. Entfällt die Rückkopplungsvariable, übernimmt der Aktionsname ihre Aufgabe. Aktionsnamen müssen vom Anwender als boolesche Variable deklariert werden, wenn für sie kein gleichnamiger Aktionsblock definiert ist und sie damit als boolesche Variable interpretiert werden. Folgende Festlegung gilt: 1) Jeder Schritt (alle darin spezifizierten Aktionen) wird nach seiner Aktivierung mindestens einmal durchlaufen. 2) Nach der Deaktivierung wird jeder Schritt (alle Aktionen) nochmals aufgerufen, um Ende-Bedingungen auswerten und darauf reagieren zu können. Manche Programmiersysteme zeigen nur ein Netzwerk mit Schritten und Transitionen. Die Informationen über die zugeordneten Aktionsblöcke werden bei Bedarf (z.B. durch Doppelklick in einem neuen Fenster) dargestellt. Auch dies entspricht der Norm.

4.6.6 Zusammenhang von Schritt, Transition, Aktion und Aktionsblock Die nachfolgenden Beispiele fassen die Begriffe und Erläuterungen für AS zusammen. Danach wird näher auf die Bedeutung des Bestimmungszeichens eingegangen.

4.6 Ablaufsprache AS

195

Schritt_V

TransBedX

Schritt_A

N

AnwTeil

CT

IF (Schritt_A.X AND FehlerTest()) THEN CT := TRUE; ELSE CT := FALSE; END_IF ...

BA OR NOT CT

Schritt_N D t#1s

BoolAction

BA

BA := TRUE;

Bsp. 4.54. Zwei verschiedene Aktionsarten: BoolAction ist eine Aktion zum zeitverzögerten Setzen der Variablen BA. AnwTeil ist eine Anweisungs-Aktion mit einigen darin enthaltenen Anweisungen.

TRANSITION FROM Schritt_V TO Schritt_A := TransBedX; END_TRANSITION TRANSITION FROM Schritt_A TO Schritt_N := BA OR NOT CT; END_TRANSITION STEP Schritt_A: AnwTeil(N, CT); BoolAction(D, t#1s, BA); END_STEP ACTION AnwTeil : IF (Schritt_A.X AND Fehlertest()) = TRUE THEN CT := TRUE; ELSE CT := FALSE; ... END_ACTION

Bsp. 4.55. Das Bsp. 4.54 in textueller Form

Sobald die Transitionsbedingung TransBedX in Bsp. 4.54 freischaltet, wird Schritt_A aktiv. Somit werden die angehängten Bestimmungszeichen ausgewertet. Das Bestimmungszeichen “N” des ersten Aktionsblocks (AnwTeil) gibt an, dass der Wert des Schrittmerkers für die Ausführungskontrolle verwendet werden soll. Damit werden die Anweisungszeilen ausgeführt, bis der Schritt inaktiv wird. Schritt_A ist aktiv, solange kein Fehler auftritt (FehlerTest meldet TRUE) und BoolAction kein TRUE erzeugt. Ändert sich eine dieser beiden Bedingungen,

196

4 Die Programmiersprachen der IEC 61131-3

erfolgt die Freischaltung der Transition, die den Schritt inaktiv schaltet. Dann wird Anwteil ein letztes Mal durchlaufen und CT auf FALSE gesetzt (AND-Ausdruck liefert FALSE). D für “Delay” erzeugt nach dem Ablauf der angegebenen Zeit (1 Sekunde) TRUE für die im Deklarationsteil definierte Variable BA. Diese kann im Aktionsblock auch weggelassen werden; dann übernimmt bei booleschen Aktionen der Aktionsname die Aufgabe. In diesem Fall könnte BoolAction für die Transition verwendet werden und muss statt BA deklariert sein. Der hier in ST beschriebene Anweisungsteil AnwTeil könnte auch in AWL bzw. als KOP- oder FBS-Netzwerk(e) formuliert werden. Es ist auch möglich, eine Aktion wieder als AS-Struktur darzustellen.

TransBedX

Schritt_A

N

AktionZweiteEbene Schritt_aa

N

Start

TransBedAb

BV

Schritt_bb

N

Var_X

TransBedBc

Schritt_cc

S

BV

Bsp. 4.56. Unterstrukturierung einer Aktion durch ein weiteres AS-Netzwerk (Schachtelung). Die Rückkopplungsvariable BV wird im Unter-Netzwerk gesetzt und schaltet damit den Schritt_A frei.

Bsp. 4.56 beschreibt einen Aktionsblock, der seinerseits wieder AS-strukturiert ist. AS-Netze einer tieferen Ebene (wie das Netzwerk von AktionZweiteEbene in Bsp. 4.56) laufen nur ab, solange die aufrufende AS-Aktion (Schritt_A) aktiv ist. Wird diese deaktiviert, endet die weitere Bearbeitung des “Unter-” Netzwerks (bis auf die oben beschriebene Endeprüfung). Soll in diesem Beispiel sichergestellt werden, dass das gesamte Unternetzwerk bis Schritt_cc durchlaufen wird, bevor dieses Netzwerk durch den Schrittmerker von Schritt_A deaktiviert wird, kann die

4.6 Ablaufsprache AS

197

Variable BV als letzte Aktion gesetzt werden, die damit die Transition nach Schritt_A freischaltet.

TransBedX

Schritt_A

N

KOP_Netzwerk 0001: Eing23

VarAus1

Schritt_A.X TB_AB

0002: Eing24

VarAus2

Bsp. 4.57. Anweisungs-Aktion mit grafischem Anweisungsteil. Der Schrittmerker von Schritt_A wird hier verwendet, um beim letzten Durchlauf nach der Deaktivierung gesondert reagieren zu können.

Sobald Schritt_A in Bsp. 4.57 aktiv ist, wird TRUE an VarAus1 zugewiesen, da der Schrittmerker aktiv ist. Es können mehrere KOP-Netzwerke formuliert werden. Sobald TB_AB Schritt_A deaktiviert, wird die Aktion nochmals aufgerufen. Damit erhält VarAus1 den aktuellen Wert von Eing23, da SchrittA.X nunmehr FALSE ist.

0001: Var1

VarAus1 S

KOP_Aktion

Var2

Bsp. 4.58. Verwendung eines Aktionsblocks innerhalb eines KOP-Netzwerks

Im Gegensatz zu Bsp. 4.57, dort ist der Aktionsblock einem Schritt zugewiesen und in KOP formuliert, dient der Aktionsblock in Bsp. 4.58 dazu, innerhalb eines KOP-Netzwerks eine (oder mehrere) Aktivitäten zu beschreiben. Die boolesche

198

4 Die Programmiersprachen der IEC 61131-3

Variable KOP_Aktion wird in diesem Fall auf TRUE gesetzt (und nur dann), wenn Var1 oder Var2 TRUE besitzen. Ein Aktionsblock wie in Bsp. 4.58 kann auch innerhalb eines FBS-Netzwerks eingesetzt werden, indem der Eingang eines (oder mehrerer) Aktionsblocks mit einem Ausgang verbunden wird.

Var1 & Var2

VarAus1 S

FBS_Aktion

Bsp. 4.59. Verwendung eines Aktionsblocks innerhalb eines FBS-Netzwerks

Die linke Verbindung löst im Aktionsblock dieselbe Reaktion aus wie die Verbindung mit einem Schrittmerker. Die rechte Verbindung erhält jeweils den Wert der linken Verbindung. Solche Netzwerke sind nicht mehr nach AWL oder ST querübersetzbar, da dies mit dem Konzept des Aktuellen Ergebnisses und den Ausdrücken nicht mehr vereinbar ist (z.B. bei Bestimmungszeichen mit Zeitverzögerung).

4.6.7 Bestimmungszeichen und Ablaufsteuerung Der Detail-Betrachtung des Bestimmungszeichen schließt sich ein Absatz über die generelle Ablaufsteuerung einer AS strukturierten POE an. Bestimmungszeichen. Wann eine Aktion ausgeführt wird, hängt vom Schrittmerker und dem Bestimmungszeichen ab. Folgende Bestimmungszeichen stehen zur Verfügung. In Bsp. 4.62 sind detaillierte Grafiken zu Tab. 4.15 zu finden.

4.6 Ablaufsprache AS

BZ (leer) N R S L D P SD DS SL P1

P0

199

Kurzwort

Erklärung wie N. Nicht gespeichert Aktueller Wert des Schrittmerkers. Rücksetzen Setze Wert auf FALSE; gespeichert. Setzen Setze Wert auf TRUE; gespeichert. Zeitbegrenzt Liefere TRUE bis Ende der angegebenen Zeit oder Schritt-Deaktivierung. Zeitverzögert Liefere TRUE nach Ablauf der angegebenen Zeit bis zur Schritt-Deaktivierung. Impuls Liefere TRUE genau bei einem FALSE o TRUE Übergang (Flankenerkennung). Gespeichert (unbedingt), Liefere TRUE nach Ablauf der angegebenen Zeit, Zeitverzögert auch wenn der Schritt nicht mehr aktiv. Zeitverzögert, Gespeichert Liefere TRUE nach Ablauf der angegebenen Zeit nur, wenn der Schritt noch aktiv. Gespeichert, Zeitbegrenzt Liefere TRUE bis Ende der angegebenen Zeit. Puls, steigende Flanke Die Aktionsblock wird genau einmal nach der Aktivierung des Schritts durchlaufen (siehe auch P0: Deaktivierung des Schritts) Puls, fallende Flanke Die Aktionsblock wird genau einmal nach der Deaktivierung des Schritts durchlaufen (siehe auch P1: Aktivierung des Schritts)

Tab. 4.15. Bestimmungszeichen (BZ) in AS

Jede Aktion besitzt einen eigenen Kontroll-Mechanismus, d.h. alle Aktionsblöcke, die diese Aktion verwenden, beeinflussen die Ausführungskontrolle der Aktion. Aus der Gesamtheit der von diesen Aktionsblöcken gelieferten Ausführungsanforderungen wird eine Bedingung errechnet, die entscheidet, ob die Aktion ablaufen soll oder nicht. Diese nachfolgend beschriebene Ausführungskontrolle einschließlich Q-Ausgang ist bei den meisten Programmiersystemen für den Anwender nicht sichtbar, sondern ist im Betriebssystem der SPS hinterlegt. Die Beschreibung zeigt, wann eine Aktion in einer POE ausgeführt wird. In einem AS-Netzwerk werden alle Aktionen durch eine eigene Ausführungskontrolle, eine sogenannte Aktionskontrolle (englisch: ACTION_CONTROL; nicht zu verwechseln mit Aktionsblock) gesteuert; d.h. diese Aktionskontrolle berechnet Start und Endezeitpunkt einer Aktion. Die Eingänge sind mit den Aktionsblöcken (Schrittmerker, Bestimmungszeichen) verbunden, die diese Aktion verwenden. Die eingehenden booleschen Werte werden nach den in Abb. 4.29 vorgegebenen Regeln bearbeitet. Der Ausgang ist ein boolescher Wert, der, soweit er implementierungsabhängig vom Anwender verwendet werden kann, Auskunft über den Zustand der Aktion bietet.

200

4 Die Programmiersprachen der IEC 61131-3

R SchrittA.X

. . . SchrittB.X

&

BZ BZ BZ

N S L D P SD DS SL S P1 P0

Q >=1

Abb. 4.27. Aktionskontrolle einer Aktion. Alle Aktionsblöcke, die diese Aktion verwenden, beeinflussen über ihr Bestimmungszeichen (BZ) und den Wert des Schrittmerkers den entsprechenden Eingang. Die Eingänge werden gemäß unten stehenden Regeln bearbeitet (durch “ ” schematisch dargestellt). Das Gesamtergebnis (Q-Ausgang) mit Namen Aktionsmerker regelt schließlich, ob diese Aktion ausgeführt wird oder nicht.

Jeder Aktionsblock wird vom SPS-Betriebssystem mit dem im Bestimmungszeichen (BZ) genannten Eingang der Aktionskontrolle (der im Aktionsblock genannten Aktion) gekoppelt. Damit besitzt die zum BZ gehörende Funktion den Schrittwert als Eingangsparameter, siehe Bsp. 4.60. Alle Ausgänge bis auf die RESET-Operation, die höchste Priorität besitzt, werden nach der Berechnung mit einer OR-Operation verbunden. Das mit dem RESET über ein logisches UND verbundene Ergebnis, Q-Ausgang genannt, wird: -

bei einer booleschen Aktion der Aktionsvariablen zugewiesen, bei den restlichen Aktionen (mit Anweisungsteil) als Ausführungskontrolle verwendet. Solange der zur Aktion gehörende Q-Ausgang TRUE ist, werden die Anweisungen immer wieder zyklisch gestartet, ansonsten nicht.

4.6 Ablaufsprache AS

Schritt_1

R

B1

.. . Schritt_20

D

B1

Schritt_24.X

S

Schritt_20.X

D

.. . .. .

.. . Schritt_24

Schritt_1.X S

201

R

set fun.

>=1

delay fun.

& B1.Q

B1

Bsp. 4.60. Aktionskontrolle der Aktion B1, die hier in drei verschiedenen Aktionsblöcken verwendet wird. Deren Bestimmungszeichen und die Schrittmerker regeln den Wert von B1.Q.

Die Funktionen für die einzelnen Bestimmungszeichen sind in Abb. 4.29 zusammengestellt. Um sich die Funktionalität der Aktionskontrolle von 4.29 vor Augen zu führen, stelle man sich eine Aktion X vor, die nur an einer Stelle des Netzwerks in einem Aktionsblock mit BZ “N” genutzt wird. Sobald der zugehörige Schritt aktiv wird, besitzt der Schrittmerker TRUE; der ist mit dem “N”-Eingang der Aktionskontrolle verbunden. Damit liefert die OR-Verknüpfung TRUE. Da kein RESET für die Aktion programmiert ist, ist der negierte RESET Eingang ebenfalls TRUE. Die AND-Verknüpfung wird TRUE und damit der Q-Ausgang. Die Aktion X wird nun ausgeführt, bis der Schrittmerker wieder auf FALSE geht. Eine Aktion darf niemals gleichzeitig durch zwei BZ mit Zeitangaben angesteuert werden (L, D, SD, DS oder SL), da hierfür keine Vorrangregeln definiert sind.

202

4 Die Programmiersprachen der IEC 61131-3

&

R N

>=1

Q

RS S

S R1 Q1

L TON T

IN PT

T

IN PT

& Q

TON D

Q

R_TRIG P

CLK Q

RS SD

TON

S R1 Q1 T

IN PT

Q

TON DS T

IN PT

RS S R1 Q1

Q

RS SL

S R1 Q1

& TON T

IN PT

Q

R_TRIG P1

CLK Q

F_TRIG P0

CLK Q

Abb. 4.28. Berechnungsvorschrift der Aktionskontrolle einer Aktion. Alle aktiven Schritte, die die Aktion benutzen, liefern an dem Eingang (N, R, S, L, D, P, SD, DS, SL, P1, P0), der im Aktionsblock (BZ) aufgeführt ist, TRUE. T ist ein Zeitparameter, der dem BZ mitgegeben wird. Die 10 FB-Instanzen entsprechen den IEC 61131-3 Standard-FBs (FBInstanzname wurde weggelassen).

4.6 Ablaufsprache AS

203

Der in Bsp. 4.60 genannte Aktionsmerker (Q-Ausgang) wird als boolesche Variable vom System zur Verfügung gestellt. Mit der Ausgabe 2 der Norm wurde eine weitere boolesche Variable definiert, der Aktivierungsmerker. Er ist aktiv, solange eine Aktion ausgeführt wird; damit ist er genau eine Bearbeitungsschleife länger aktiv als der Aktionsmerker, der bei der letzten Abarbeitung (nachdem der zugehörige Schritt inaktiviert wurde) bereits auf 0 gesetzt ist. Wird der Aktivierungsmerker in einem System verwendet, ist die Aktionskontrolle von 4.28 wie folgt zu erweitern.

&

R N

Q

>=1 RS

S

S R1 Q1

SL

S R1 Q1

RS & Q

TON T

IN PT

F_TRIG

Q Q

CLK Q

R_TRIG P1

CLK Q

P0

CLK Q

F_TRIG

>=1

A

Abb. 4.29. Erweiterung von Abb. 4.29 um den Aktivierungsmerker; er zeigt durch ein TRUE an, dass die entsprechende Aktion derzeit aktiv ist (evtl. auch mit bereits inaktivem Schritt).

Nachfolgende Beispiele sollen zeigen, wie sich der Q-Ausgang einer Aktionskontrolle in Abhängigkeit verschiedener BZs ändert.

204

4 Die Programmiersprachen der IEC 61131-3

Gezeigt wird die zeitliche Veränderung der booleschen Variablen A1, die jeweils durch den Q-Ausgang der Aktionskontrolle zur Aktion A1 beschrieben wird. Im Falle einer Anweisungs-Aktion wird der zugehörige Anweisungsteil solange zyklisch gestartet, wie das SPS-Betriebssystem den Q-Ausgang von A1 mit TRUE berechnet. Um die gegenseitige Beeinflussung von BZs aus mehreren Aktionsblöcken zeigen zu können, wird ein weiterer Schritt SX eingeführt, der die Aktion A1 ebenfalls benutzt.

S1

.. .

bz1

A1

bz2

A1

Trans1

SX

TransX

Bsp. 4.61. Schritt und Aktionsbeschreibung für Bsp. 4.62.

bz1 N

bz2 Beispiel Direkte Weitergabe des Schrittwertes: S1

S

R

A1 Setzen und Rücksetzen einer Aktion: S1 SX A1

Bsp. 4.62. Wert des Q-Ausgangs für A1 (Aktion wird ausgeführt, bzw. Wertzuweisung an boolesche Variable), abhängig vom Bestimmungszeichen eines Aktionsblocks (bz1), der diese Aktion benutzt, oder von zwei Aktionsblöcken bz1 und bz2 (wird fortgesetzt).

4.6 Ablaufsprache AS

205

Zeitbegrenztes Setzen innerhalb der aktiven Schrittzeit:

L T#1s

Fall1:

Fall2:

S1

S1

A1

A1 1s Einmaliges Setzen bei Flankenerkennung:

P

1s

S1 A1 Zeitverzögertes Setzen innerhalb der aktiven Schrittzeit:

D T#1s

Fall1:

Fall2:

S1

S1

A1

SD T#1s

R

A1 1s 1s Zeitverzögertes Setzen unbedingt, Restart zwischen 2 Starts: Fall1:

Fall2:

S1

S1

SX

SX

A1

A1 1s Reset

1s 1s

1s 1s

Fall3: S1 SX A1 1s

Bsp. 4.62. (Fortsetzung)

Der Unterschied zwischen SD und DS liegt darin, dass bei DS nach der Wartezeit die Aktion nur dann ausgelöst wird, wenn der Schrittmerker dieses Aktionsblocks nach der Wartezeit immer noch auf TRUE steht, bei SD erfolgt auf jeden Fall die Aktivierung (bis zum RESET auf diese Aktion).

206

4 Die Programmiersprachen der IEC 61131-3

DS T#1s

SL T#1s

R

R

Zeitverzögertes Setzen (Start innerhalb der aktiven Schrittzeit); Restart erforderlich: Fall1:

Fall2:

S1

S1

SX

SX

A1

A1 1s

1s Zeitbegrenztes Setzen: Fall1:

Fall2:

S1

S1

SX

SX

A1

A1 1s

1s

Fall3: S1 SX A1 1s

Bsp. 4.62. (Fortsetzung)

Ablaufsteuerung. In den Programmiersprachen AWL oder ST erhalten die einer Anweisung folgenden oder über die Ausführungssteuerung (CAL, JMP) angesprungenen Befehle die Kontrolle über den Prozessor (sequentielle Abarbeitung). In AS wird die Befehlsabarbeitung anders geregelt. Ein AS-strukturiertes Netzwerk besitzt zu jeder Zeit eine Zustandsbeschreibung aus aktiven bzw. nicht-aktiven Schritten und den Werten der Transitionsbedingungen, die jeweils den Zustand TRUE oder FALSE besitzen.

4.6 Ablaufsprache AS

207

Das SPS-Betriebssystem vergibt die Prozessorkontrolle nach folgendem Algorithmus: 1) Aktiviere den Anfangsschritt (nur beim Einsprung in ein AS-Netz). Ansonsten: Deaktiviere alle aktiven Schritte mit nachfolgend freigegebenen Transitionen und aktiviere alle Schritte, die diesen Transitionen nachfolgen. 2) Prüfe jeweils den Q-Ausgang aller Aktionskontrollen. Falls gerade ein TRUE o FALSE Übergang stattfand, führe die Aktionen aus (letzte Aktivierung). 3) Führe alle Aktionen aus, deren Aktionskontrolle (Q-Ausgang) TRUE besitzen. 4) Sobald die Befehlssequenzen und/oder die Bearbeitung der booleschen Aktionen beendet sind, führe einen Austausch der Variablenwerte mit der E/APeripherie durch (Zyklusende). 5) Bestimme die Transitionen neu und fahre mit 1) fort. Wie man daran erkennt, erfolgt keine sequentielle Befehlsabarbeitung des Netzwerks, sondern eine ständige Auswertung sämtlicher Schritte und Transitionen. Somit kennt ein AS-Netzwerk auch kein explizites Programmende. Schließt sich einem Schritt keine weitere Transition an, so springt das Programm nicht automatisch zum Anfangsschritt zurück (auch nicht bei einer AS-Unterstrukturierung wie in Bsp. 4.56), sondern die POE verbleibt im zuletzt eingenommen Zustand. Wird eine AS-strukturierte POE von einer nicht AS-strukturierten POE aufgerufen, entsteht die Schwierigkeit, den Zeitpunkt der Gültigkeit der Ausgangsparameter festzulegen. Die AS-Struktur kennt schließlich keine “Rückkehr”, sondern ist immer “aktiv”. Dies könnte z.B. durch einen “Freigabe-Operand” der aufgerufenen POE erfolgen. Weiterhin muss die Systemreaktion festgelegt werden, wenn eine AS-strukturierte POE ein zweites Mal aufgerufen wird, was ein unsicheres Netzwerk oder eine weitere Instanziierung herbeiführen würde. Das Verhalten ist derzeit noch nicht standardisiert und wird von den Programmiersystemen unterschiedlich gelöst. Wird beispielsweise die AS-Strukturierung für FBs gesperrt (dann also nur noch für PROGRAM zugelassen), entfällt die oben angesprochene Inkonsistenz. Der Algorithmus zur Realisierung einer Ablaufsteuerung arbeitet üblicherweise mit einer (globalen) Datenstruktur, welche die Schrittzustände und Transitionen aller je angesprungenen POEs enthält. Damit werden alle aktivierten ASNetzwerke simultan ausgewertet. Eine Variante dazu bildet die Verwendung einer (lokalen) Zustands- und Transitionsüberwachung für jede POE: Ruft ein Baustein einen FB auf, erfolgt eine Auswertung und Ausführung seiner aktuell aktiven Transitionen und Zustände. Danach kehrt die Kontrolle an das aufrufende Programm (PROGRAM) zurück, an dessen Ende der Variablenaustausch (Zyklusende) erfolgt. Im jeweiligen Zyklus werden dadurch nur solche Transitionen/Zustände überwacht und ausgeführt, die den POEs angehören, die in diesem Zyklus aufgerufen werden.

208

4 Die Programmiersprachen der IEC 61131-3

4.6.8 Beispiel Dino-Park Ein Vergnügungspark besteht aus verschiedenen Häusern und Gehegen. Wie man seit Jurassic Park weiß, wandeln die Besucher in der hochtechnisierten Welt nicht mehr zu Fuß, sondern werden in komfortablen Fahrzeugen, die aneinandergehängt sind, zu den Stätten der Vergnügung gebracht. Da es sich bei unserem Vergnügungspark “Dino-Park” um eine Stätte für Besserverdienende handelt, verbringt nur jeweils eine Besuchergruppe ihre Zeit im Park. Sie betritt geschlossen über das Kassenhaus den Park und steigt ein. Die Fahrt geht zum ersten Dino-Gehege. Der Park besteht aus 6 Bereichen / Attraktionen (Att) mit folgenden Aufgaben für die Überwachungssteuerung: Att1: Kassenhaus. Anschalten der gesamten Elektrizität über den booleschen Aktor ElektAn. Ein Lift wird über die Variable LiftAb zu einer Beladestation bewegt; das Stoppen des Lifts erfolgt durch einen Hardware-Kontakt beim Erreichen der vorgesehenen Stelle. Att2: Anschalten des Wasserfalls, solange sich der Besuch im Haus aufhält. Eine Aktion mit Anweisungen steuert den Mechanismus einer Vorführung von Dino-Marionetten. Um für nachfolgende Attraktionen in anderen Häusern genügend Druckluft zu besitzen, soll der Pressluft-Generator angeworfen werden. Nach 10 Minuten erfolgt die Ansteuerung der Sound-Maschine, die Dino-Schreie generiert, die gleichzeitig das Signal zum Aufbruch sind.

Die Besuchergruppe kann sich nun teilen. Für die Unerschrockenen wartet in Att4 eine wässrige Überraschung, die übrigen können sich mit einer entschärften Version in Att3 amüsieren. Att3: Anschalten des Lichts, solange sich der Besuch im Haus aufhält. Über Druckluft werden Konfetti in den Raum geblasen. Sobald ein Besucher den Schalter AktionAus findet und aktiviert, wird die Aktion in Att3 und Att4 beendet, die Fahrt geht weiter. Att4: wie Att3 mit Ausnahme, dass die Konfetti durch Wasser ersetzt sind. Att5: Freigehege. Der Fahrstuhl mit Nahrung zur Dinofütterung wird gestartet; es dauert 15 Sekunden, bis er seine oberste Position erreicht. Ausschalten des Pressluft-Generators. Aktivierung eines Geldsensors nach 20 Minuten. Erfolgte bis zu diesem Zeitpunkt von den Teilnehmern ein Geldeinwurf in ausreichender Höhe, geht die Fahrt wieder von vorn los (zurück nach Att1). Att6: Ende der Vergnügung. Licht aus.

4.6 Ablaufsprache AS PROGRAM Dinopark VAR ElektAn LiftAb LiftHoch Wasserfall Schrei Druck Licht3An Licht4An WasserMarsch KonfettiMarsch AktionAus Geld GeldEinwurf END_VAR

AT %QB0.0 : BOOL; AT %QB1.0 : BOOL; AT %QB1.1 : BOOL; AT %QB2.0 : BOOL; AT %QB3.0 : BOOL; AT %QB4.0 : BOOL; AT %QB5.3 : BOOL; AT %QB5.4 : BOOL; AT %QB6.0 : BOOL; AT %QB6.1 : BOOL; AT %IB1.0 : BOOL; AT %IW2 : INT; : BOOL;

Att1

S S

ElektAn LiftAb

ElektAn Att2

N D t#10m N

Wasserfall Schrei Dinos Code

S

Druck

Schrei

Att3

N N

Licht3An KonfettiMarsch

N N

Att4

Licht4An WasserMarsch

AktionAus Att5

GeldEinwurf & (Geld < 1000) Att6

R

L t#15s R D t#20m

LiftHoch Druck GeldEinwurf

GeldEinwurf & (Geld >= 1000)

ElektAn

END_PROGRAMM

Bsp. 4.63. AS-strukturierte POE: Dino-Park

209

210

4 Die Programmiersprachen der IEC 61131-3

VAR ... END_VAR INITIAL_STEP Att1: ElektAn(S); LiftAb(S); END_STEP STEP Att2: Wasserfall(N); Schrei(D, t#10m); Dinos(N); Druck(S); END_STEP (* weitere Schritt-Deklarationen *) ... TRANSITION FROM Att1 TO Att2 := ElektAn; END_TRANSITION TRANSITION FROM Att2 TO (Att3, Att4) := Schrei; END_TRANSITION TRANSITION FROM (Att3, Att4) TO Att5 := AktionAus; END_TRANSITION TRANSITION FROM Att5 TO Att1 := GeldEinwurf & (Geld >= 1000); END_TRANSITION TRANSITION FROM Att5 TO Att6 := GeldEinwurf & (Geld < 1000); END_TRANSITION ACTION Dinos : (* Anweisungen *); END_ACTION

Bsp. 4.64. Bsp. 4.63 in textueller Notation (Auszug)

4.6 Ablaufsprache AS

211

Kommentierung des Vergnügungspark-Netzwerks Schritt Att1

Kommentierung Initialzustand; dieser Schritt wird beim Aufruf der POE als erstes eingenommen. Die beiden booleschen Variablen ElektAn und LiftAb werden auf TRUE gesetzt, sobald der Schrittmerker von Att1 auf TRUE gesetzt wird. ElektAn wird ebenfalls verwendet, um die Nachfolgetransition sofort freizuschalten. Att6 setzt diese boolesche Aktion wieder zurück.

Att2

Die boolesche Variable Wasserfall wird solange auf TRUE gesetzt (, damit der Wasserfall läuft), wie der Schrittmerker von Att2 gesetzt ist. Die Variable Schrei wird erst nach 10 Minuten auf TRUE gesetzt. Solange dieser Schritt aktiv ist, werden die Anweisungen der Aktion Dinos zyklisch aufgerufen. Druck wird bei Aktivierung von Att2 auf TRUE gesetzt.

Att2 / Att3

Beide Schritte sind gleichzeitig aktiv. Alle dort aufgeführten Variablen erhalten während der Laufzeit TRUE zugewiesen. Meldet der Sensor AktionAus TRUE, werden beide inaktiviert und auf Att5 weitergeschaltet.

Att5

LiftHoch erhält ab der Aktivierung des Schritts TRUE; nach 15 Sekunden den Wert FALSE. Die Variable GeldEinwurf wird dagegen erst 20 Minuten nach Aktivierung von Att5 auf TRUE gesetzt.

Die beiden nachfolgenden Transitionen schließen sich durch die Bedingung Geld gegenseitig aus, so dass nur ein Weg gewählt wird. Att6

Das Programm geht davon aus, dass die POE nur einmal aufgerufen wird. Somit befindet sich diese POE für die restliche Laufzeit der Task im Schritt Att6 (wenn kein Geld mehr eingeworfen wird). Die eingangs gesetzte Aktion bzw. boolesche Variable ElektAn wird wieder rückgesetzt.

5 Standardisierte SPS-Funktionalität

Die IEC standardisiert nicht nur die Syntax der Programmiersprachen, sondern geht noch einen Schritt weiter, um die Verwendung typischer SPS-Funktionalitäten wie Zeiten, Zähler oder spezielle Arithmetik-Operationen zu vereinheitlichen. Dazu werden in der Norm SPS-typische Funktionen und -Funktionsbausteine vordefiniert, die in ihrem Verhalten exakt beschrieben sind. Diese Bausteine werden Standard-Funktionen und Standard-Funktionsbausteine genannt. Ihre Namen sind Reservierte Schlüsselworte. Programmiersysteme bzw. Bausteinbibliotheken unterschiedlicher Hersteller müssen sich an diese Vorgaben halten, wenn ihre Funktionen und Funktionsbausteine den entsprechenden Namen tragen. Daneben ist es jederzeit möglich, zusätzliche SPS-Funktionalität anzubieten, die beispielsweise Hardware-Eigenschaften berücksichtigt oder sonstige Charakteristika eines SPS-Systems unterstützt. Eine solche Festlegung auf einen eindeutigen SPS-Funktionsstandard bildet eine wichtige Voraussetzung für einheitliche, hersteller- und projektübergreifende Ausbildung, Programmierung und Dokumentation. In diesem Kapitel wird eine Übersicht über die wichtigsten Standard-Funktionen und -Funktionsbausteine sowie die verwendeten Konzepte gegeben: 1) Standard-Funktionen (Std.-FUN) - Aufrufschnittstelle - Erweiterbarkeit - Überladen - Beispiele 2) Standard-Funktionsbausteine (Std.-FB) - Aufrufschnittstelle - Beispiele Während Standard-Funktionen den grundlegenden Verknüpfungs-Operatoren (Addition, Schieben, Vergleich u.a.) in herkömmlichen SPS-Systemen entsprechen, übernehmen die Standard-Funktionsbausteine die zustandsbehaftete SPSFunktionalität von Zeiten, Zählern, R/S-Gliedern und zur Flankenerkennung.

“This page left intentionally blank.”

214

5 Standardisierte SPS-Funktionalität

In den folgenden Abschnitten wird die Aufrufschnittstelle (Ein- und Ausgangsvariablen bzw. Funktionswert) für Std.-FUN und Std.-FB ausführlich dargestellt. Anschließend werden jeweils Beispiele zur praxisgerechten Verwendung erklärt. In den Anhängen Anh. A und Anh. B wird die grafische Deklaration sämtlicher Standard-Funktionen und -Funktionsbausteinen einschließlich einer Beschreibung ihrer Funktionalität dargestellt. Die prinzipielle Handhabung von Funktionen und Funktionsbausteinen wurde bereits in Kap. 2 beschrieben, Eigenschaften ihrer Formalparameter in Kap. 3.

5.1 Standard-Funktionen Die IEC 61131-3 definiert folgende acht Gruppen von Standard-Funktionen: 1) 2) 3) 4) 5) 6) 7) 8)

Funktionen zur Typumwandlung (Konvertierung von Datentypen), Numerische Funktionen, Arithmetische Funktionen, Bitfolge-Funktionen (Schiebe- und bitweise boolesche Funktionen), Funktionen für Auswahl und Vergleich, Funktionen für Zeichenfolgen (String-Operationen), Sonderfunktionen für Datentyp Zeit, Sonderfunktionen für Datentypen der Aufzählung.

Tab. 5.1 fasst sämtliche Standard-Funktionen der Norm in dieser Weise komprimiert zusammen. Die Sonderfunktionen für die Datentypen Zeit (ADD, SUB, MUL, DIV, CONCAT) und Aufzählung (SEL, MUX, EQ, NE) werden zusammen mit den übrigen Funktionen zu Arithmetik, Vergleich, Auswahl und Zeichenfolge aufgeführt. Dabei werden Funktionsname und Datentyp des Funktionswerts sowie eine stichwortartige Kurzbeschreibung angegeben. Zusätzlich können dieser Tabelle – in Verbindung mit Tab. 5.4 – die Namen der Eingangsvariablen sowie deren Datentypen entnommen werden.

5.1 Standard-Funktionen

Standard-Funktionen (mit Datentypen der Eingangsvariablen)

215

Kurzbeschreibung Datentyp Funktionswert

überladbar

erwei terbar

ANY ANY_INT ANY ANY_BIT

Datentyp umwandeln Ganzzahlig machen Wandeln von BCD Wandeln nach BCD Wandeln nach Tageszeit

ja ja ja ja nein

nein nein nein nein nein

Wandeln nach Datum

nein

nein

ja ja ja ja ja ja ja ja ja ja ja

nein nein nein nein nein nein nein nein nein nein nein

ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja

ja nein nein nein ja nein nein nein nein nein nein nein nein nein nein nein nein nein

Typumwandlung *_TO_** (ANY) TRUNC (ANY_REAL) BCD_TO_** (ANY_BIT) *_TO_BCD (ANY_INT) DATE_AND_TIME_TO_TIME_OF_DAY (DT) DATE_AND_TIME_TO_DATE (DT)

TOD DATE

Numerik ABS SQRT LN LOG EXP SIN COS TAN ASIN ACOS ATAN

Arithmetik

(ANY_NUM) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL) (ANY_REAL)

Absolutbetrag Wurzel (Basis 2) natürl. Logarithmus Logarithmus zur Basis 10 Exponentiation Sinusfunktion Cosinusfunktion Tangensfunktion Sinus-Umkehrfunktion Cosinus-Umkehrfunktion Tangens-Umkehrfunktion

(IN1,IN2)

ADD {+} (ANY_NUM, ANY_NUM) (TIME, TIME) ADD {+} a (TOD, TIME) ADD {+} a (DT, TIME) ADD {+} a MUL {*} (ANY_NUM, ANY_NUM) (TIME,ANY_NUM) MUL {*} a SUB {-} (ANY_NUM, ANY_NUM) (TIME, TIME) SUB {-} a (DATE, DATE) SUB {-} a (TOD, TIME) SUB {-} a (TOD, TOD) SUB {-} a (DT, TIME) SUB {-} a (DT, DT) SUB {-} a DIV {/} (ANY_NUM, ANY_NUM) (TIME,ANY_NUM) DIV {/} a MOD (ANY_NUM, ANY_NUM) EXPT {**} (ANY_NUM, ANY_NUM) MOVE {:=} (ANY_NUM, ANY_NUM) a

ANY_NUM ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL ANY_REAL

ANY_NUM Addition TIME Zeitaddition TOD Zeitaddition DT Zeitaddition ANY_NUM Multiplikation TIME Zeitmultiplikation ANY_NUM Subtraktion TIME Zeitsubtraktion TIME Zeitsubtraktion TOD Zeitsubtraktion TIME Zeitsubtraktion DT Zeitsubtraktion TIME Zeitsubtraktion ANY_NUM Division TIME Zeitdivision ANY_NUM Rest-Bildung (Modulo) ANY_NUM Exponent ANY_NUM Zuweisung

Sonderfunktionen für den Datentyp Zeit. Der allg. Ein- und Ausgangstyp für ADD und SUB ist daher ANY_MAGNITUDE, vgl.a. Abschn. 3.4.3

Tab. 5.1. Übersicht über die Standard-Funktionen (wird fortgesetzt)

216

5 Standardisierte SPS-Funktionalität

Kurzbeschreibung Datentyp Funktionswert

Standard-Funktionen (mit Datentypen der Eingangsvariablen)

Schieben SHL SHR ROR ROL

Schieben nach links Schieben nach rechts Rotieren nach rechts Rotieren nach links

ja ja ja ja

nein nein nein nein

ANY_BIT ANY_BIT ANY_BIT ANY_BIT

Bitweise UND-verknüpf. Bitweise ODER-verknüpf. Bitweise EXODER-verkn. Bitweise negieren

ja ja ja ja

ja ja ja nein

ANY AUFZ ANY_E ANY_E ANY_E ANY AUFZ

Binäre Auswahl (1 aus 2) Binäre Auswahl (1 aus 2) Maximum Minimum Begrenzung Multiplexer (1 aus N) Multiplexer (1 aus N)

ja nein ja ja ja ja nein

nein nein ja ja nein ja nein

BOOL BOOL BOOL BOOL BOOL BOOL BOOL BOOL

auf größer als auf größer gleich auf gleich auf gleich auf kleiner als auf kleiner gleich auf ungleich auf ungleich

ja ja ja nein ja ja ja nein

ja ja ja nein ja ja nein nein

INT STRING STRING STRING STRING DT STRING STRING STRING INT

Länge einer Zeichenfolge Zeichenfolge „links von“ Zeichenfolge „rechts von“ Zeichenfolge „aus Mitte“ Aneinanderreihung Zeit-Aneinanderreihung Einfügen Ausschneiden Ersetzen Suche Position

nein ja ja ja nein nein ja ja ja ja

nein nein nein nein ja nein ja ja ja ja

(IN1,IN2) (G, ANY, ANY) (G, AUFZ, AUFZ) (ANY_E, ANY_E) (ANY_E, ANY_E) (MN, ANY_E, MX) (K, ANY, ..., ANY) (K, AUFZ, ..., AUFZ)

Vergleich GT {>} GE {>=} EQ {=} EQ {=} b LT {<} LE {<=} NE {<>} NE {<>} b

Zeichenfolge

(IN1,IN2) (ANY, ANY) (ANY, ANY) (ANY, ANY) (AUFZ, AUFZ) (ANY, ANY) (ANY, ANY) (ANY, ANY) (AUFZ, AUFZ)

(IN1, IN2)

LEN (STRING) LEFT (STRING, L) RIGHT (STRING, L) MID (STRING, L, P) CONCAT (STRING, STRING) (DATE, TOD) CONCAT a INSERT (STRING, STRING, P) DELETE (STRING, L, P) REPLACE (STRING, STRING, L, P) FIND (STRING, STRING) a b c

ANY_BIT ANY_BIT ANY_BIT ANY_BIT

(IN1,IN2) (ANY_BIT,ANY_BIT) (ANY_BIT,ANY_BIT) (ANY_BIT,ANY_BIT) (ANY_BIT,ANY_BIT)

Auswahl SEL SEL b MAX c MIN c LIMIT c MUX c MUX b

erwei terbar

(IN1,N) (ANY_BIT, ANY_INT) (ANY_BIT, ANY_INT) (ANY_BIT, ANY_INT) (ANY_BIT, ANY_INT)

Bitweise AND {&} OR {>=1} XOR{=2k+1} NOT

überladbar

Sonderfunktionen für Datentyp Zeit Sonderfunktionen für Datentyp der Aufzählung ANY_E steht hier als Abkürzung für ANY_ELEMENTARY

Tab. 5.1. (Fortsetzung)

5.1 Standard-Funktionen

217

Die Abkürzungen zu den Datentypen von Eingangsvariablen und Funktionswerten in Tab. 5.1 werden, bis auf die Allgemeinen Datentypen, in Tab. 5.4 zusammengestellt. Diese Abkürzungen entsprechen den Namen für Eingangsvariablen, die die IEC 61131-3 für die betreffenden Standard-Funktionen verwendet. AUFZ ist eine zusätzliche Abkürzung, die hier gewählt wurden, um Tab. 5.1 übersichtlich zu halten.

Eingänge N L P G K MN MX AUFZ

Bedeutung Anzahl der zu schiebenden Bits (Number) linke Position innerhalb Zeichenfolge (Left) Position innerhalb Zeichenfolge (Position) Auswahl aus 2 Eingängen (Gate) Auswahl aus n Eingängen Minimalwert für LIMIT (MiNimum) Maximalwert für LIMIT (MaXimum) Datentyp der Aufzählung

Datentyp ANY_INT ANY_INT ANY_INT BOOL ANY_INT ANY_ELEMENTARY ANY_ELEMENTARY

Tab. 5.2. Abkürzungen und Bedeutung für Eingangsvariablen in Tab. 5.1

In der ersten Spalte von Tab. 5.1 werden linksbündig die Funktionsnamen angegeben. Sternchen (*) im Funktionsnamen der Gruppe „Typumwandlung“ stehen als Abkürzungen für (vgl. Anh. A): * Datentyp des Eingangs (rechts in Spalte 1) ** Datentyp des Funktionswerts (Spalte 2) Der Name der Eingangsvariable(n) einer Funktion wird, soweit für eine Gruppe einheitlich angebbar bzw. überhaupt vorhanden, in der kursiv geschriebenen Gruppen-Überschrift angegeben. Beispielsweise heißen die Eingangsvariablen für Arithmetik IN1, IN2 und bei Erweiterung IN3, IN4,.... Bei Funktionen mit nur einer Eingangsvariablen besitzt diese keinen Namen. Falls eine Funktion mit mehreren Eingängen davon nur einen mit einem beliebigen Datentyp (überladbar) besitzt, ist sein Variablenname „IN“. Dies trifft zu für LIMIT, LEFT, RIGHT, MID und DELETE. In der IEC 61131-3 bildet SEL eine Ausnahme dieser einheitlichen Benennung. Die Eingänge werden dort mit G, IN0 und IN1 (statt IN1, IN2) bezeichnet. Einige Standard-Funktionen besitzen in ihrer grafischen Darstellung alternativ Funktionsnamen mit Sonderzeichen, die in Tab. 5.1 unmittelbar hinter dem

218

5 Standardisierte SPS-Funktionalität

Funktionsnamen in geschweiften Klammern angegeben sind. Beispielsweise wird die Addition mit ADD (als Operator in AWL) oder „+“ (als grafisches Symbol in KOP/FBS oder innerhalb Ausdrücken in ST) aufgerufen.

5.1.1 Überladen und Erweitern Rechts neben dem Funktionsnamen werden in Tab. 5.1 die Datentypen der Eingangsvariablen in Klammern angegeben. Dabei werden zur Erläuterung auch Allgemeine Datentypen verwendet, die mit Tab. 3.9 bereits vorgestellt wurden. Jede Funktion, deren Eingangsvariablen mit einem Allgemeinen Datentyp beschrieben wird, heißt überladbar und hat ein „ja“ in der entsprechenden Spalte von Tab. 5.1. Die Funktion ist nicht auf einen Typ von Eingangsvariablen beschränkt, sondern kann auf verschiedene Datentypen angewendet werden. Der Datentyp des Funktionswerts (2. Spalte) entspricht in der Regel den Datentypen der Eingänge. Ausnahmen bilden Funktionen wie LEN, die als Eingabeparameter eine Zeichenfolge erwarten, als Rückgabewert jedoch einen INT-Wert liefern. Kann eine Standard-Funktion eine variable Anzahl von Eingängen (2, 3, 4,...) besitzen, wird sie erweiterbar genannt. Solche Funktionen sind mit „ja“ in der entsprechenden Spalte von Tab. 5.1 gekennzeichnet. Die Angabe von formalen Parametern beim Aufruf von erweiterbaren Funktionen entfällt. Der Aufruf erfolgt in den textuellen Sprachen einfach mit durch Kommata getrennten Aktualparameter – in der grafischen Darstellung fehlen die Parameternamen innerhalb des Kästchens. Diese Eigenschaften sind in der IEC 61131-3 nicht für benutzerdefinierte Funktionen vorgesehen, können allerdings als Ergänzung zur Norm auch auf solche Funktionen (und andere POE-Typen) ausgedehnt werden. Erweiterbarkeit und Überladen bei Standard-Funktionen werden in den beiden nächsten Abschnitten anhand von Beispielen erläutert. Überladen von Funktionen. Überladene Funktionen können unter gleichem Namen für die Verarbeitung mehrerer Datentypen verwendet werden. Dabei unterstützt eine überladene Funktion nicht immer sämtliche Datentypen eines Allgemeinen Datentyps, wie er in Kap. 3 erläutert wird. Kennt ein SPS-System beispielsweise die Integer-Datentypen INT, DINT und SINT, werden für eine überladene Funktion ADD, die den allgemeinen Datentyp ANY_INT unterstützt, typischerweise genau diese drei Datentypen zugelassen. Falls eine Standard-Funktion nicht überladen wird, sondern auf einen speziellen Elementaren Datentyp eingeschränkt wurde, ist ihr Name um einen Unterstrich und den betreffenden Datentyp zu erweitern: z.B. ADD_SINT ist eine auf den

5.1 Standard-Funktionen

219

Datentyp SINT eingeschränkte Addition. Solche Funktionen werden „typisiert“ genannt. Demgegenüber heißen überladene Funktionen auch typunabhängig. Dies wird in Bsp. 5.1 anhand der Integer-Addition veranschaulicht:

INT

ADD_INT

INT

DINT

INT ADD_DINT

DINT

SINT

ANY_ INT DINT

ANY_ INT

ADD ANY_ INT

ADD_SINT

SINT

Typisierte Standardfunktionen ADD_*

SINT

Überladene Standardfunktion ADD

Bsp. 5.1. Typisierte Standard-Funktionen ADD_INT, ADD_DINT und ADD_SINT für ganzzahlige Additionen und die überladene Standard-Funktion ADD

Das Programmiersystem hat bei der Verwendung überladener Funktionen die passende typisierte Funktion auszuwählen. Wenn beispielsweise ein Funktionsaufruf der Addition ADD in Bsp. 5.1 erfolgt, bei dem die Datentypen der Aktualparameter vom Datentyp DINT sind, wird für den Anwender (nicht direkt sichtbar) die Variante ADD_DINT ausgewählt und aufgerufen. Es werden jeweils sämtliche abgeleiteten Datentypen unterstützt, die das SPSSystem zur Verfügung stellt. Beim Aufruf von Standard-Funktionen müssen sämtliche überladenen Eingänge und ggf. auch der Funktionswert denselben Datentyp besitzen. D.h. es ist unzulässig, die Eingangsvariablen gleichzeitig mit Variablen unterschiedlicher Datentypen zu versorgen. Bei gemischten Eingangs-Datentypen sind vom Anwender explizite Typumwandlungsfunktionen für die betroffenen Eingänge vorzuschalten bzw. dem Funktionswert nachzuschalten, wie es Bsp. 5.2 für ADD_DINT und ADD_INT zeigt. In solchen Fällen ist anstelle der überladbaren Funktion ADD ihre typisierte Variante (z.B. ADD_DINT) zu verwenden.

220

5 Standardisierte SPS-Funktionalität

VAR Ganzzahl Ganzkurzzahl Gleitpunktzahl Doppelwort END_VAR

Ganzzahl Gleitpunktzahl

: : : :

INT; SINT; REAL; DWORD;

INT_TO_DINT REAL_TO_DINT

Ganzzahl Ganzzahl

DINT_TO_DWORD

Doppelwort

ADD

Ganzzahl Ganzkurzzahl

ADD

Ganzzahl

SINT_TO_INT

ADD INT_TO_SINT

Ganzkurzzahl

Bsp. 5.2. Aufruf der überladenen Standard-Funktion ADD mit Typumwandlungen zur korrekten Versorgung der Eingangsvariablen. Im oberen Fall wird ADD durch das Programmiersystem auf die typisierte Standard-Funktion ADD_DINT abgebildet, in den beiden unteren auf die Funktion ADD_INT.

Erweiterbarkeit von Funktionen. Erweiterbare Standard-Funktionen können eine variable Anzahl von Eingängen besitzen, die zwischen zwei und einer vom SPS-System gegebenen Obergrenze liegt. Sie werden auch als „ausziehbar“ bezeichnet, um anzudeuten, dass ihre Kastenhöhe in grafischer Darstellung abhängig von der Eingangszahl ist. Die Erweiterung der Eingänge einer Standard-Funktion um weitere Eingänge dient sowohl bei den textuellen als auch bei den grafischen Programmiersprachen der IEC 61131-3 als Ersatz für einen kaskadierten Aufruf dieser Funktion. Insbesondere bei den grafischen Sprachen KOP und FBS kann dadurch viel Platz in der Darstellung eingespart werden.

5.1 Standard-Funktionen

Var1

ADD

Var1 ADD

Var2

Var4

Kaskadierung von Addierern

Anweisungsliste (AWL) LD ADD ADD ADD ST

Var1 Var2 Var3 Var4 Erg

ADD

Var2 ADD

Var3

Var3 Erg

Var4

Erg

erweiterter Addierer

Strukturierter Text (ST) Erg := Var1 + Var2; Erg := Erg + Var3; Erg := Erg + Var4;

kann ersetzt werden durch:

kann ersetzt werden durch:

LD ADD ST

Erg := Var1 + Var2 + Var3 + Var4;

Var1 Var2, Var3, Var4 Erg

221

Bsp. 5.3. Kaskadierte Addition als Ersatzdarstellung für eine erweiterbare Funktion am Beispiel der Addition in grafischer und textueller (AWL und ST) Darstellung

In diesem Beispiel wird der dreifache Aufruf der Standard-Funktion ADD durch einen einzigen Aufruf mit erweiterten Eingängen ersetzt. Auch für die textuellen Darstellungen in AWL und ST ergeben sich Vereinfachungen.

5.1.2 Beispiele In diesem Abschnitt wird die Aufrufschnittstelle von Standard-Funktionen exemplarisch beschrieben. Auf Möglichkeiten und Besonderheiten beim Aufruf von Funktionen wurde bereits in Kap. 2 eingegangen. Für jede der in Tab. 5.1 angegebenen Funktionsgruppen wird nachfolgend mindestens ein Beispiel herausgegriffen und erläutert. Dieses wird jeweils in den textuellen Sprachen AWL und ST sowie in den grafischen Darstellungen für KOP und FBS angegeben. In AWL und ST werden bei Aufrufen die Namen der Formalparameter nicht explizit mit angegeben. Für die nachfolgenden Beispiele wird das PROGRAM ProgRahmenFUN in Bsp. 5.4 als Rahmen für den gemeinsamen Deklarationsteil der benötigten Variablen verwendet.

222

5 Standardisierte SPS-Funktionalität

TYPE FARBEN

:

( hRot, hGelb, hGruen, Rot, Gelb, Gruen, dRot, dGelb, dGruen);

(* Aufzählungstyp für Farbskala *) (* hell *) (* normal *) (* dunkel *)

END_TYPE PROGRAM ProgRahmenFUN (* gemeinsamer Deklarationsteil Std.-FUN *) VAR (* lokale Daten *) Drehzahl : REAL:= 10.5; (* Drehzahl *) DZ1 : REAL; (* Drehzahl 1 *) DZ2 : REAL := 46.8895504; (* Drehzahl 2 *) Stufe : UINT := 1; (* Drehzahl-Stufe *) Status : BYTE := 2#10101111; (* Status *) Erg : BYTE; (* Zwischenergebnis *) Maske : BYTE := 2#11110000; (* Bit-Maske *) SPSNorm : STRING [11]:= 'IEC 61131-5'; (* Zeichenfolge *) AT %IB2 : SINT; (* für MUX-Auswahl *) AT %QX3.0 : BOOL; (* Ausgangsbit *) Zeitpunkt : DT := dt#1994-12-23-01:02:03; (* Datum mit Uhrzeit *) Uhrzeit : TIME := t#04h57m57s; (* Uhrzeit *) Ampel : FARBEN; (* Ampelfarben *) Farbskala1 : FARBEN := hGelb; (* Hellgelb Farbskala 1 *) Farbskala2 : FARBEN := Gelb; (* Gelb Farbskala 2 *) Farbskala3 : FARBEN := dGelb; (* Dunkelgelb Farbskala 3 *) Skala : INT := 2; (* Auswahl Farbskala *) END_VAR ... (* Programmrumpf mit nachfolgenden Beispielen *) END_PROGRAM

Bsp. 5.4. Gemeinsame Deklarationen für Beispiele zur Verwendung der StandardFunktionen

Funktionen zur Typumwandlung.

Drehzahl

REAL_TO_UINT

Anweisungsliste (AWL) LD Drehzahl REAL_TO_UINT ST Stufe

Stufe

Strukturierter Text (ST)

Stufe := REAL_TO_UINT (Drehzahl);

Bsp. 5.5. Beispiel für „Konvertierung REAL nach UINT“

Dieses Beispiel zeigt die Typumwandlung des REAL-Wertes Drehzahl (Gleitpunktzahl) in den ganzzahligen UINT-Wert Stufe.

5.1 Standard-Funktionen

223

Die Variable Stufe besitzt nach Ausführung der Funktion den Wert 10, indem von 10.5 abgerundet wird. Numerische Funktionen.

Drehzahl

LN

DZ1

Anweisungsliste (AWL) LD LN ST

Strukturierter Text (ST)

Drehzahl DZ1 := LN

(Drehzahl);

DZ1

Bsp. 5.6. Beispiel für „Natürlicher Logarithmus“

Dieses Beispiel zeigt die Berechnung des Natürlichen Logarithmus. Die Variable DZ1 besitzt nach der Ausführung den Wert 2,3513... Arithmetische Funktionen.

Drehzahl

MUL

DZ1 DZ2

Drehzahl

Anweisungsliste (AWL) LD MUL MUL ST

Drehzahl DZ1 DZ2 Drehzahl

Strukturierter Text (ST)

Drehzahl := Drehzahl * DZ1 * DZ2;

Bsp. 5.7. Beispiel für „Multiplikation“. Anstelle der zweifachen Verwendung von MUL kann auch geschrieben werden: MUL DZ1, DZ2.

Dieses Beispiel verwendet die überladene Funktion Multiplikation. Sie wird aufgrund der REAL-Eingangsvariablen auf die typisierte Funktion MUL_REAL abgebildet. Die Variable Drehzahl besitzt nach der Ausführung den Wert 1157,625.

224

5 Standardisierte SPS-Funktionalität

Anstelle des Schlüsselworts MUL kann in der grafischen Darstellung auch das übliche Multiplikationszeichen „*“ verwendet werden, wie in diesem Beispiel für ST gezeigt. Schiebe-Funktionen.

SHL Status Stufe

IN N

Erg

Anweisungsliste (AWL) LD SHL ST

Status Stufe Erg

Strukturierter Text (ST)

Erg := SHL ( IN N

:= Status, := Stufe );

Bsp. 5.8. Beispiel für „Schieben links“

In Bsp 5.8 wird die Schiebefunktion SHL verwendet, um den Wert der Variable Status um so viele Bitstellen nach links zu schieben, wie Stufe angibt. Das Schiebe-Ergebnis Erg besitzt nach Funktions-Ausführung den Wert 2#01011110, d.h. beim Links-Schieben wird eine „0“ von rechts nachgeschoben. Bitfolge-Funktionen.

AND Status Maske

Erg

Anweisungsliste (AWL) LD NOT AND ST

Strukturierter Text (ST)

Status Maske Erg

Erg := NOT Status & Maske;

Bsp. 5.9. Beispiel für „AND“

Da das logische AND eine erweiterbare Funktion darstellt, entfallen wie bei MUL die Angaben der Eingangsparameter-Namen. AND ist eine überladene Funktion,

5.1 Standard-Funktionen

225

ihre Eingänge und ihr Funktionswert sind hier vom Typ BYTE, das Programmiersystem verwendet also die typisierte Funktion AND_BYTE. Anstelle der beiden AWL-Befehle LD und NOT könnte in Bsp. 5.9 gleichwertig auch der boolesche Operator LDN (Laden negiert) verwendet werden. Die Invertierung wird grafisch durch einen Funktionseingang mit kleinem Kreis dargestellt. Anstelle des Schlüsselworts AND kann in der grafischen Darstellung auch das übliche Und-Zeichen „&“ verwendet werden, wie in diesem Beispiel für ST gezeigt. In Bsp. 5.9 wird AND verwendet, um bestimmte Bits des Status-Werts mit Hilfe einer Bit-Maske zu extrahieren. Das Ergebnis Erg besitzt nach Funktions-Ausführung den Wert 2#01010000, d.h. die unteren vier Bits wurden durch die Maske ausgeblendet. Funktionen für Auswahl.

MUX %IB2 DZ1

K

DZ2

Drehzahl

Anweisungsliste (AWL) LD MUX ST

%IB2 DZ1, DZ2 Drehzahl

Strukturierter Text (ST)

Drehzahl := MUX ( K := %IB2, DZ1, DZ2 );

Bsp. 5.10. Beispiel für „MUX“

Der Multiplexer MUX besitzt neben dem Integer-Eingang K die überladenen Eingänge vom gleichen Typ wie der Funktionswert. Daher können bis auf K die Bezeichnungen für die Eingangsparameter entfallen. K wird in Bsp. 5.10 mit dem Datentyp SINT versorgt (ganzzahliges Byte mit Vorzeichen). Falls das Eingangsbyte %IB2 den Wert „1“ besitzt, bekommt Drehzahl nach Ausführung den Wert von DZ2 zugewiesen, bei „0“ den Wert von DZ1. Falls der Wert am Eingang K kleiner als 0 oder größer ist als die Anzahl der übrigen Eingänge, meldet das Programmiersystem bzw. Laufzeitsystem einen entsprechenden Fehler (vgl. Anh. E).

226

5 Standardisierte SPS-Funktionalität

Funktionen für Vergleich.

>= Drehzahl DZ1

GE Drehzahl DZ1 DZ2

& >=

%QX3.0

DZ1 DZ2

Erweiterter Vergleicher

Anweisungsliste (AWL) LD GE AND( GE ) ST

Drehzahl DZ1 DZ1 DZ2

%QX3.0

Ersatz-Darstellung

Strukturierter Text (ST)

%QX3.0 := GE ( Drehzahl, DZ1, DZ2 );

%QX3.0

Bsp. 5.11. Beispiel für „Erweiterten Vergleicher“. In grafischer Darstellung wird rechts eine Ersatz-Darstellung angegeben.

Vergleicher verwenden überladene Eingänge, ihr Ausgang Q ist boolesch. Sie bilden das „Bindeglied“ zwischen numerischen/arithmetischen Berechnungen und booleschen Verknüpfungen. In der grafischen Darstellung des Bsp. 5.11 ist die um einen Eingang erweiterte Vergleichsfunktion zusätzlich als Ersatzbild angegeben. In dieser Ersatzdarstellung sind die Schlüsselworte GE und AND durch ihre gleichwertigen Kürzel (>= und &) ersetzt.

5.1 Standard-Funktionen

227

Funktionen für Zeichenfolgen.

REPLACE SPSNorm '-3' 2 10

IN1 IN2 L P

SPSNorm

Anweisungsliste (AWL) LD REPLACE ST

SPSNorm '-3', 2, 10 SPSNorm

Strukturierter Text (ST) SPSNorm:= REPLACE ( IN2 := '-3', IN1 := SPSNorm, P := 10, L := 2 );

Bsp. 5.12. Beispiel für „REPLACE“ in AWL und in ST

Die Funktion REPLACE bietet keine überladbaren Eingänge, daher wird jeder Eingangsparameter beim Aufruf in grafischer Darstellung (und in ST) mit seinem Variablennamen angegeben. Bsp. 5.12 zeigt, dass die Reihenfolge dieser Eingänge dadurch beliebig sein kann (vgl. ST-Bsp). Die Reihenfolge ist fest vorgeschrieben (vgl. AWL-Bsp.), wenn keine Namen der Eingangsparameter verwendet werden. Die Zeichenfolge SPSNorm besitzt nach Ausführung den STRING-Wert 'IEC 61131-3'.

228

5 Standardisierte SPS-Funktionalität

Funktionen für Datentyp Zeit.

ADD_TOD_TIME Zeitpunkt Uhrzeit

IN1 IN2

Anweisungsliste (AWL) LD Zeitpunkt ADD_TOD_TIME Uhrzeit ST Zeitpunkt

Zeitpunkt

Strukturierter Text (ST)

Zeitpunkt := REAL_TO_UINT (Zeitpunkt, Uhrzeit);

Bsp. 5.13. Beispiel für „Addiere Zeit“ in AWL und in ST. Von der Verwendung des „+“Zeichens für Zeitoperationen rät die Norm inzwischen ab.

Diese Zeit-Addition (ebenso wie die entsprechende Subtraktion) kann als Fortsetzung der überladenen Addition betrachtet werden — bezogen auf gemischte Argumente: TIME, TIME_OF_DAY (TOD) und DATE_AND_TIME (DT). Die Variable Zeitpunkt besitzt nach der Funktionsausführung den Wert DT#1994-12-23-06:00:00. Addition und Subtraktion von Zeiten sind nicht symmetrisch. Für die Subtraktion kommen gegenüber der Addition die drei Differenzen für die Eingangs-Datentypen DATE, TOD und DT hinzu. Diese Operationen gibt es bei der Addition nicht, da es wenig Sinn macht, beispielsweise den 10. Oktober auf den 12. September zu addieren. Für die Addition fehlt die Möglichkeit, auf DATE eine Zeit TIME addieren zu können, während dies für TIME, TOD und DT möglich ist. Um es auch für DATE zu ermöglichen, wird zunächst nach DT gewandelt und anschließend addiert. Dadurch können Fehlprogrammierungen bei der Zeitrechnung weitgehend vermieden werden.

5.1 Standard-Funktionen

229

Funktionen für Aufzählungstypen.

MUX Skala FarbSkala1 FarbSkala2 FarbSkala3

K

Ampel

Anweisungsliste (AWL) LD MUX

ST

Skala ( FarbSkala1, FarbSkala2, FarbSkala3) Ampel

Strukturierter Text (ST)

Ampel := MUX (

K := Skala, FarbSkala1, FarbSkala2, FarbSkala3);

Bsp. 5.14. Beispiel für „Aufzählungs-MUX“

Für den Datentyp Aufzählung bietet die IEC 61131-3 Funktionen, von denen in Bsp 5.14 die Auswahl (MUX) gezeigt wird. Mit Hilfe der INT-Variablen Skala wird eine Variable mit Datentyp Aufzählungselement (Typdeklaration FARBEN) ausgewählt. Nach Ausführung der MUX-Funktion erhält die Variable Ampel die Werte „hGelb“, „Gelb“ und „dGelb“ der Farbskalen (hell, normal und dunkel), wenn Skala die Werte 0, 1 und 2 durchläuft.

230

5 Standardisierte SPS-Funktionalität

5.2 Standard-Funktionsbausteine Die IEC 61131-3 definiert eine Reihe von Standard-Funktionsbausteinen, die dem SPS-Programmierer die wichtigsten SPS Funktionsblöcke (mit speicherndem Verhalten) zur Verfügung stellen. Die IEC 61131-3 definiert folgende fünf Gruppen von Standard-FBs: 1) 2) 3) 4) 5)

Bistabile Elemente (= Flip-Flops, R/S-Glieder), Flankenerkennung, Zähler, Zeiten, Funktionsbausteine für Kommunikation.

Tab. 5.3 fasst sämtliche Standard-FBs der Norm in dieser Weise komprimiert zusammen. Der Aufbau dieser Tabelle entspricht prinzipiell dem der StandardFunktionen (vgl. Tab. 5.1). FBs für Kommunikation werden im Teil 5 der IEC 61131 definiert und in diesem Buch nicht behandelt. Für Ein- und Ausgangsvariablen werden anstelle ihrer Datentypen ihre Namen aufgeführt, die in Tab. 5.4 mit Angabe des dazugehörigen Elementaren Datentyps zu finden sind.

Name des Std.-FB mit Namen der Eingangsparameter R/S-Glieder SR (S1,R, RS (S,R1, Flanken R_TRIG {->} (CLK, F_TRIG {-<} (CLK, Zähler CTU (CU,R,PV, CTD (CD,LD,PV, CTUD (CU,CD,R,LD,PV, Zeiten TP (IN,PT, TON {T---0} (IN,PT, TOF {0---T} (IN,PT, Kommunikation

Namen der Rückgabewerte

Kurzbeschreibung

Q1) Q1)

Setzen vorrangig Rücksetzen vorrangig

Q) Q)

Erkennung steigende Flanke Erkennung fallende Flanke

Q,CV) Q,CV) QU,QD,CV)

Vorwärts-Zähler Rückwärts-Zähler Vorwärts/Rückwärts-Zähler

Q,ET) Q,ET) Q,ET)

Impulsgeber Einschalt-Verzögerung Ausschalt-Verzögerung siehe IEC 61131-5

Tab. 5.3. Übersicht der Standard-Funktionsbausteine

5.2 Standard-Funktionsbausteine

Eingänge / Ausgänge R S R1 S1 Q Q1 CLK CU CD LD PV QD QU CV IN PT ET PDT CDT

Bedeutung Rücksetz-Eingang (Reset) Setz-Eingang (Set) R vorrangig S vorrangig Ausgang Ausgang (RS, SR)1 (Takt-) Eingang (ClocK) Eingang Zähle vorwärts (Count Up), Eingang Zähle abwärts (Count Down) Lade Zählwert (LoaD) Zählwert (Preset Value) Abwärts-Ausgang (Down) Aufwärts-Ausgang (Up) Aktueller Zählwert (Current Value) Zeit-Eingang (INput) Zeitwert (Preset Time) Aktueller Zeitwert (End Time) Datum/Zeitwert (Preset Date and Time) Aktuelles Datum mit Zeit (Current Date and Time)

231

Datentyp BOOL BOOL BOOL BOOL BOOL BOOL BOOL R_EDGE R_EDGE INT INT BOOL BOOL INT BOOL TIME TIME DT DT

Tab. 5.4. Abkürzungen und Bedeutung für Ein- und Ausgangsvariablen in Tab. 5.3

Die Zähler-Eingänge CU und CD sind vom Datentyp BOOL mit dem Zusatz R_EDGE, d.h. an ihnen muss eine steigende Flanke erkannt werden, um vorwärts oder rückwärts zu zählen. Die Standard-Rückgabewerte sämtlicher Standard-FBs sind Null, wenn der Funktionsbaustein zum ersten Mal aufgerufen wird. Lediglich die Echtzeit-Uhr liefert an ihrem Ausgang CDT (Current Date and Time) sofort das aktuelle Datum mit Zeit. Die Namen der Eingangsparameter jedes Standard-FB sind Schlüsselworte. In AWL können sie als Operatoren auf FB-Instanzen verwendet werden, wie es in Abschn. 4.1.4 beschrieben wurde. Die Eingangsparameter R und S werden in AWL allerdings mit einer zweiten Bedeutung versehen, indem sie Operatoren zum Rücksetzen und Setzen von allgemeinen booleschen Variablen darstellen. Diese Tatsache bedeutet eine Schwierigkeit, die bei Implementierung von Programmiersystemen zu überwinden ist.

1

In der Norm wird der Q-Ausgang von Flip Flops im Unterschied zu den übrigen Standard-Funktionsbausteinen mit Q1 statt mit Q bezeichnet.

232

5 Standardisierte SPS-Funktionalität

Das Konzept der Überladbarkeit von Ein- und Ausgängen wie bei Standardfunktionen in Abschn. 5.1.1 beschrieben, gilt auch für Standard-Funktionsbausteine.

5.2.1 Beispiele Wie für die Standard-Funktionen wird in diesem Abschnitt die Aufrufschnittstelle von Standard-Funktionsbausteinen exemplarisch beschrieben. Auf Möglichkeiten und Besonderheiten beim Aufruf von FBs wurde bereits in Kap. 2 eingegangen. Für jede der in Tab. 5.3 angegebenen Funktionsgruppen wird nachfolgend mindestens ein Beispiel herausgegriffen und erläutert. Dieses wird jeweils in den textuellen Sprachen AWL und ST sowie in den grafischen Darstellungen für FBS angegeben. In AWL und ST werden im Folgenden die Namen der FB-Eingangsparameter explizit angegeben, um die Benutzung der FB-Instanzen möglichst gut zu verdeutlichen. Für AWL wird dabei diejenige Variante des Funktionsaufrufs (vgl. Abschn. 4.1.4) verwendet, die Eingangsparameter und Rückgabewerte als Strukturelemente der FB-Instanz behandelt. Für die nachfolgenden Beispiele wird das PROGRAM ProgRahmenFB in Bsp. 5.15 als Rahmen für den gemeinsamen Deklarationsteil der benötigten Variablen und FB-Instanznamen angenommen.

5.2 Standard-Funktionsbausteine

PROGRAM ProgRahmenFB VAR_GLOBAL RETAIN Zeitdauer : TIME := t#63ms; END_VAR

233

(* Gemeinsamer Deklarationsteil Std.-FB *) (* Globale, batteriegepufferte Daten *) (* 63 Millisekunden Initialwert *)

VAR (* Lokale Daten *) M_Schalt : RS; (* Merker Schaltbedingung *) TippTaster : R_TRIG; (* Flankenerkennung Taster *) VR_Zaehler : CTUD; (* Vorwärts/Rückwärts-Zähler *) V_Impuls : TP; (* Verlängerter Impuls als Zeit *) Impuls : BOOL; (* Impulsmerker *) NotAus : BOOL; (* Merker NotAus *) AT %IX1.4 : BOOL; (* Not-Aus-Taster *) AT %IX2.0 : BOOL; (* Zähle hoch *) AT %IX2.1 : BOOL; (* Lade Zaehler *) AT %IX2.2 : BOOL; (* Starte Zeit *) AT %IX3.0 : BOOL; (* Zähle runter *) AT %IW5 : INT; (* Zählgrenze *) AT %MX3.2 : BOOL; (* Schalt-Merker *) AT %QX3.2 : BOOL; (* Schalt-Ausgang *) MaxErreicht : BOOL; (* Zähler oben *) MinErreicht : BOOL; (* Zähler unten *) Zaehlwert AT %MW2 : INT; (* Aktueller Wert des Zählers *) Zeitwert : TIME; (* Zeitwert *) DatumUndZeit : DT; (* Aktuelles Datum mit Uhrzeit *) END_VAR ... (* Programmrumpf für nachfolgende Beispiele *) END_PROGRAM

Bsp. 5.15. Gemeinsame Deklarationen für Beispiele zur Verwendung der Standard-FBs

Diese Deklarationen beinhalten: -

FB-Instanznamen (M_Schalt bis V_Impuls), Direkt dargestellte Variable (%IX1.4 bis %QX3.2), Symbolische Variable (Zaehlwert), Allgemeine Variable (sonst).

Im Abschnitt VAR werden sie als lokale Variablen deklariert und im Abschnitt VAR_GLOBAL RETAIN als batteriegepufferte globale Variable.

234

5 Standardisierte SPS-Funktionalität

Bistabile Elemente (Flip-Flops).

M_Schalt RS %MX3.2 NotAus

S R1 Q1

%QX3.2

Anweisungsliste (AWL) LD ST LD ST CAL LD ST

Strukturierter Text (ST)

%MX3.2 M_Schalt.S NotAus M_Schalt.R1 M_Schalt M_Schalt.Q1 %QX3.2

M_Schalt

( S R1

:= %MX3.2, := NotAus);

Bsp. 5.16. Beispiel für ein „Bistabiles Element“ Flip-Flop

Bsp. 5.16 zeigt die Benutzung eines Flip-Flops zur Speicherung einer binären Zustandsinformation, hier den Wert des Merkers %MX3.2. Mit Hilfe des Eingangs R1 kann der Ausgang Q1 vorrangig rückgesetzt werden, d.h. auch wenn an beiden Eingängen eine „1“ ansteht, bleibt der Ausgang auf „0“.

Flankenerkennung.

TippTaster R_TRIG %IX1.4

CLK

Q

NotAus

Anweisungsliste (AWL) LD ST CAL LD ST

%IX1.4 TippTaster.CLK TippTaster TippTaster.Q NotAus

Strukturierter Text (ST)

TippTaster

( CLK := %IX1.4);

NotAus := TippTaster.Q;

Bsp. 5.17. Beispiel zur Flankenerkennung R_TRIG

5.2 Standard-Funktionsbausteine

235

Die FB-Instanz TippTaster des FB-Typs R_TRIG in Bsp. 5.17 wertet das am Peripherie-Bit anliegende Signal bei steigender Flanke aus und liefert bei einem 0o1-Übergang an Q eine „1“. Dazu führt TippTaster einen internen Flankenerkennungsmerker mit, der den „alten“ Wert von CLK speichert, um ihn jeweils mit dem aktuellen vergleichen zu können. Diese Information wird einen Programmzyklus lang (bis zum erneuten Aufruf) gemerkt und kann dadurch von übrigen Programmteilen ausgewertet werden, auch wenn %IX1.4 bereits wieder auf „0“ ist. Beim nächsten Aufruf im folgenden Zyklus wird der Flanken-Merker TippTaster wieder rückgesetzt. Das bedeutet, dass der FB R_TRIG für Direkt dargestellte Variablen nur solche Flanken erkennen kann, die in Abständen mindestens größer als die Programmzykluszeit auftreten. Die IEC 61131-3 bietet die FBs R_TRIG und F_TRIG nicht nur zur unmittelbaren, wie in Bsp. 5.17 gezeigten Verwendung an. Daneben werden diese FBs zur Flankenerkennung implizit zur Realisierung der Variablen-Attribute R_EDGE und F_EDGE verwendet (vgl. Kap. 3). Bsp. 5.18 zeigt die Variablendeklaration mit der Angabe eines flankengesteuerten Eingangs (fett dargestellt) im Deklarationsteil des FB BspFlanke.

FUNCTION_BLOCK BspFlanke VAR_INPUT Flanke : BOOL R_EDGE; (* flankengesteuert *) END_VAR VAR_OUTPUT Merker : BOOL; END_VAR ... LD Flanke; (* Zugriff auf Flanken-Merker *) ST Merker; ... END_FUNCTION_BLOCK

Bsp. 5.18. Deklaration mit R_EDGE zur Flankenerkennung und Verwendung in AWL

236

5 Standardisierte SPS-Funktionalität

Zum besseren Verständnis der flankengesteuerten Variablen erhält das Bsp. 5.18 in Bsp. 5.19 zusätzliche Anweisungen, die diese Erkennung realisieren. Eine entsprechende Funktionalität wird bei der Verwendung jener Variablen – für den Anwender unsichtbar – vom Programmiersystem eingesetzt.

FUNCTION_BLOCK BspFlanke VAR_INPUT Flanke : BOOL; END_VAR VAR_OUTPUT Merker : BOOL; END_VAR VAR FlErkenn : R_TRIG; END_VAR ... CAL FlErkenn (CLK := Flanke); LD FlErkenn.Q; ST Merker; ... END_FUNCTION_BLOCK

(* flankengesteuert *)

(* FB-Instanz „steigende Flanke“ *)

(* FB-Aufruf zur Flankenerkennung *) (* FB-Ergebnis laden *)

Bsp. 5.19. Automatische Umsetzung des Beispiels aus Bsp. 5.18 mit R_TRIG

Die Deklaration des FB FlErkenn in Bsp. 5.19 wird implizit vom Programmiersystem in das Programm eingefügt. Dieser FB wird mit der Eingangsvariable Flanke aufgerufen. Sein Ausgangswert FlErkenn.Q wird dann überall dort eingesetzt, wo auf den Wert von Flanke zugegriffen wird. Dieses Beispiel zeigt, warum diese Art der Flankenerkennung in der IEC 61131-3 nicht für Ausgangsvariablen zulässig ist: solche könnten an beliebigen Stellen der POE überschrieben werden. Dadurch würde jedoch die Regel verletzt werden, dass Funktionsbausteine nicht die Ausgänge aufgerufener anderer FBs ändern dürfen! Siehe auch Abschn. 2.3.2.

5.2 Standard-Funktionsbausteine

237

Vorwärts/Rückwärts-Zähler.

VR_Zaehler CTUD %IX2.0 %IX3.0 %IX1.4 %IX2.1 %IW5

NOT

CU CD R LD PV

QU QD

MaxErreicht MinErreicht

CV

Zaehlwert

Anweisungsliste (AWL) LD ST LDN ST LD ST LD ST LD ST CAL

%IX2.0 VR_Zaehler.CU %IX3.0 VR_Zaehler.CD %IX1.4 VR_Zaehler.R %IX2.1 VR_Zaehler.LD %IW5 VR_Zaehler.PV VR_Zaehler

LD ST LD ST LD ST

VR_Zaehler.QU MaxErreicht VR_Zaehler.QD MinErreicht VR_Zaehler.CV Zählwert

Strukturierter Text (ST)

VR_Zaehler ( CU CD R LD PV

:= %IX2.0 := NOT(%IX3.0), := %IX1.4, := %IX2.1, := %IW5);

MaxErreicht := VR_Zaehler.QU; MinErreicht := VR_Zaehler.QD; Zaehlwert := VR_Zaehler.CV;

Bsp. 5.20. Beispiel für den Vorwärts/Rückwärts-Zähler CTUD

In diesem Beispiel wird der Vorwärts/Rückwärts-Zähler VR_Zaehler an sämtlichen Eingängen beschaltet, was nicht der Regelfall sein muss. Üblicherweise werden nur die benötigten Eingangs- und Ausgangsvariablen beschaltet. Die Eingänge CU und CD können beide gleichzeitig mit einer steigenden Flanke aktiv sein. In diesem Fall würde der Zählstand gleich bleiben, wenn das Minimum oder das Maximum noch nicht erreicht wurde. Der VR_Zaehler in Bsp. 5.20 zählt mit steigender Flanke von %IX2.0 vorwärts und bei fallender Flanke %IX3.0 rückwärts. Werden CU und CD mit derselben Variablen oder Konstanten belegt, würde der Zähler im Takt zu diesem Signal abwechselnd um eins hoch und gleich darauf wieder herunter zählen.

238

5 Standardisierte SPS-Funktionalität

Der an PV anliegende Setzwert wird bei einem Aufruf von der Peripherie %IW5 nachgeladen, wenn gleichzeitig der Lade-Eingang LD aktiv ist. Hier braucht keine steigende Flanke anliegen. Zeitgeber (Zeiten). Bsp. 5.21 zeigt stellvertretend die Benutzung der Zeitgeber-FBs. Dieses Beispiel demonstriert deutlich, wie die Zeitgeber als Instanzen den Zustand ihrer Daten, insbesondere auch den der Eingangsparameter, zwischen den einzelnen Aufrufen beibehalten. Prinzipiell kann bei jedem Aufruf eines Zeitgebers (bzw. eines beliebigen FBs) jede einzelne Eingangsvariable unmittelbar vorher gesetzt werden. Eine solche Umparametrierung des Zeitgebers zur Laufzeit führt jedoch dazu, dass dieser innerhalb derselben POE zur Steuerung mehrerer Prozess-Zeiten gleichzeitig verwendet wird. Dadurch wird das Programm schwer lesbar und fehleranfällig, so dass solche Fälle in der Programmierpraxis wohl selten vorkommen. Es reicht, den Zeitwert PT pro Instanz des Zeitgeber beim ersten Aufruf nur einmal zu setzen und von da an immer wieder zu benutzen. Dies bedeutet, dass der Aufruf der Zeit primär dem Starten der Zeitfunktion über den Eingang IN dient. Die Ausgangsvariablen des Zeitgebers können an jeder beliebigen Programmstelle abgefragt werden, brauchen also nicht unmittelbar nach Aufruf ausgewertet zu werden. Allerdings werden die Ausgangsparameter bei jedem Aufruf des Zeit-FBs gesetzt, indem sie aufgrund der Werte des physikalisch im Hintergrund laufenden Timers aktualisiert werden. Dadurch „veraltet“ der Zeitwert zwischen zwei Aufrufen. Deshalb sollte der Zeit-FB in einer periodischen Task häufig genug und nicht zu lang vor der Auswertung von Q und ET aufgerufen werden, um die Zeit nicht zu verfälschen. Während der Ausgang Q dazu dient, festzustellen, ob die Zeit abgelaufen ist oder nicht, wird der Ausgang ET verwendet, um die bis dahin noch verbleibende Zeit anzuzeigen. Daher werden Zeiten gewöhnlich nach folgendem Muster aufgerufen: 1) Setzen des Zeitwerts, 2) periodisches Starten mit Aktualisieren, 3) Abfrage der Zeit. Oft werden in einem periodisch laufenden Programm diese drei Schritte in einem Aufruf vereint. Dies vereinfacht das Programm und erleichtert die grafische Darstellung des Aufrufs. Das Zeitverhalten der Zeitgeber-Typen kann detailliert Anh. B entnommen werden.

5.2 Standard-Funktionsbausteine

239

V_Impuls TP %IX2.2 Zeitdauer

IN PT

Q ET

Impuls Zeitwert

Anweisungsliste (AWL)

LD ST ... LD ST CAL ... LD ST LD ST

(* 1. Impulsdauer setzen *) Zeitdauer V_Impuls.PT

Strukturierter Text (ST) (* 1. Impulsdauer setzen *) V_Impuls.PT := Zeitdauer; ...

(* 2. Zeit starten *) %IX2.2 V_Impuls.IN V_Impuls

(* 2. Zeit starten *) V_Impuls ( IN := %IX2.2); ...

(* 3. Zeit abfragen *) V_Impuls.Q Impuls V_Impuls.ET Zeitwert

(* 3. Zeit abfragen *) Impuls := V_Impuls.Q; Zeitwert := V_Impuls.ET;

Bsp. 5.21. Beispiel zur Zeit: Impulsgeber TP

Bsp. 5.21 zeigt die Verwendung des Impulsgebers mit Hilfe der beschriebenen drei Schritte zum Aufruf der Instanz V_Impuls: 1) Der Zeitwert für V_Impuls wird auf 63 Millisekunden festgelegt, 2) V_Impuls wird gestartet durch Eingangsbit 2.2, 3) Die Abfrage von V_Impuls mit Q und ET.

Hinweis: Der Zeitgeber-FB RTC (Echtzeit-Uhr) ist nicht mehr im Standard der IEC 61131-3 enthalten.

“This page left intentionally blank.”

6 Zeitgemäße SPS-Konfiguration

Die IEC 61131-3 trägt der technologischen Entwicklung der letzten Jahre Rechnung, indem mit modernen Konzepten die Modellierung von SPS-Projekten über die Grenzen von Ein-Prozessor-Programmen hinaus möglich wird. Das Softwaremodell der IEC 61131-3 erlaubt die praxisgerechte Strukturierung der Anwendung in Programmteile (Modularisierung in POEs). Dadurch werden Wartbarkeit, Dokumentation oder Diagnose-Möglichkeiten der SPS-Programme wesentlich unterstützt. Durch eine einheitliche Softwarearchitektur werden wesentliche Voraussetzungen für die Portabilität von Programmen erfüllt, indem die Verarbeitungseinheiten der SPS (Ressourcen) eindeutig beschriebene Eigenschaften besitzen und so eine Plattform für hardwareunabhängigere Programme bieten. Die bisher übliche Baustein-Strukturierung von SPS-Projekten (vgl. Abb. 2.5) diente einerseits der Programmstrukturierung und andererseits beinhalteten einige besondere Bausteintypen (wie Organisations-Bausteine) oft implizite LaufzeitEigenschaften. Demgegenüber bietet die IEC 61131-3 wesentlich erweiterte und standardisierte Möglichkeiten. In diesem Kapitel werden die Konfigurationselemente der IEC 61131-3 erläutert, die ein wesentliches Strukturierungshilfsmittel für das Zusammenwirken der POEs darstellen. Sie definieren Laufzeit-Eigenschaften der Programme, Kommunikationsbeziehungen sowie die Zuordnung zur SPS-Hardware. Diese Konfigurationselemente der IEC 61131-3 unterstützen aktuelle Betriebssystemfunktionalitäten auf der SPS-Seite. Eine CPU kann beispielsweise mehrere Programme gleichzeitig abarbeiten (Multi-Tasking).

242

6 Zeitgemäße SPS-Konfiguration

6.1 Projekt-Strukturierung durch Konfigurationselemente Nachdem in den vorangegangenen Kapiteln Programmierung und Verwendung der POEs erläutert wurden, dient dieser Abschnitt dazu, einen Überblick über die Modellbildung und Strukturierung von SPS-Programmen auf einer übergeordneten Ebene zu gewinnen. Dazu wird die Abb. 2.7 (POE-Aufruf-Hierarchie) in die Gesamtsicht eines SPSProgramms einbezogen.

Konfigurationselemente Konfiguration

Ressource

Task Laufzeitprogramm Programm

Funktionsbaustein

Funktionsbaustein

Funktionsbaustein

Funktion

Funktion

Abb. 6.1. Gesamtstruktur von SPS-Programmen nach IEC 61131-3 mit beispielhaften POEs und Konfigurationselementen

Wie Abb. 6.1 zeigt, liegen die Konfigurationselemente Konfiguration, Ressource und Task mit Laufzeitprogramm hierarchisch oberhalb der POE-Ebene.

6.2 Elemente einer realen SPS-Konfiguration

243

Während POEs die Aufruf-Hierarchie bilden, dienen die Konfigurationselemente dazu, diesen POEs Eigenschaften zuzuordnen: -

Laufzeit-Eigenschaften von PROGRAMs und FBs festlegen, Kommunikationsbeziehungen zwischen Konfigurationen definieren, Abbildung der Programmvariablen auf die SPS-Hardware-Adressen vornehmen.

Zunächst werden Aufbau und Inhalt der Konfigurationselemente selbst vorgestellt.

6.2 Elemente einer realen SPS-Konfiguration Konfigurationselemente entsprechen realen Elementen eines SPS-Systems: -

-

Konfiguration:

SPS-System, z.B. Steuerung als Einbaurahmen mit mehreren (auch vernetzten) Zentraleinheiten (CPUs) auf Maschinenzellen-Ebene Ressource: (ggf. multitasking-fähige) SPS-CPU Task: Laufzeit-Eigenschaften für Programm(e) und Funktionsbausteine („Typ“ eines SPS-Programms) Laufzeitprogramm: Einheit aus PROGRAM bzw. FUNCTION_BLOCK und zugewiesener TASK

Hauptprogramm(e) einer CPU sind POEs vom Typ PROGRAM. Handelt es sich um ein größeres Anwenderprogramm, wird es bevorzugt in Ablaufsprache geschrieben und koordiniert den Aufruf der übrigen POEs. Hauptprogrammen und Funktionsbausteinen werden Laufzeit-Eigenschaften wie „periodische Ausführung“ oder „Prioritätsstufe“ zugeordnet, wie es in Abb. 6.2 angedeutet wird. Unter dem Begriff „Laufzeitprogramm“ versteht man die Einheit aus sämtlichen benötigten POEs und der TASK, d.h. ein Gesamtprogramm mit Laufzeit-Eigenschaften. Ein Laufzeitprogramm bildet in diesem Sinn eine gebundene, in sich abgeschlossene Programmeinheit, die selbständig in einer CPU ablaufen kann. Abb. 6.2 veranschaulicht die Zuordnung von Konfigurationselementen zu Komponenten eines realen SPS-Systems (vgl. auch Abb. 2.4):

244

6 Zeitgemäße SPS-Konfiguration

Programm

Task

Ressource PROGRAM ProgA TASK TaskB

(CPU)

.. .. ..

VAR_INPUT ...

INTERVAL ...

CAL FB...

PRIORITY ...

PROGRAM ProgA WITH TaskB; Laufzeitprogramm

.. .. ..

.. .. ..

Konfiguration (SPS-System)

Abb. 6.2. Darstellung einer realen Konfiguration. ProgA und TaskB werden zu einem Laufzeitprogramm verbunden und der Ressource CPU des SPS-Systems zugeordnet.

Die tatsächliche Zuordnung von Konfigurationselementen zu den Elementen eines SPS-Systems hängt von dessen realer Hardware-Architektur ab. Mit Hilfe der Konfigurationsbeschreibung können die Tasks einer CPU zugewiesen werden, auf der sie simultan ablaufen, oder auf mehrere CPUs, soweit vorhanden, verteilt werden. Die Betrachtung der RESOURCE als eine CPU oder als CPU-Familie in einem Einbaurahmen hängt daher von der konkreten SPS-Architektur ab. Für „kleine SPS-Systeme“ können die Aufgaben zur Konfiguration auch allein durch eine POE vom Typ PROGRAM wahrgenommen werden: Programme können die dazu notwendigen Globalen Variablen sowie Zugriffspfade und Direkt dargestellte bzw. Symbolische Variablen deklarieren. Laufzeit-Eigenschaften, CPU-Zuordnung usw. werden (implizit) durch Mechanismen des Programmiersystems bzw. SPS-Fähigkeiten ersetzt. Diese Vorgehensweise zur SPS-Projektierung entspricht der von herkömmlichen SPS-Systemen. Diese Eigenschaften der Programm-POEs begünstigen eine Migration von bestehenden zu IEC-konformen Programmen.

6.3 Die Konfigurationselemente

245

6.3 Die Konfigurationselemente Zunächst werden die Aufgaben der Konfigurationselemente im Überblick beschrieben und anschließend detailliert erläutert. Dabei werden Teile des Beispiels in Abschn. 6.4 zur Erklärung verwendet.

6.3.1 Aufgaben Die Konfigurationselemente erfüllen im Einzelnen die in Tab. 6.1 zusammengefassten Aufgaben:

Konfigurationselement Konfiguration

Ressource

Task Laufzeitprogramm

Aufgabenbeschreibung - Definition globaler Variablen (innerhalb Konfiguration gültig) - Zusammenstellung von Ressourcen eines SPS-Systems - Definition der Zugriffspfade zwischen Konfigurationen - Deklaration (globaler) Direkt dargestellter Variablen - Definition globaler Variablen (innerhalb Ressource gültig) - Zuordnung von Tasks und Programmen zur Ressource - Aufruf der Laufzeitprogramme mit Eingangs- und Ausgangsparametern - Deklaration (globaler) Direkt dargestellter Variablen - Definition von Laufzeit-Eigenschaften - Zuordnung der Laufzeit-Eigenschaften zu PROGRAM und FUNCTION_BLOCKs

Tab. 6.1. Aufgaben der Konfigurationslemente. Innerhalb des PROGRAM können ebenfalls (globale) Direkt dargestellte Variablen sowie Zugriffspfade deklariert werden.

Durch die Deklaration der Direkt dargestellten Variablen wird die Abbildung der Gesamt-Konfiguration auf die Peripherie-Adressen der SPS-Hardware vorgenommen. Um diese Zuordnungen POEs zugänglich zu machen, kann die Deklaration in VAR_GLOBAL in Konfiguration, Ressource oder im PROGRAM erfolgen, d.h. POEs können darauf mit Hilfe VAR_EXTERNAL zugreifen. Zusammengefasst ergeben sämtliche Deklarationsabschnitte aller POEs für Direkt dargestellte Variablen die Belegungsliste des SPS-Programms. Damit kann auch eine Umverdrahtung, also die Neuzuordnung von symbolischen zu absoluten SPS-Peripherie-Adressen durchgeführt werden. Die Konfigurationselemente werden weitgehend in textueller Form deklariert. Die Norm definiert eine grafische Darstellung für TASK, doch die grafische Realisie-

246

6 Zeitgemäße SPS-Konfiguration

rung der übrigen Konfigurationselemente ist dem konkreten Programmiersystem überlassen und daher implementierungsabhängig.

6.3.2 Die CONFIGURATION Die IEC 61131-3 verwendet die Konfiguration (CONFIGURATION), um die Ressourcen (RESOURCE) eines SPS-Systems zusammenzufassen und ihnen Möglichkeiten zum Datenaustausch zur Verfügung zu stellen. Eine Konfiguration besteht aus den in Abb. 6.3 gezeigten Teilen:

CONFIGURATION Konfigurations-Name Typdefinitionen Globale Deklarationen RESOURCE-Deklarationen

ACCESS-Deklarationen

END_CONFIGURATION

Abb. 6.3. Aufbau der Deklaration einer Konfiguration

Innerhalb von Konfigurationen können Typdefinitionen erfolgen, die global für das gesamte SPS-Projekt gelten. Diese Möglichkeit besteht in den anderen Konfigurationselementen nicht. Die Kommunikation zwischen Konfigurationen, d.h. ihr Datenaustausch untereinander, erfolgt über Zugriffspfade in VAR_ACCESS. Variablen in VAR_GLOBAL sind nur innerhalb der Konfiguration gültig und stehen dort sämtlichen Ressourcen, Programmen und FBs zur Verfügung. Die Variablenart VAR_EXTERNAL ist deshalb in der Konfigurationsbeschreibung nicht verwendbar. Kommunikationsbausteine dienen der globalen Kommunikation in einem SPSSystem (zwischen Konfigurationen) und sind Inhalt des Teils 5 der IEC 61131 (vgl. auch Abschn. 6.5).

6.3 Die Konfigurationselemente

247

CONFIGURATION SPS_Zelle1 VAR_GLOBAL ... END_VAR RESOURCE CPU_Band ON CPU_001 ... END_RESOURCE RESOURCE CPU_Walz ON CPU_002... END_RESOURCE VAR_ACCESS ... END_VAR END_CONFIGURATION

Bsp. 6.1. Elemente der CONFIGURATION von Bsp. 6.6

Bsp. 6.1 zeigt Abschnitte zur Deklaration einer Konfiguration mit Namen SPS_Zelle1.

Sie enthält einen Abschnitt mit globalen Variablen, der für andere Konfigurationen nicht sichtbar ist, sondern nur den Ressourcen CPU_Band und CPU_Walz sowie den darauf laufenden POEs zur Verfügung stehen. Der Kommunikationsbereich VAR_ACCESS wird benutzt, um Daten zwischen den Ressourcen einer bzw. mehrerer Konfigurationen austauschen zu können (Zugriffspfade). Konfigurationen und Ressourcen enthalten keine Anweisungen wie POEs, sondern regeln ausschließlich die Beziehung der zugewiesenen POEs untereinander und nach außen.

6.3.3 Die RESOURCE Die Deklaration von Ressourcen dient der Zuordnung von TASKs an die physikalischen Betriebsmittel (engl.: resource) eines SPS-Systems. Ressourcen bestehen aus den in Abb. 6.4 gezeigten Teilen:

RESOURCE

Ressource-Name ON Ressource

Globale Deklarationen

TASK-Deklarationen

END_RESOURCE

Abb. 6.4. Aufbau der Deklaration einer Ressource

248

6 Zeitgemäße SPS-Konfiguration

Durch den Ressourcen-Namen wird einer SPS-CPU ein symbolischer Name zugeordnet. Die Typen und Nummern der in einem SPS-System zur Verfügung stehenden Ressourcen (individuelle CPU-Bezeichnungen) werden vom Programmiersystem zur Verfügung gestellt und auf ihre korrekte Verwendung überwacht. Mit Hilfe der auf Ressource-Ebene zulässigen globalen Variablen können die auf eine CPU begrenzten Daten verwaltet werden.

RESOURCE CPU_Band ON CPU_001 TASK ... PROGRAM ... WITH ... END_RESOURCE RESOURCE CPU_Walz ON CPU_002 VAR_GLOBAL ... END_VAR TASK ... PROGRAM ... WITH ... END_RESOURCE

Bsp. 6.2. Elemente der Ressourcen von Bsp. 6.6 (Detailausschnitt aus Bsp. 6.1)

Bsp. 6.2 zeigt Abschnitte zur Deklaration zweier Ressourcen. Auf die globalen Daten der Ressource CPU_002 kann von Ressource CPU_001 aus nicht zugegriffen werden. Das Schlüsselwort PROGRAM besitzt innerhalb einer Ressource-Definition eine andere Bedeutung als zu Beginn einer Programm-POE! Innerhalb der Ressource wird PROGRAM ... WITH zur Verknüpfung der TASK mit dem Programm verwendet, das vom Typ PROGRAM sein muss.

6.3.4 Die TASK mit Laufzeitprogramm Die Aufgabe der TASK-Definition liegt in der Vereinbarung und Zuweisung von Laufzeiteigenschaften für Programme und deren FBs. Bisher war es bei SPS-Systemen üblich, spezielle Bausteinarten zu verwenden (z.B. Organisationsbausteine OB), die implizit vordefinierte Laufzeit-Eigenschaften besitzen. Diese können eine zyklische Bearbeitung beinhalten oder Eigenschaften des SPS-Systems für Interrupt-Verarbeitung oder Fehler-Reaktionen ausnutzen. Mit der Definition einer TASK nach IEC 61131-3 werden solche ProgrammEigenschaften explizit und herstellerunabhängig formuliert. Dadurch können solche Programme besser dokumentiert und einfacher gewartet werden. Abb. 6.5 zeigt den prinzipiellen Aufbau einer textuellen TASK-Deklaration.

6.3 Die Konfigurationselemente

TASK Task-Name

249

(Task-Eigenschaften)

PROGRAM Programm-Name WITH Task-Name:(PROGRAM-Schnittstelle)

Abb. 6.5. Aufbau der textuellen Deklaration eines Laufzeitprogramms durch Definition der Task und Zuordnung von Task zum Programm (PROGRAM). Die „Task-Eigenschaften“ beschreiben die Parameterwerte der Task, die „PROGRAM-Schnittstelle“ enthält die Zuordnung von Aktual- zu Formalparametern.

Durch die Zuordnung von PROGRAM und TASK entsteht ein Laufzeitprogramm mit Programm-Name. Dieses bildet den Instanznamen des Programms vom Typ PROGRAM, dessen „Aufrufschnittstelle“ bei der Deklaration angegeben wird. Diese Schnittstelle beinhaltet Ein- und Ausgangsparameter der Programm-POE (im Unterschied zu FBs) und wird einmalig beim Starten der Ressource initialisiert. Ein PROGRAM kann durch diese Deklaration in mehreren Instanzen (Laufzeitprogramme) ausgeführt werden. Eine TASK kann neben dieser textuellen Darstellung auch grafisch wie in Abb. 6.6 deklariert werden. Dabei wird die Liste der TASK-Eigenschaften als Eingänge eines Kastens dargestellt. Die grafische Darstellung der Zuordnung zum Programm (PROGRAM...WITH...) wird durch die IEC 61131-3 allerdings nicht vorgegeben.

Taskname

T_Periodisch TASK

TASK BOOL

SINGLE

TIME

INTERVAL

UINT

PRIORITY

T_Unterbrech

SINGLE t#20ms 2

TASK Trigger

INTERVAL PRIORITY

SINGLE INTERVAL

1

PRIORITY

Abb. 6.6. Grafische Deklaration einer Task. Links in allgemeiner Darstellung, rechts zwei Tasks von Bsp. 6.6

Für die Task-Eigenschaften können die in Tab. 6.2 enthaltenen Eingangsparameter der TASK angegeben werden.

250

6 Zeitgemäße SPS-Konfiguration

TASK-Parameter SINGLE INTERVAL

PRIORITY

Bedeutung Mit steigender Flanke an diesem Eingang werden die mit der TASK verknüpften Programme einmal aufgerufen und ausgeführt. Wenn dieser Eingang einen Zeitwert ungleich Null besitzt, werden die mit der TASK verknüpften Programme zyklisch (periodisch) aufgerufen. Dabei gibt der Wert dieses Eingangs den Abstand zwischen zwei Aufrufen an. Dieser Wert kann also zum Einstellen und Überwachen der Programm-Zykluszeiten benutzt werden. Ist dieser Eingang Null, wird die Task nicht aufgerufen. Dieser TASK-Eingang legt die Priorität eines verknüpften Programms gegenüber anderen gleichzeitig laufenden Programmen fest, koordiniert also Multi-Tasking eines SPS-Systems. Die Bedeutung ist daher implementierungsabhängig (siehe Text).

Tab. 6.2. TASK-Eigenschaften als Eingangsparameter

Die Bedeutung des Eingangs PRIORITY hängt davon ab, auf welche Weise das SPS-System das Zusammenspiel mehrerer Tasks regelt und ist daher implementierungsabhängig. Wird eine Task aktiviert, die eine höhere Priorität aufweist als die gerade laufende besitzt, gibt es prinzipiell zwei Möglichkeiten, diesen Laufzeitkonflikt auf derselben Ressource (CPU) zu lösen. Es hängt von der Funktionalität des SPS-Betriebssystems ab, ob eine laufende Task unterbrechbar ist oder nicht: 1) Die laufende Task wird sofort unterbrochen und durch die höherpriore Task ersetzt. Dieses Verfahren nennt die IEC 61131-3 „vorberechtigter Aufruf“ (engl.: preemptive scheduling) einer Task und bringt damit zum Ausdruck, dass TASKs mit höherer Priorität absoluten Vortritt besitzen und sofort zur Ausführung gelangen. 2) Die laufende Task wird nicht unterbrochen, sondern normal beendet. Danach kommt diejenige TASK zur Ausführung, die von allen wartenden TASKs die höchste Priorität besitzt. Dieses Verfahren wird „nicht-vorberechtiger Aufruf“ (engl.: non-preemptive scheduling) genannt. Beide Verfahren dienen dazu, der höherprioren Task die Kontrolle über die angeforderte Ressource zu geben. Besitzt die anfordernde TASK dieselbe Priorität wie die laufende, muss sie warten. Falls TASKs derselben Priorität warten, wird jeweils diejenige mit der längsten Wartezeit ausgewählt.

6.3 Die Konfigurationselemente

251

TASK T_Schnell (INTERVAL := t#8ms, PRIORITY := 1); PROGRAM Antrieb WITH T_Schnell : ProgA (RegPar := %MW3, R_Wert => FehlerCode); TASK T_Unterbrech (SINGLE := Trigger, PRIORITY := 1); PROGRAM Schmier WITH T_Unterbrech : ProgC;

Bsp. 6.3. Elemente TASK und PROGRAM...WITH... von Bsp. 6.6

In Bsp. 6.3 werden die beiden TASKs T_Schnell (periodisch mit kurzer Zykluszeit) und T_Unterbrech (Unterbrechung mit hoher Priorität) definiert. T_Schnell wird im Abstand von 8 Millisekunden angestoßen. Wenn die Ausführungszeit des damit verknüpften Programms Antrieb diesen Wert überschreiten sollte (z.B. aufgrund Unterbrechungen durch höherpriore Tasks), meldet das SPSSystem den Laufzeitfehler „Zykluszeit-Überschreitung“. Das Programm Schmier besitzt dieselbe Priorität wie Antrieb, muss also warten, falls die Eingangsbedingung Trigger auf TRUE wechselt. Bei der Zuordnung eines Programms können Aktualparameter übergeben werden, wie hier für RegPar des ProgA mit einer Direkt dargestellten Variable gezeigt. Zur Laufzeit werden diese Parameter bei jedem Aufruf des Laufzeitprogramms gesetzt. Im Unterschied zu FBs können hier neben den Eingangsparametern auch Ausgangsparameter angegeben werden, die jeweils bei Beendigung des Programms aktualisiert werden. In Bsp. 6.3 erfolgt dies für R_Wert des ProgA. Zuweisungen solcher Ausgangsparameter an Variablen werden mit „=>“ anstelle von „:=“ versehen, um den Unterschied zur Versorgung von Eingangsparametern deutlich hervorzuheben. Wird ein PROGRAM ohne TASK-Verknüpfung deklariert, hat dieses Programm gegenüber allen anderen niedrigste Priorität und wird standardmäßig zyklisch aufgerufen.

6.3.5 Die ACCESS-Deklaration Mit dem Sprachkonstrukt VAR_ACCESS ... END_VAR können sogenannte Zugriffspfade als transparente Kommunikationsverbindungen zwischen Konfigurationen definiert werden. Sie stellen eine Erweiterung gegenüber den globalen Variablen dar, die innerhalb der Konfiguration gelten. Für Zugriffspfade können Schreib- und LeseAttribute angegeben werden. Variablen der Konfiguration werden unter symbolischen Bezeichner anderen Konfigurationen bekanntgegeben.

252

6 Zeitgemäße SPS-Konfiguration

VAR_ACCESS BandLeer ... ... ...

:

CPU_Band.%IX1.0 : BOOL

READ_ONLY;

Variable, auf die von außen zugegriffen werden soll

Name des Zugriffpfads

Angabe des Datentyps des Zugriffspfads mit SchreibLese-Berechtigung

END_VAR

Bsp. 6.4. Deklaration von Zugriffspfaden

Bsp. 6.4 zeigt den Aufbau für Deklarationen von Zugriffspfaden anhand der Variable BandLeer von Bsp. 6.6. Zugriffspfade können für folgende Variablenarten gebildet werden: -

Ein- oder Ausgangsvariablen von PROGRAM, globale Variable, Direkt dargestellte Variable.

Zugriffspfade machen diese Variablen unter neuem Namen über eine Konfiguration hinaus bekannt, so dass beispielsweise über Kommunikationsbausteine darauf zugegriffen werden kann. Falls diese Variablen vom Typ Feld oder Struktur sind, kann der Zugriffspfad nur für ein einzelnes ihrer Feld- oder Strukturelemente gebildet werden. Für Zugriffspfade ist standardmäßig nur ein lesender Zugriff (READ_ONLY) zulässig. Durch die Angabe READ_WRITE kann ein Überschreiben des Zugriffspfads durch andere Ressourcen explizit erlaubt werden. Diese Angaben werden unmittelbar hinter den Datentyp der Zugriffsvariablen gesetzt. Der Datentyp von Zugriffsvariablen muss identisch mit dem der dazugehörigen Variablen sein.

6.4 Konfigurations-Beispiel

253

6.4 Konfigurations-Beispiel Bsp. 6.5 zeigt eine Konfiguration in Übersichts-Darstellung. Dieses Beispiel wird in Bsp. 6.6 und Bsp. 6.7 textuell deklariert. Die Konfiguration besteht aus einem SPS-System mit zwei CPUs, denen mehrere Programme und Funktionsbausteine als Laufzeitprogramme zugeordnet werden. Teilabschnitte dieses Beispiels wurden in den vorangegangenen Abschnitten bereits erläutert.

Konfiguration

SPS_Zelle1

Ressource

CPU_Band

Task Laufzeitprogramm

Programm

Funktionsbaustein

T_Schnell Antrieb

ProgA

CPU_Walz

T_Periodisch Steuer

Schmier

ProgB

FB1

T_Unterbrech

ProgC

FB2

Bsp. 6.5. Beispiel für Konfigurationselemente mit POEs in Übersichts-Darstellung

In Bsp. 6.6 besteht die Maschinenzelle SPS_Zelle1 physikalisch aus 2 CPUs, von denen die erste zwei Tasks ausführen kann: eine schnelle, periodische mit kurzer Zykluszeit und eine langsamere periodische, während auf der zweiten CPU eine Task mit Interrupt-Verhalten läuft.

254

6 Zeitgemäße SPS-Konfiguration

CONFIGURATION SPS_Zelle1 VAR_GLOBAL FehlerCode AT %MW3 Start END_VAR

: : :

DUINT; WORD; INT;

RESOURCE CPU_Band ON CPU_001 TASK T_Schnell (INTERVAL := t#8ms, PRIORITY := 1); TASK T_Periodisch (INTERVAL := t#20ms, PRIORITY := 3); PROGRAM Antrieb WITH T_Schnell : ProgA (RegPar := %MW3); PROGRAM Steuer WITH T_Periodisch : ProgB (InOut := Start, R_Wert => FehlerCode, FB1 WITH T_Schnell, FB2 WITH T_Periodisch); END_RESOURCE RESOURCE CPU_Walz ON CPU_002 VAR_GLOBAL Trigger AT %IX2.5 : BOOL; END_VAR TASK T_Unterbrech (SINGLE := Trigger, PRIORITY := 1); PROGRAM Schmier WITH T_Unterbrech : ProgC; END_RESOURCE VAR_ACCESS RegelP : CPU_Band.Antrieb.RegPar : WORD READ_WRITE; BAND_LEER : CPU_Walz.%IX1.0 : BOOL READ_ONLY; END_VAR VAR_CONFIG Band.Antrieb.RegPar.C2 END_VAR

AT QB17

: BYTE;

END_CONFIGURATION

Bsp. 6.6. Textuelle Darstellung des Beispiels in Bsp. 6.5. Die Variablennamen und Namen von Programmen und FBs sind fett dargestellt.

Mit dem Konstrukt VAR_CONFIG wird der Variable C2, deren Speicherort bei der Deklaration in Programm ProgA noch offen blieb, ein konkretes Ausgangsbyte zugewiesen.

6.5 Kommunikation bei Konfigurationen und POEs PROGRAM ProgA VAR_INPUT RegPar : WORD; END_VAR VAR C2 AT %Q*: BYTE; END_VAR

END_PROGRAM

PROGRAM ProgB VAR_IN_OUT InOut : INT; END_VAR VAR_OUTPUT R_Wert : DUINT; END_VAR ... CAL Inst_FB2 ... END_PROGRAM

255

PROGRAM ProgC

... CAL Inst_FB3 ... END_PROGRAM

Bsp. 6.7. Programme zum Beispiel in Bsp. 6.6; FB3 ist dort nicht sichtbar, FB1 könnte z.B. der Ausnahme- und Fehlerbehandlung dienen.

In diesem Beispiel werden die Laufzeitprogramme Antrieb, Steuer und Schmier durch Verknüpfung der PROGRAMs ProgA, ProgB und ProgC mit TASKDefinitionen gebildet. Sowohl Programm Antrieb als auch FB-Instanz FB1 (dadurch unabhängig vom Programm Steuer) laufen auf CPU_Band als schnelle Tasks (T_Schnell), FB2 auf derselben CPU (CPU_001) in Programm Steuer als periodische Task (T_Periodisch). Das Programm Steuer wird hier verwendet, um auch das Laufzeitverhalten der verwendeten FB-Tasks festzulegen. Auf diese Weise Tasks zugeordnete FBs werden nach IEC 61131-3 unabhängig vom Programm ausgeführt. Beim periodischen Aufruf des Laufzeitprogramms Steuer wird der Eingangsparameter InOut mit der Variablen Start belegt. Nach Beendigung von Steuer wird dessen Ausgangsvariable R_Wert der globalen Variable FehlerCode zugewiesen. Auf CPU_Walz (zweite CPU) läuft das Programm Schmier als Interruptgetriebene Task (T_Unterbrech). FB3 erhält als Unterprogramm von ProgC dadurch automatisch dieselben Laufzeit-Eigenschaften. In diesem Beispiel sind CPU_001 und CPU_002 keine Variablen, sondern Hersteller-Bezeichnungen für SPS-Zentraleinheiten von SPS_Zelle1.

6.5 Kommunikation bei Konfigurationen und POEs Dieser Abschnitt beschreibt Möglichkeiten zum Datenaustausch zwischen Konfigurationen sowie innerhalb einer Konfiguration über gemeinsame Datenbereiche. Solche (strukturierten) Datenbereiche dienen der Kommunikation verschiedener Programmteile untereinander, zum Datenaustausch, für Synchronisationsmechanismen oder zur Diagnose-Unterstützung.

256

6 Zeitgemäße SPS-Konfiguration

Ziel der IEC 61131-3 ist es, mit Hilfe einheitlichen Kommunikationsmodells gut strukturierte SPS-Programme zu ermöglichen, die sowohl Inbetriebnahme und Diagnose erleichtern als auch die Anlagen-Dokumentation verbessern. Durch anwendungsgerechte Modularisierung einer Aufgabe entstehen wiederverwendbare Programmteile, die den Innovationszyklus bei der Entwicklung von SPS-Programmen verkürzen helfen. Die IEC 61131-3 legt fest, wie Programmteile miteinander kommunizieren, also Daten austauschen können. Dazu gibt es folgende Möglichkeiten: -

Direkt dargestellte Variable, Ein- und Ausgangsvariable bzw. Funktionswerte bei POE-Aufrufen, globale Variable (VAR_GLOBAL, VAR_EXTERNAL), Zugriffspfade (VAR_ACCESS), Kommunikations-Bausteine (IEC 61131-5) Aufrufparameter.

Die drei ersten Fälle dienen der Kommunikation innerhalb einer Konfiguration, während Zugriffspfade und Kommunikations-Bausteine zwischen Konfigurationen bzw. nach außen verwendet werden. Die Direkt dargestellten Variablen sind eigentlich nicht für die Kommunikation zwischen Programmteilen vorgesehen, obwohl dies als prinzipielle Möglichkeit hier mit aufgenommen wurde. Insbesondere ist das Schreiben auf SPS-Eingänge (%I...) dazu ungeeignet. Ausgänge (%Q...) sollten zur Steuerung des Prozesses und nicht zur Zwischenablage von Informationen verwendet werden. Diese Mechanismen können, wie in Tab. 6.3 gezeigt, auf mehreren Ebenen benutzt werden, wobei Konfigurationselemente und POEs verschiedene Zugriffsmöglichkeiten besitzen.

Kommunikationspfad Zugriffspfade Direkt dargest. Variable globale Variable externe Variable Kommunikations-Bausteine Aufrufparameter Legende: CON: RES: PROG: FB: FUN:

CONF x x x

RES x x

x

PROG x x x x x x

FB

FUN

x x x

x

CONFIGURATION RESOURCE PROGRAM FUNCTION_BLOCK FUNCTION

Tab. 6.3. Kommunikationsmöglichkeiten von Konfigurationselementen und POEs

6.5 Kommunikation bei Konfigurationen und POEs

257

Zugriffspfade dienen dem Datenaustausch zwischen Konfigurationen, also über die Grenzen eines SPS-Systems hinaus und sind auf der Ebene von Konfigurationen und Programmen zulässig. Direkt dargestellte Variable der SPS (z.B. über ein Prozessabbild oder durch direkten Zugriff auf die E/A-Peripherie, „%I.., %Q.., %M.“) erlauben ebenfalls eine (bedingte) Kommunikation zwischen Programmteilen, da sie systemweit wie globale Datenbereiche zur Verfügung stehen. Merker (%M..) können als SPSglobaler Datenbereich (z.B. zur Synchronisation von Ereignissen) eine Rolle spielen. Diese Variablen dürfen nur auf Programmebene oder höher deklariert werden (z.B. als global) und von Funktionsbausteinen als externe Variablen verwendet werden. Dies stellt ein wichtiges Unterscheidungsmerkmal der Programmierung nach IEC 61131-3 gegenüber bisher üblicher SPS-Programmierung dar. Globale Variable können für Konfigurationen, Ressourcen und Programme angelegt und auf diesen Ebenen benutzt werden. Funktionsbausteine können diese Datenbereiche zwar lesend und schreibend (als externe Variablen) benutzen, nicht jedoch selbst anlegen oder initialisieren. Funktionen besitzen keinen Zugriff auf globale oder externe Variablen. Externe Variable können von Programmen und Funktionsbausteinen importiert werden, wenn sie an anderer Stelle als global deklariert wurden.. Kommunikations-Bausteine sind spezielle Funktionsbausteine, die Daten vom Aufrufer zum Empfänger „paketweise transportieren“. Da diese FBs zum Programm dazugebunden werden, sind sie lokal innerhalb der Konfiguration bekannt und können nicht nach außen sichtbar sein. Die Definition geeigneter Standard-Kommunikationsbausteine befindet sich mit Teil 5 der IEC 61131 („Kommunikationsdienste“) noch in Bearbeitung und wird hier nicht ausgeführt. Aufrufparameter werden als Ein- und Ausgangsparameter beim Aufruf von POEs verwendet. Durch sie können Daten in POEs hinein bzw. aus POEs zurückgegeben werden. Wie in Kap. 2 erläutert wurde, kann die Parametrierung von Eingangsvariablen bzw. die Abfrage der Ausgangsvariablen von Funktionsbausteinen auch beliebig weit vor oder nach dem eigentlichen Aufruf erfolgen, so dass sich auch hier der Charakter eines Kommunikationsmechanismus ergibt, der über die Möglichkeiten bisheriger SPS-Programmierung hinausgeht. Ressourcen können Programmen bei der Zuordnung von Tasks Werte übergeben, wie es für Antrieb in Bsp. 6.6 gezeigt wurde. Bei jedem Aufruf des Programms werden diese Werte als Aktualparameter erneut übergeben bzw. als Ausgangsparameter gelesen.

“This page left intentionally blank.”

7 Innovative SPS-Programmiersysteme

Dieses Kapitel geht über die Festlegungen der IEC 61131-3 hinaus und beschreibt weitere Anforderungen an Programmiersysteme. Dies umfasst vor allem Markterfordernisse, die sich aus dem speziellen SPS-Umfeld; Anforderungen und Lösungen werden auf Basis der IEC 61131-3 Programmierkultur vorgestellt.

7.1 Anforderungen an innovative Programmierwerkzeuge Die Leistungsfähigkeit eines SPS-Programmiersystems kann man an folgenden drei Eigenschaften messen: -

Technologische Neuerung, Erfüllung der SPS-spezifischen Anforderungen, Kosten/Nutzen-Verhältnis.

Eine wesentliche Auswirkung der IEC 61131-3 war der Entfall der scharfen Trennung zwischen SPS, Prozessrechner und PC. Mit demselben Programmiersystem lässt sich Dank verschiedener Backend- Compiler Anwendercode generieren für -

-

Kompakt-SPS (Gerät, meist im Hutschienenformat, mit im Gehäuse integrierten Ein- / Ausgangsanschlüssen, proprietäres Betriebssystem), Modular- SPS (Gerät, meist 19 Zoll Platinengröße, welches über den Rückwand mit einer Vielzahl von Ein-Ausgabe- Steckmodulen kommuniziert, proprietäres Betriebssystem), Embedded Controller (Knotenrechner mit Netzanschluss z.B. Profibus oder CAN, proprietäres Betriebssystem) Embedded PC (Platine auf Basis der PC- Hardware; meist Windows-CE oder (Realtime-) Linux) Standard- PC (erweitert mit Ein- / Ausgangskarten, Windows EchtzeitErweiterung, unterbrechungsfreie Stromversorgung, …)

260

7 Innovative SPS-Programmiersysteme

Die Kombinationen sind vielfältig, alle können mit einem Programmiersystem, bzw. einer Programmiermethode bedient werden. Die Programmiersysteme laufen meist auf Windows-XP oder -Vista und sind über serielle Leitungen oder LAN an die Ziel- SPS angeschlossen. Die nachfolgenden Abschnitte gehen auf diese Eigenschaften sowie die wesentlichen Bestandteile eines Programmiersystems ein.

SprachEditoren

Compiler, Linker, Systemkonfigurator

Test & Inbetriebnahme Kommunik.Manager

Projektverwaltung

Geräteverwaltung

Dokumentation

Abb. 7.1. Wichtige Bestandteile eines modernen Programmiersystems

Ergänzungen zu den oben genannten Teilpaketen bilden beispielsweise (nicht Teil der IEC 61131-3 Norm): -

Werkzeuge zur Anlagen-Projektierung, Simulations-Werkzeuge, Allgemeine Datenverwaltungssysteme, Parametrier-Editoren, Logik-Analysator, Anlage-Diagnose, BDE-, SCADA Systeme, Protokollgeräte-Anschluss, CAD-Anschluss, Netzverwaltung.

7.2 Rückübersetzung (Rückdokumentation) Die Rückdokumentation ist eine klassische Forderung im SPS-Markt. Das SPSProgramm sollte rücklesbar sein, wenn es sich (außerhalb von Büroumgebungen) bereits in der Anlage befindet und beispielsweise zu Wartungszwecken geändert wird. Dabei sollte der SPS-Techniker die Möglichkeit erhalten, auch ohne dass die ursprünglichen Programmquellen auf einem PC zur Verfügung stehen, das Programm wieder lesen und ausdrucken sowie ändern zu können. Rückübersetzbarkeit beschreibt die Fähigkeit, die zur Darstellung einer POE benötigte Information allein aus der SPS gewinnen (Rückdokumentation) und für Programmänderungen verwenden zu können.

7.2 Rückübersetzung (Rückdokumentation) AWL Code

261

INTEL 8086 Mnemo-Code (Quelldarstellung)

VAR V1, V2, Vst: SINT; END_VAR LD AND ST

V1 V2 Vst

MOV AND MOV

AL, V1 AL, V2 Vst, AL

Bsp. 7.1. Beispiel eines rückübersetzbaren Quellcodes; zusätzlich bedarf es Information über die Variablen (Name, Adresse, Typ).

Die Eigenschaft der Rückübersetzung ist in verschiedenen Abstufungen zu finden: -

keine Rückübersetzung, Rückübersetzung mit Symbolik und Kommentaren, Rückübersetzung inkl. Grafik-Informationen, Quellcode in der SPS.

7.2.1 Keine Rückübersetzung Die meisten IEC-Systeme besitzen keine Rückübersetzungs-Eigenschaft. Die Anzahl von frei wählbaren symbolischen Namen, die bei einer Rücktransformation aus dem Maschinencode benötigt werden, hat sich deutlich vergrößert, was den Speicherausbau von SPSen oft sprengt. SPS-Prozessoren sind selten vom SPS-Hersteller entwickelte Bausteine (wie ASIC oder BitSlice), die mit einem eigens dafür entworfenen Maschinencode arbeiten. Aus Kostengründen werden fast ausschließlich Standardprozessoren verwendet. Diesen ausführbaren Code wieder in einen AWL- oder ST-Code zurückzuwandeln, ist ungleich schwieriger. Selbstverständlich müssen Programme nach einer Inbetriebnahme noch modifizierbar sein. Stand der Technik ist es, die gesamte Projekt-Information (Quellen, Bibliotheken, Schnittstellen- und Konfigurations-Information) auf der Festplatte zu halten. Idealerweise liegen dabei die Quellen in einer sprachunabhängigen, anwenderlesbaren Form vor und können in einer beliebigen Sprache dargestellt werden. Geeignete Sicherungsprogramme müssen vor dem Beginn einer weiteren Projektbearbeitung sicherstellen, dass die Programme auf der SPS mit dem Stand des Projekts auf der Festplatte übereinstimmen.

7.2.2 Rückübersetzung mit Symbolik und Kommentaren Der Binärcode eines Programms, der aus der SPS geladen wird, reicht allein nicht aus, um eine modifizierbare Quelle zu generieren. Es sind von der SPS Listen zu

262

7 Innovative SPS-Programmiersysteme

liefern, die Angaben über die aktuelle Verdrahtung beinhalten (CONFIGURATION). Dies umfasst die Zuordnung von Symbolischen Variablen an die physikalischen Adressen, die Verbindung globaler Variablen oder die Abbildung einzelner Programme an Tasks, Ressourcen, usw. Ein weiteres Informationspaket stellen die symbolischen Namen (für Variablen, Sprungmarken, etc.) dar, die es in einem ausführbaren Code in der Regel nicht mehr gibt. Diese Symboltabelle aus der Programm-Erstellungsphase mit der Zuordnung von Namen zu Adressen ist, evtl. ergänzt um Kommentare zu Anweisungen und Deklarationen, in der SPS zu speichern, wenn eine Rückübersetzung direkt aus der SPS benötigt wird.

7.2.3 Rückübersetzung inkl. Grafik-Information In der SPS befindet sich ausführbarer Code. Um aus diesem Code eine grafische Darstellung (KOP, FBS, AS) am PC zu erzeugen, muss der Code bestimmten syntaktischen Regeln gehorchen oder es sind im Code Zusatzdaten enthalten, die zum Aufbau genutzt werden. Die erste Variante besitzt deutlich kürzere Programme, doch es gibt Einschränkungen beim Aufbau der grafischen Darstellung.

7.2.4 Quellcode in der SPS Die Komplexität heutiger IEC-Systeme erschwert die Realisierung der Informationsverpackung im Code. Um alle zur Rückübersetzung nötigen Informationen auf der SPS hinterlegen zu können, bietet sich eine Lösung an, bei der komplette Projekte komprimiert in spezielle (langsame und billige) Festwertspeicher der SPS geladen werden. Von dort können sie später komplett auf die Festplatte des PCs rücktransportiert werden. Mit diesen Daten kann dann das Programmiersystem arbeiten wie in der Phase der Programmerstellung.

7.3 Sprachverträglichkeit Die fünf verschiedenen Sprachen der IEC 61131-3 stehen in einer speziellen Relation zueinander. Eine besondere Stellung nimmt die Ablaufsprache mit ihren beiden Darstellungsarten (textuell, grafisch) ein, da sie nicht zur Formulierung eines Berechnungsalgorithmus, sondern eher zur Strukturierung und Ablaufsteuerung eines Programms verwendet wird. Die Verknüpfungen und Berechnungen selbst sind in einer der anderen Programmiersprachen definiert und befinden sich in den Aktionsblöcken; siehe dazu die Bsp. 4.54 und 4.55 aus Abschn. 4.6.6.

7.3 Sprachverträglichkeit

263

Ein Programm besteht aus Bausteinen (POEs), die durch Aufrufe miteinander verbunden sind. Diese POEs sind soweit voneinander unabhängig, dass sie in unterschiedlichen Sprachen, ja selbst in IEC-fremden Sprachen definiert sein dürfen, solange sie sich an die Aufrufkonvention halten. Die IEC 61131-3 geht über diese Schnittstellen-Festlegung nicht hinaus. Es stellt sich folgende Frage: Besteht die Notwendigkeit, die in einer Sprache entwickelte Befehlssequenz in einer anderen Sprache darzustellen? Diese mehrsprachige Verwendung innerhalb eines Programms und evtl. wahlfreie Darstellbarkeit von POEs wird in den nächsten beiden Abschnitten unter den Stichwörtern Querübersetzbarkeit und Sprachunabhängigkeit gezeigt.

7.3.1 Querübersetzbarkeit Die IEC 61131-3 setzt nicht voraus, dass eine POE, die in einer Sprache entwickelt wurde, in einer anderen darstellbar sein muss. Die Diskussion über eine solche Notwendigkeit ist so alt wie die SPS selbst. Welche Gründe gibt es, dies dennoch zu fordern? Motivation für Querübersetzbarkeit. Ein wesentlicher Grund für eine Querübersetzbarkeit von Programmteilen sind Ausbildungsgrad und Tätigkeitsbereich von Technikern und Ingenieuren. Sie werden branchenspezifisch in unterschiedlichen Programmiersprachen geschult, was die notwendige Zusammenarbeit oft erschwert. Die Automobilbranche in den USA bevorzugt Kontaktplan, im europäischen Bereich ist AWL, bzw. zunehmend ST vertreten. Anlagenbauer ziehen den funktionsstrukturierten Aufbau von FBS vor. Ein Informatiker hat sicherlich keinerlei Schwierigkeiten mit ST. Also für jeden Geschmack etwas und doch von jedem bearbeitbar? Es gibt Aufgaben, die sich für bestimmte Sprachen besser eignen. Ein Speicherverwaltungssystem lässt sich sicherlich besser in AWL oder ST lösen als in Kontaktplan. Eine Förderbandsteuerung liest sich in Kontaktplan übersichtlicher als in ST. AS ist die geeignete Sprache für eine Schrittkettensteuerung. In vielen Fällen ist die Entscheidung für eine bestimmte bzw. alleinige Programmiersprache nicht mehr so leicht. Oft werden dieselben Programmteile von verschiedenen Anwendern benötigt. Ein SPS-Hersteller liefert beispielsweise in AWL geschriebene POEs, um dem Benutzer die Ansteuerung der SPS-Peripherie zu erleichtern. Beim Anwender kann es sich um einen Förderbandhersteller handeln, der die SPS zur Kontrolle und Steuerung von Endschaltern und Motoren benutzt – dabei bevorzugt in KOP

264

7 Innovative SPS-Programmiersysteme

arbeitet. Er passt die AWL-Quellen in KOP-Darstellung an seine Erfordernisse an, um dann das Förderband dem Anlagenbauer zu liefern. Dieser erstellt seine gesamte Anlage wiederum in FBS und benötigt dabei auch die Ansteuerungsprogramme für seine vollständige und einheitliche Dokumentation.

AWL: LD OR AND ST

ST: Var1 Var2 Var3 (* Kommentar *) Spule

KOP:

FBS:

0002

0002 (* Kommentar *)

(* Kommentar *)

Var1

Spule := (Var1 OR Var2) AND (* Kommentar *) Var3;

Var3

Spule

Var1

>=1

Var2

Var2

& Var3

Spule

Bsp. 7.2. Beispiel für eine Querübersetzung in vier verschiedenen Programmiersprachen der IEC 61131-3

Unterschiedlicher Ansatz der grafischen und textuellen Sprachen. Eine Schwierigkeit bei der Querübersetzung liegt in Art und Sichtweise der Werteberechnung. KOP und FBS kommen aus der Binär- bzw. Analogwertverarbeitung: es „fließt Strom“ oder: Werte werden ungetaktet und „parallel“ weitergegeben. Die textuellen Sprachen AWL und ST sind dagegen prozedurale Sprachen, d.h. ein Befehl wird nach dem anderen ausgeführt. Dies zeigt sich besonders bei näherer Betrachtung der Netzwerk-Auswertung aus Abschn. 4.4.4. Dazu zeigt Bsp. 7.3 ein Beispiel in Kontaktplan (FBS entsprechend).

7.3 Sprachverträglichkeit

LD JMPC ST AND JMPC

Var1 Marke1 Var2 Var3 Marke2

265

0001: Var1 Marke1 Var2

Var3 Marke2

a) AWL

b) KOP

Bsp. 7.3. Sequentielle Ausführung eines Programmstücks in AWL und parallele NetzwerkAuswertung in KOP stehen im Widerspruch zu der Forderung nach einfacher Querübersetzbarkeit.

Nach der Auswerteregel für grafische Sprachen (Abschn. 4.4.4) erhält Var2 in allen Fällen einen Wert zugewiesen. Wird das Netzwerk direkt nach AWL abgebildet, erhält Var2 nur eine Wertzuweisung, wenn Var1 = FALSE. Ansonsten müsste bei der Querübersetzung eine Umordnung der Elemente erfolgen (alle ST vor bedingtem JMP oder CAL); damit ändert sich aber bei einer erneuten Querübersetzung nach KOP das grafische Aussehen des Netzwerks. Sollen aus AWL KOP Netzwerke, ähnlich der Erweiterung von Var3 in Bsp. 7.3, aufgebaut werden, ist mit der Auswerteregel nicht mehr entscheidbar, ob nach Marke1 oder Marke2 gesprungen werden soll, wenn Var1 und Var3 TRUE-Werte besitzen. Die Problematik der Querübersetzbarkeit lösen viele Programmiersysteme (soweit sie überhaupt diese Funktionalität besitzen), indem in einem Netzwerk: -

nach einer Zuweisung keine weitere Verknüpfung erlaubt ist, der Verwendungsteil eines grafischen Netzwerks (Bsp. 4.40) von oben nach unten berechnet wird und bei einem Befehl der Ausführungssteuerung verlassen wird.

Unterschiede in den Sprachen beeinflussen die Querübersetzbarkeit. Es lässt sich nicht jede Sprache in eine andere überführen. Da AS eine Sprache für die Strukturierung darstellt, die sich zwar der anderen Sprachen bedient, vom Aufbau und Ablauf aber völlig anders konzipiert wurde, wird im Weiteren allein die Querübersetzbarkeit zwischen AWL, ST, KOP und FBS betrachtet.

266

7 Innovative SPS-Programmiersysteme

Einschränkungen bei KOP / FBS. Sprünge lassen sich zwar über Marken realisieren, widersprechen aber der Idee eines „parallel“ schaltenden Netzwerks. Manche Aufgaben wie Funktionen zur Betriebsmittelverwaltung (Stackoperationen,...) lassen sich nur sehr kompliziert und unleserlich programmieren. Konstrukte wie CASE-, FOR-, WHILE- oder REPEAT-Anweisungen sind nicht vorgesehen und müssten über Standard-Funktionen wie EQ oder aufwendige Netzwerk-Anordnungen realisiert werden. Beide Sprachen lassen im Gegensatz zu ST nur einfache Ausdrücke als Indexbezeichner von Feldern zu. KOP wurde zur Verarbeitung von booleschen Signalen (TRUE und FALSE) definiert. Alle anderen Datentypen wie Integer können zwar über Funktionen und FBs verarbeitet werden, es muss aber mindestens ein Ein- und Ausgang vom Typ BOOL sein und mit der „stromführenden Leitung“ verbunden sein. Dies kann das Programm unübersichtlich machen. Für diese nicht-boolesche Werteverarbeitung ist eine Darstellung in FBS günstiger. Nicht jedes textuelle Element besitzt eine Entsprechung in der grafischen Darstellung. Beispielsweise fehlt in KOP und FBS ein Teil der Negativ-Modifizierer von AWL. Möglich sind zwar JMP, JMPC, RET oder RETC, doch fehlen JMPCN und RETCN. Dies muss über weitere Verknüpfungen durch den Anwender oder zusätzliche (ungenormte) Grafikelemente des Programmiersystems formuliert werden. Einschränkungen bei AWL / ST. Der in KOP und FBS verwendete Begriff des Netzwerks findet sich in den textuellen Sprachen nicht wieder. In Kontaktplan lassen sich Attribute wie Flankenerkennung (P, N) direkt durch grafische Elemente darstellen. Diese Attributdarstellung im Anweisungsteil durchbricht das Konzept der sonst strikten Angabe der Variablen-Eigenschaften im Deklarationsteil. Hierfür gibt es in den textuellen Sprachen keine Anweisung. Die Verwendung von EN/ENO birgt eine weitere Schwierigkeit, da in AWL oder ST kein entsprechendes Sprachelement vorhanden ist. Somit muss jede in einer textuellen Sprache entwickelte benutzerdefinierte Funktion eine Auswertung und Zuweisung dieser Variablen vornehmen, um in den grafischen Sprachen darstellbar zu sein. Verwendet man EN/ENO in den Grafiksprachen und verzichtet darauf in den textuellen Sprachen, sind zwei Versionen von Standard-Funktionen notwendig (mit und ohne EN/ENO Behandlung), siehe auch Abschn. 2.7.

7.3 Sprachverträglichkeit

267

Querübersetzbarkeit AWL / ST. Die Hochsprache (ST) lässt sich leichter und effizienter in eine Assemblersprache (AWL) transformieren als umgekehrt. Beide Sprachen besitzen jedoch Einschränkungen bzgl. der gegenseitigen Querübersetzbarkeit, von denen je eine exemplarisch erwähnt wird: ST kennt keine Sprünge, während diese in AWL („Assembler“) zur Programmierung von Schleifen u.ä. benutzt werden müssen. Dies schränkt die Umsetzung mancher AWL-Programme ein. AWL kennt im Gegensatz zu ST nur einfache Ausdrücke für Indexbezeichner von Feldern und Aufrufparametern von Funktionen und FBs. Volle Querübersetzbarkeit nur durch Zusatzinformation erreichbar. Erlaubt ein KOP-System innerhalb eines Netzwerks mehrere Spulen und/oder bedingte Anweisungen (in FBS die mehrfache Weiterverarbeitung einer ausgehenden Linie) mit unterschiedlichen Werten (siehe dazu Bsp. 7.4), müssen vom Querübersetzer Hilfsvariablen eingefügt werden. Weiterhin ist sicherzustellen, dass im umgekehrten Fall aus den AWL-Anweisungen (entsprechend auch ST) von Bsp. 7.4 nicht mehrere KOP-Netzwerke aufgebaut werden. Geringfügige Modifikationen des AWL-Programms können daher große Änderungen am querübersetzten KOP-Netzwerk auslösen.

LD ST AND ST

V a r1 Z w ischMerker V a r2 V a r3

LD AND ST

Z w ischM e rker V a r4 V a r5

a) A W L

0001: Var1

Var2

Var3

Var4

Var5

ZwischMerker

b) KOP

Bsp. 7.4. Werden innerhalb eines Netzwerks Spulen und bedingte Anweisungen mit unterschiedlichen Wert-Zuweisungen verwendet, ist keine direkte Querübersetzbarkeit möglich. Dazu wird z.B. in AWL die Hilfsvariable ZwischMerker notwendig.

268

7 Innovative SPS-Programmiersysteme

LD

Var1

OR ( ST

Var3 ZwischMerker

AND

Var4 )

AND OR ( AND

Var2 ZwischMerker Var5 )

ST

Var7

a) AWL

0001: Var1

Var2

Var7

(* meist unzulässig *)

Var3

Var4

Var5

b) KOP

Bsp. 7.5. Grenzen der Querübersetzbarkeit entstehen durch komplizierte Klammer-Konstrukte und Zwischenmerker bei der Übersetzung in eine textuelle Sprache.

Das grafisch übersichtliche KOP-Netzwerk aus Bsp. 7.5 ist nicht direkt, d.h. mit einfachen Befehlen in AWL darstellbar. Es sind dazu eine Hilfsvariable (wie ZwischMerker) notwendig, die sich den Wert zwischen Var3 und Var4 „merkt“, und mehrere Klammerausdrücke. Die Abspeicherung einer Variablen mitten in einem Klammerausdruck wird von der IEC 61131-3 zwar nicht explizit ausgeschlossen, sollte aber vermieden werden, da auch vergleichbare Operatoren wie der bedingte Sprung nicht in Klammerausdrücken verwendet werden dürfen. Es gibt Programmiersysteme, welche die Grafik-Elemente aufgrund ihrer logischen Zusammengehörigkeit automatisch (optimiert) platzieren. Andere Systeme erlauben eine individuelle Anordnung durch den Anwender. Diese topografische Information muss in AWL oder ST mit Hilfe von Kommentarinformation gespeichert werden, soll später die gleiche Grafik aufgebaut werden. Das Mitführen solcher Topografie-Daten ist einem AWL/STAnwender nicht zumutbar. Deshalb besitzen die meisten Programmiersysteme die Platzierungsinformation nur in der internen Datenhaltung. Sie geht bei einer Querübersetzung nach AWL oder ST verloren. Somit gibt es keinen Weg von den textuellen Sprachen zurück zur Grafik, ohne dass sich die Struktur der Netzwerke mehr oder weniger stark verändert. Gütekriterien für die Querübersetzbarkeit. Wie den vorausgegangenen Ausführungen zu entnehmen ist, kommt es bei der Querübersetzbarkeit nicht auf komplette Abbildungsvorschriften an, die im strengen Sinn nicht zu erreichen sind.

7.3 Sprachverträglichkeit

269

Die Güte eines Programmiersystems zeigt sich eher daran, inwieweit es folgende Bedingungen erfüllt: 1) Die Umsetzungsregeln sollten so einfach und nachvollziehbar sein, dass der Anwender stets die Umsetzung in eine andere Sprache nachvollziehen kann. 2) Eine Umsetzung darf zu keinem anderen Programmaufbau führen (nur lokale Änderungen; Einheiten müssen zusammenbleiben). 3) Durch Querübersetzung darf es zu keiner Laufzeitänderung des Programms kommen. 4) Die Umsetzung darf keine Seiteneffekte mit sich bringen (andere Programmteile werden beeinflusst). 5) Semantische Mehrdeutigkeiten wie in Bsp. 7.3 müssen geklärt sein. Aufgrund der komplexen und fehleranfälligen Realisierung der Querübersetzbarkeit verzichten die meisten Programmiersysteme inzwischen auf diese Eigenschaft.

7.3.2 Sprachunabhängigkeit aufgerufener POEs Ein wesentliches Element der IEC 61131-3 ist die POE als eigenständige Einheit. Zur Programmierung eines Aufrufs dieser POE muss lediglich deren äußere Schnittstelle bekannt sein, es sind keine Kenntnisse über den Code erforderlich. So sollte es auch für den Top-Down Entwurf eines Projekts möglich sein, zuerst alle Schnittstellen der POEs festzulegen und erst danach den Code zu programmieren. Diese externe Schnittstelle wird üblicherweise vom Programmiersystem nach einer POE-Definition projektglobal zur Verfügung gestellt und besteht: -

bei Funktionen aus: Funktionsname und -typ, Namen und Datentypen der VAR_INPUT- und soweit vorhanden, VAR_OUTPUT- Parameter, bei FBs aus: FB-Name, Namen und Datentypen der VAR_INPUT-, VAR_OUTPUT- und VAR_IN_OUT- sowie der EXTERNAL-Parameter, bei Programmen aus: PROGRAM Name sowie Name und Datentyp aller dazugehörigen VAR_INPUT, VAR_OUT, VAR_IN_OUT, VAR_ACCESS Parameter und GLOBAL Deklarationen.

Eine POE kann andere Funktionen und FBs aufrufen, ohne die Sprache zu kennen, in der diese POE programmiert wurde. Somit muss das Programmiersystem auch nicht für jede Sprache einen eigenen Satz von Standard-Funktionen und -FBs zur Verfügung stellen. Diese Methode der „Blackbox“ kann auch für IEC 61131-3-fremde Sprachen genutzt werden, d.h. der Aufrufer besitzt bis auf die externe Schnittstelle keinerlei Kenntnisse über die Realisierung des aufgerufenen Bausteins. Sind die Aufrufschnittstellen des IEC 61131-3 Programmiersystems und die eines C-Compilers verträglich, kann ebenso ein C-Unterprogramm aufgerufen werden. Die IEC 61131-3 erlaubt ausdrücklich die Hinzunahme weiterer Programmiersprachen.

270

7 Innovative SPS-Programmiersysteme

7.4 Dokumentation Zur kostengünstigen Pflege von Anwenderprogrammen, sowie zur Erfüllung der heutigen Qualitätsanforderungen wie ISO 9000 gibt es verschiedene Dokumentationsformen: 1) Querverweisliste. Eine Tabelle gibt darüber Auskunft, welche symbolischen Namen (Bezeichner wie Variablen, Sprung- oder Netzwerknamen, POENamen und -Instanzen usw.) in welchen POEs verwendet werden. 2) Programmstruktur. Übersicht über die Aufrufhierarchie der POEs. Jede POE erhält dabei eine Liste aller von ihr aufgerufenen POEs. Die Schachtelungstiefe ist je nach System unterschiedlich. Diese Darstellung kann tabellarisch oder grafisch erfolgen. 3) Zuordnungsliste (auch Verdrahtungsliste). Diese Liste enthält die (symbolisch) deklarierten physikalischen Ein- und Ausgänge des Programms (Direkt dargestellte und Symbolische Variablen) und weist sie Hardware-Adressen zu (E/A-Peripherie). 4) Belegungsliste. Tabellenartige Übersicht über die Verwendung der E/A-Peripherie durch das Programm, nach SPS-Adressen sortiert. Mit Hilfe der Belegungsliste lassen sich bei einer Programmerweiterung schnell freie Plätze der E/A-Peripherie finden sowie die Zuordnung von Programm und SPS maschinennah dokumentieren. 5) Anlagen-Dokumentation. Eine (meist grafische) Beschreibung einer kompletten Anlage. Das einzelne Automatisierungsgerät tritt dabei nur noch als „Blackbox“ auf. Eine Gesamtanlage besteht oft aus mehreren SPSen, Maschinen, Ausgabegeräten usw. Die Beschreibung dieser Ebene ergänzt die Dokumentation nach oben hin. Sie enthält die topologische Anordnung der einzelnen SPS-Stationen und anderer Komponenten sowie deren Verdrahtung untereinander. Dafür wird oft auf ein marktübliches Zeichenprogramm oder CAD-System zurückgegriffen. 6) Programmdokumentation. Programmquellen der POEs, die vom Programmiersystem erstellt werden. Die Druckausgaben sollten möglichst die gleiche Struktur und Inhalte der POEs zeigen wie am Bildschirm. 7) Konfiguration. Die Konfiguration – definiert in der IEC 61131-3 – beschreibt, welche Programme auf den SPS-Ressourcen mit welchen Eigenschaften ablaufen. Diese Möglichkeiten sind zwar durch die IEC 61131-3 nicht vorgeschrieben, haben sich aber im Laufe der Jahre zur Beschreibung des Programms (oft einheitlich) entwickelt.

7.4 Dokumentation

271

7.4.1 Querverweisliste Diese Liste ist auch unter dem englischen Namen „Cross Reference List“ in der PC-Welt bekannt. Sie beinhaltet: -

-

alle in einem Programm (selten: Projekt) verwendeten symbolischen Namen, den Datentyp von Variablen, FB-Typ bei Instanznamen, Funktionstypen bei Funktionen sowie besondere Attribute wie RETAIN, CONSTANT oder READ_ONLY und Variablenart (VAR_INPUT, ...), den POE-Namen mit Typ, sowie die Zeilennummer, in welcher der symbolische Name (ggfs. instanziiert) verwendet wird, die Zugriffsart an diesen Programmstellen, die POE, in der die Deklaration vorgenommen wird.

Manche Systeme stellen diese Symbole nur POE-weise zusammen oder beschränken die Liste auf globale/externe Daten. Die Querverweisliste eignet sich sehr gut, um z.B. bei der Fehlersuche das Auffinden von Programmstellen zu erleichtern. Die Sortierkriterien sind vielfältig. Die wohl wichtigste Darstellung ist eine alphabetische Auflistung der Symbole. Weiterhin kann z.B. nach Symboltyp (Ein-/Ausgangsvariable, Funktionsname, FB-Name,...) oder Datentyp (wie Byte, INT, usw.) sortiert werden.

Symbolname

POE-Name

POETyp

Temp_Sensor

SOND.POE SOND.POE STEUE.POE

Prog Prog FB

ZeilenNr

Zugriffsart

10 Deklarat. 62 Schreiben 58 Lesen

Datentyp Fun-Typ FB-Typ INT

Attribut Var Art

Retain

GLOBAL GLOBAL EXTERN.

...

Bsp. 7.6. Ausschnitt aus einer Querverweisliste, sortiert nach Symbolnamen

7.4.2 Zuordnungsliste (Verdrahtungsliste) Die Zuordnungsliste stellt alle Variablen, denen im PROGRAM oder in der KONFIGURATION physikalische E/A-Peripherie zugewiesen werden, und die Zugriffspfade zusammen. Hier sind oft Hilfsmittel erforderlich, mit denen diese symbolischen Variablen auf andere physikalische Adressen gelegt werden können (Umverdrahtung). Dies wird dann erforderlich, wenn das Programm in eine andere Umgebung (z.B. eine andere Anlage mit anderen Anschlüssen) portiert wird.

272

7 Innovative SPS-Programmiersysteme

Symbolname Temp_Sensor_1 Temp_Sensor_2 Temp_Steuer Temp_Stand ...

E/A-Peripherie %IB0 %IB2 %QB4 %MB1

Bsp. 7.7. Ausschnitt aus einer Zuordnungsliste (Verdrahtungsliste)

7.4.3 Kommentierbarkeit Ein wesentlicher Bestandteil der Dokumentation ist erklärender Text in Form von Kommentar. In Programmquellen kann er an folgenden Stellen, siehe auch Bsp. 7.2, einfließen: -

Kommentar kann in ST und AWL überall dort eingefügt werden, wo Leerzeichen erlaubt sind. Die IEC 61131-3 macht keine Aussagen zu Kommentaren in den grafischen Sprachen. Es hat sich aber bereits in der Vergangenheit gezeigt, dass Netzwerkkommentare, die den Aufbau und das Verhalten des folgenden Netzwerks beschreiben, eine wichtige Dokumentationsstütze darstellen.

Manche Programmiersysteme verhindern über Menü-Einstellungen das (versehentliche) Überschreiben des Programms, um z.B. für Service-Personal nur Kommentaränderungen zuzulassen.

7.5 Projektverwaltung Die Projektverwaltung hat die Aufgabe, sämtliche zur Programmierung eines Projekts notwendigen Informationen konsistent zu verwalten. Dazu zählen: -

Quell-Information, - die Quellen der erstellten POEs mit - Typ-Definitionen, Deklarationen von globalen Daten, Beschreibung von VAR_ACCESS Variablen, ... , - Aufruf-Schnittstellenbeschreibung aller POEs zur Darstellung und zur Durchführung der erforderlichen Schnittstellenprüfungen, - Versionskontroll-Systeme zur Datenhaltung von Quellen,

7.5 Projektverwaltung

273

-

-

-

-

Zugriffs-Beschränkungen (Passwort-Ebenen) zu: - POEs ändern, - Programme ausgeben, - Bibliotheken. Objekt-Information, - übersetzte Quellen (Zwischencode, Objekte, ausführbare Dateien), - Projekterstellungs-Prozeduren (Aufrufabhängigkeiten, Erstellungs- und Änderungsinformation zur Steuerung von zeitlichen Übersetzungsabhängigkeiten wie MAKE, Batches, ...), - Bibliotheken (Standard-Funktionen, Standard-FBs, Hersteller-FBs, Kommunikations-FBs; Anwenderbibliotheken). On-line-Information, - Dateien zur Parametrierung (Rezeptur) des Projekts, - Geräte- und Konfigurations-Beschreibungen (SPS-Gerätebeschreibung, Peripheriebaugruppen, ...), - Spezielle Information für den „on-line“-Test (Symbole, Haltepunkte, ...), - Kommunikations-Information (herstellerspezifische Übertragungsprotokolle, Schnittstellen, ...). Dokumentation (wie Querverweisliste, Belegungsliste, Programmstruktur,...).

Die Projektverwaltung ordnet und archiviert alle anfallenden Daten. Warum reicht dazu in der Regel kein reiner Dateimanager (z.B. Windows-Explorer) aus? Die POEs besitzen Abhängigkeiten. Die gleiche POE kann in einem Projekt von mehreren Programmen verwendet werden, obwohl sie evtl. nur einmal als Datei vorhanden ist. Funktionsnamen und FB-Typen besitzen projektglobale Gültigkeit (FB-Instanzen, soweit sie nicht GLOBAL deklariert sind, nur POE-weit!). Beim POE-Aufruf (CAL) benötigen die Compiler und Editoren SchnittstellenInformation über die aufgerufene POE (Parametertypen, ....). Unterschiedliche Informationen wie Binär-Dateien und Konfigurationsdateien müssen zusammengebracht werden. Um einen ständigen Neuaufbau solcher Informationspakete zu vermeiden, kann eine Projektverwaltung erzeugte Informationen aufnehmen und bei Bedarf anderen Komponenten eines Programmiersystems zurückliefern. Abb. 7.2 zeigt das Festplattenverzeichnis (D:), das sich in Unterverzeichnisse aufgliedert. Um die Zusammenhänge eines Projekts zu visualisieren, müssen zusätzlich Aufruf- und Umgebungsabhängigkeiten ausgewertet werden, damit diese Relationen, siehe Abb. 7.3, gezeigt werden können.

274

7 Innovative SPS-Programmiersysteme

D: \

Verz1

Hersteller POEs

Verz2

Standard FBs und FUNs

Verz3

: Verzeichnis

Binär Projekt A

Dateien

. . .

Konfigurat. Dateien

. POE -Verz1

POE -Verz11

POE -Verz12 POE -Verzx

Abb. 7.2. Datenhaltung für Quellen und Bibliotheken auf der Festplatte (hier D:). Das Programmiersystem sollte eine Verzeichnisstruktur zulassen, die der Anwender entsprechend den Projekterfordernissen frei wählen kann; z.B. Verwendung des Windows Dateisystems.

Das Programmiersystem sollte dabei helfen, den Aufbau eines Projekts zu verstehen. Ein Projekt kann aus mehreren Konfigurationen (SPSen) bestehen. Die Beschreibung einer solchen Konfiguration ist in Kap. 6 zu finden. Eine Konfiguration kann mehrere Ressourcen (CPUs) verwenden. Jede Ressource besitzt eine Spezifikation ihrer Hardware (Resource1 Datei). Auf der einzelnen Ressource können mehrere Programme (Programm1, ...) ablaufen, die ihrerseits durch POEs und deren Aufrufe beschrieben sind. Somit kann es vorkommen, dass zwei POE-Instanzen in Abb. 7.3, die in unterschiedlichen Programmen verwendet werden, durch ein und dieselbe POE definiert sind, die nur einmal auf der Festplatte oder Datenbank hinterlegt ist.

7.5 Projektverwaltung

275

Konfigurations- und Programmebenen POE Instanzen

Konfiguration 1

Konfig.1 Datei

Ressource 1

Programm 1

Ressource1 Datei

Programm 2 Ressource 2

Ressource2 Datei

Konfiguration 2

D:\

Konfig.2 Datei

Abb. 7.3. Die logische Struktur von Projekten besteht aus Konfigurationen, Ressourcen und POE-Aufrufhierarchien. Da diese Struktur nicht mit der physikalischen Verzeichnisstruktur von Abb. 7.2 übereinstimmt, sind weitere Visualisierungshilfen wünschenswert.

Zur Informationssuche können unterschiedliche Regeln vereinbart sein. Soll z.B. das auf der Resource1 ablaufende Programm1 übersetzt werden, muss das System für einen Übersetzungs- und Linkerlauf alle dazugehörenden Anwender-, Systemund Hersteller-POEs zusammensuchen. Ist ein aufgerufener POE-Name doppelt vorhanden, ist zu entscheiden, ob eine Überdeckung (z.B. Anwender-POE geht vor Hersteller-POE) oder Fehlermeldung erfolgt; die IEC macht hierüber keine Aussage. Um die Übersetzungszeit bei Änderungen kurz zu halten, ist es vorteilhaft, wenn nur die zur Konfiguration, Ressource oder zum Programmzweig gehörenden Teile übersetzt werden. Wurde beispielsweise nur im Programm1 geändert, müssen nicht die übrigen Programme (oder andere Ressourcen), die diese POE nicht benötigen, übersetzt werden. Zu den Aufgaben einer Projektverwaltung gehören somit: -

Eintragen neu erstellter Dateien (Quellen, Fehlermeldungsdateien, Schnittstellenbeschreibungen), Einkopieren von projektfremden Dateien (aus anderen Projekten), Anzeigen aller vorhandener POEs,

276

-

7 Innovative SPS-Programmiersysteme

Umbenennen, Löschen von POEs, Aufbau einer Informations-Struktur, die den Projektaufbau (Aufrufhierarchie, Zusammenhänge) für den Anwender transparent macht, Verwaltung und Lieferung aller Informationen (POEs, Schnittstellen, Aufrufhierarchie, Binärdateien usw.), die das restliche Programmiersystem zur Erstellung eines Projekts benötigt.

Manche IEC 61131-3 Programmiersysteme hinterlegen die Daten in einzelnen Dateien (z.B. eine pro POE) auf der Festplatte, manche in Datenbanken. Diese Daten dürfen nur über die Projektverwaltung manipuliert werden. Um Anfragen an die Projektverwaltung (z.B. vom Linker) möglichst schnell beantworten zu können, kann ein Teil der Information bereits vorverarbeitet werden, ohne bei jeder Anfrage das gesamte Dateisystem neu untersuchen zu müssen.

7.6 Test&Inbetriebnahme-Funktionen Die Programmentwicklung erfolgt im ersten Schritt auf einem PC ohne die SPS. Sind die wichtigsten Teile erstellt, erfolgt erfahrungsgemäß die weitere Arbeit direkt mit der SPS in der realen Umgebung. Dabei werden typischerweise folgende Aufgaben durchgeführt: -

-

Übertragung des gesamten Projekts oder einzelner POEs (nach Änderungen) auf die Steuerung, Übertragung des Projekts von der Steuerung auf den PC, Ändern des Programms in der SPS (im Zustand „RUN“ oder „STOP“), Starten und Stoppen der SPS, Anzeigen der Werte bestimmter Variablen (Status), Direktes Setzen der E/A-Peripherie oder Variablen (engl.: Forcing), „Abschalten“ der physikalischen SPS-Ausgänge, um unsichere Anlagenzustände während des Tests zu vermeiden. Die Programmabarbeitung und die Wertzuweisung an direkte Variable erfolgt wie im normalen Betrieb. Zusätzliche Software oder Hardware sorgt aber dafür, dass die errechneten Werte nicht auf die physikalische Ausgangsperipherie geschrieben werden, SPS-Systemdaten, Kommunikation- und Netzwerk-Information auslesen, Programmsteuerung (Haltepunkte, Einzelschritt, ...).

Diese Funktionalitäten werden in unterschiedlichem Umfang und Ausprägung von den Programmiersystemen angeboten. Die IEC 61131-3 macht darüber keine Aussagen.

7.6 Test&Inbetriebnahme-Funktionen

277

7.6.1 Programmtransfer Nachdem (oder während) eine POE mit einem Editor erstellt und syntaktisch überprüft wurde, erfolgt die Erstellung des SPS-spezifischen Codes. Dies kann Maschinencode sein, der direkt auf der SPS ausgeführt wird, oder Anweisungen, die auf der SPS durch einen Interpreter abgearbeitet werden. Dieser Objektcode wird vom Programmiersystem mit den übrigen POEs des Programms zusammengepackt (Link-Vorgang). Es fehlen nun noch: -

die Verbindung des ausführbaren Codes mit der Beschreibung der CONFIGURATION (Taskzuweisung), eine evtl. Anpassung der Hardware-Adressen an die tatsächlichen physikalischen Adressen der SPS, spezielle Parametrierung des SPS-Betriebssystems.

Diese Aufgaben können durch ein Systemkonfigurator genanntes Softwareprogramm durchgeführt werden. Es gibt auch Implementierungen, bei denen das SPS- Betriebssystem einen Teil dieser Aufgaben übernimmt. Das Gesamtpaket muss nun vom PC auf die Steuerung gebracht werden. Ein als Kommunikationsmanager bezeichnetes Programm sorgt dafür, dass eine physikalische und logische Verbindung zu der SPS aufgebaut wird (z.B. ein firmenspezifisches Protokoll über die USB- Schnittstelle oder eine Feldbusverbindung). Diese Software führt eine Reihe von Überprüfungen aus, die zum Teil für den Anwender nicht sichtbar sind, wie: -

ist die Kontaktaufnahme mit der SPS erfolgreich? befindet sich die SPS in einem Zustand, um neue Programme aufnehmen zu können? Kann die SPS in diesen Zustand gebracht werden? Entspricht die Hardware-Konfiguration der SPS den im Programm vorgegebenen Bedingungen? Besteht eine Zugangsberechtigung des aktuellen Anwenders zu dieser SPS? Visualisierung des aktuellen Zustands der Kommunikation.

Dann erfolgt die Übertragung des Programms sowie der zum Ablauf relevanten Daten. Das SPS-Programm kann starten (Neustart).

7.6.2 Online-Änderung des Programms Sollen Bausteine eines aktiv laufenden SPS-Programms (SPS in „RUN“) geändert werden, kann dies erfolgen, -

indem die POE im PC geändert und das gesamte Programm vom Programmiersystem völlig neu erstellt wird. Anschließend wird alles komplett in die SPS geladen. Soll dies im laufenden Betrieb erfolgen, muss ein zweiter

278

-

-

7 Innovative SPS-Programmiersysteme

Speicherbereich zur Verfügung stehen, auf den nach erfolgtem Transfer umgeschaltet wird, da die Transferzeit i.a. zu lange dauert, um das zyklische Programm für diese Zeit anzuhalten. indem die POE im PC geändert und nur dieser Teil auf die SPS transferiert wird. Dies erfordert aber eine Bausteinverwaltung auf der SPS, die diese POE entgegennimmt und nach erfolgter Übertragung den alten Baustein aus- und den neuen einhängt. Da die nun ungültige POE aufgrund der unterschiedlichen Größen nicht vollständig überschrieben werden kann, erfolgt zu gegebener Zeit ein „Zusammenschieben“ oder „Komprimieren“ aller gültigen POEs im Speicher der SPS (engl.: „garbage collection“). indem nur einzelne Netzwerke (AS, KOP oder FBS) oder Anweisungen (AS, ST und AWL) ausgetauscht werden. Dies ist nur dann möglich, wenn damit die anderen Teile der POE nicht beeinflusst werden. So dürfen sich beispielsweise die Sprungmarken in den anderen Netzwerken nicht verschieben, wenn das SPS-Betriebssystem keine entsprechende Sprungmarkenverwaltung beinhaltet.

7.6.3 Fernbedienung: Start und Stopp der SPS Die Hardware einer SPS besitzt üblicherweise einen Schalter zum Starten und Stoppen. Diese Funktionalität kann auch oft vom Programmiersystem gesteuert werden. Die IEC 61131-3 definiert dazu verschiedene Anlaufverhalten der SPS (siehe auch Abschn. 3.5.3): 1) Kaltstart (auch: Neustart). Die SPS startet ihr Programmsystem ohne jegliche Vergangenheitsinformation („Gedächtnis“). Dies ist insbesondere nach dem Laden des Programms der Fall. 2) Warmstart (auch: Wiederanlauf). Das Programm setzt seine Abarbeitung nach einem Spannungsausfall an der unterbrochenen Stelle (z.B. innerhalb eines FBs) fort. Alle mit dem Attribut „RETAIN“ versehenen Variablen sind mit dem Wert belegt, den sie vor der Unterbrechung besaßen. 3) Warmstart am Programmstart. Das Programm startet ebenfalls mit dem Wert der Retain-Variablen, jedoch nicht an der unterbrochenen Stelle, sondern am Programm-Anfang, da die parametrierte maximale Unterbrechungszeit überschritten wurde. Vom Anwender kann in der Regel nur ein Kaltstart veranlasst werden, die Warmstarts erfolgen automatisch bei Spannungswiederkehr. Weitere Einstellungsmöglichkeiten eines Programmiersystems sind: -

Anhalten der SPS (mit den aktuellen oder „sicheren“ Werten der physikalischen Ausgänge), Löschen von Speicherbereichen, um unkontrolliertes Anlaufen zu vermeiden, Einstellen spezieller Betriebssystemzustände wie Testmodus, max. Zykluszeit.

7.6 Test&Inbetriebnahme-Funktionen

279

7.6.4 Variablen- und Programm-Status Der wichtigste Test während der SPS-Test&Inbetriebnahme ist die Beobachtung von Variablen („Merker“) und E/A-Peripherie. Mögliche Darstellungen sind Bsp. 7.8 zu entnehmen. Variable Spule Var1 Var2 Var3

Typ BOOL BOOL BOOL BOOL

Wert 1 1 0 1

a) Variablen-Liste LD OR AND ST

Var1 Var2 Var3 Spule

Spule := Var1 OR Var2 AND Var3 1 1 0 1

1

0 1 1

b) AWL (Variablenstatus)

c) ST (Variablenstatus)

0002:

0002:

(* Kommentar *)

(* Kommentar *)

1

1

>=1

1 1 0

&

0 1

1

d) KOP (Variablenstatus) LD OR AND ST

Var1 Var2 Var3 Spule

e) FBS (Variablenstatus) 1

1 1 1

Spule := Var1 OR Var2 AND Var3 1 1

1 1

f) AWL (Aktuelles Ergebnis)

g) ST (Ausdruck)

Bsp. 7.8. Das in Bsp. 7.2 aufgeführte Beispielprogramm in einer Momentaufnahme des Status während der Test&Inbetriebnahme-Sitzung in verschiedenen Darstellungsarten. Diese können auch miteinander kombiniert werden (wird fortgesetzt).

280

7 Innovative SPS-Programmiersysteme

0002: (* K o m m e n tar *)

V a r1

V a r3

0002: (* Kommentar *)

S p u le

Var1

>=1

Var2

V a r2

h) KOP (Stromflussanzeige)

& Var3

Spule

i) FBS (Programmstatus)

Bsp. 7.8. (Fortsetzung)

Es gibt, je nach Realisierung in der SPS und/oder im Programmiersystem, mehrere Varianten, um einen Überblick über den aktuellen Datenfluss zu erhalten: 1) Variablenausgabe. usgabe von einer Variablenliste (a). Die darin enthaltenen Variablen werden von der SPS abgefragt und ihre Werte laufend am Bildschirm aktualisiert. Diese Ausgabe wird typischerweise dann verwendet, wenn Werte beobachtet werden, die aus unterschiedlichen Programmteilen stammen. Je nach Programmiersystem können auch strukturierte Variablen mit den Werten ihrer Strukturkomponenten angezeigt werden. 2) Variablenstatus.Es werden alle Variablen eines bestimmten Code-Abschnitts angezeigt. In Bsp. 7.8 werden die Werte von Var1, Var2, Var3 und Spule in einem separaten Fenster (a) oder direkt in der Grafik angezeigt (b-e). 3) Programmstatus.auch: Power Flow; Stromflußanzeige). Statt einzelner Variablenwerte werden die Verknüpfungsergebnisse (wie Aktuelles Ergebnis; siehe Abschn. 4.1.2) ausgegeben (f-i). Dies erfolgt in den grafischen Sprachen durch die Ausgabe von dicken/dünnen Linien (TRUE/FALSE) bei booleschen Verknüpfungen oder Angabe von Zahlenwerten an den Verbindungslinien. Durch Zwischenwert-Berechnungen des PCs können auch Werte angezeigt werden, die nicht unmittelbar an Variablen geknüpft sind (z.B. der Operator NOT; ODER-Verbindung in KOP). Die Qualität der erhaltenen Werte ist von der Funktionalität, Geschwindigkeit und den Synchronisationsmöglichkeiten des Programmiersystems und der angekoppelten SPS abhängig.

7.6 Test&Inbetriebnahme-Funktionen

281

Das „Sammeln“ der Werte auf der SPS kann, abhängig von den Möglichkeiten des Betriebssystems und der Hardware, zu verschiedenen Zeitpunkten erfolgen: -

synchron, asynchron, bei Änderung.

Synchroner Status. Die Werteausgabe erfolgt am Ende des Programmzyklus. Die Werte werden somit immer an der gleichen Programmstelle erzeugt (konsistenter Datensatz). Dies ist auch der Augenblick, in dem die Variablen, die mit der E/APeripherie verbunden sind, auf die Peripherie geschrieben werden (Austausch des Prozessabbilds). Im zyklischen Betrieb ist das Programm allerdings wesentlich schneller als die Frequenz der Anfragen, so dass nur in jedem x-ten Zyklus ein Wertepaket zurückgereicht werden kann. Asynchroner Status. Das Programmiersystem fordert ständig (asynchron zum SPS-Programm) einen neuen Datensatz der angegebenen Variablen an, die auf der SPS zum Zeitpunkt des Eintreffens der Anforderung zusammengestellt werden. Es handelt sich somit um eine Momentaufnahme der spezifizierten Speicherbereiche. Status bei Änderung. Die Ausgabe eines Werts erfolgt nur bei Änderung (z.B. Flanke) einer Variablen. Dies erfordert in der Regel spezielle Hardwarevorrichtungen (Adressüberwachung) in der SPS. Komfortable Systeme bieten zusätzlich Datenanalyse-Tools an. Damit können Variablen in ihrem zeitlichen Verlauf beobachtet werden (Logikanalyse), wie Abb. 7.4 skizziert.

60 50

RealVar_x RealVar_y

40 30

BoolVar

20

1

10 0

m Sek

0 m Sek

Abb. 7.4. Beispiel einer Datenanalyse zweier Real- und einer Bool-Variablen

Die Anzeige von Variablenwerten in der Programmgrafik erreicht schnell ihre Grenze, wenn Felder oder umfangreiche Strukturen mit ihren Werten angezeigt

282

7 Innovative SPS-Programmiersysteme

werden sollen. Hierfür sind separate Variablenfenster wegen der Fülle der Information geeigneter. Zu den anzeigbaren Werten zählen nicht nur die Variablenwerte, dazu gehören auch Parameter von Funktionen und FBs. Derzeit noch selten realisiert ist die Ausgabe des Datenflusses zwischen einzelnen POEs, wie in Abb. 7.5 dargestellt.

fb1 prog1

Typ1

20,40

fun1

30 50

fun2

100 fb2 Typ2

undefiniert fun1 undefiniert

Abb. 7.5. Darstellung der Aufruf-Hierarchie der POEs mit ihren aktuellen Parametern zur Laufzeit des SPS-Programms

Es reicht bei der Anforderung zur Ausgabe von Variablenwerten nicht aus, den Namen der gewünschten POE anzugeben. Mit der alleinigen Angabe von „fun1“ in Abb. 7.5 ist unklar, welche Daten ausgegeben werden sollen, da diese POE zweimal benutzt wird und bedingt durch unterschiedliche Aufrufparameter unterschiedliche Werte liefern wird. Bei FBs ist die Angabe des POE-Namens nicht ausreichend, da der FB-Typ mehrfach instanziiert sein kann und damit unterschiedliche Instanzdaten besitzt. Auch die zusätzliche Angabe des Instanznamen ist nicht eindeutig, da ein FB-Typ in verschiedenen POEs mit gleichem Instanznamen instanziiert sein kann und damit mehrere Instanzen mit gleichem Namen verwendet werden. Zur eindeutigen Identifikation ist somit der Aufrufpfad, bei Funktionen sogar die Aufrufstelle, anzugeben. Eine weitere Schwierigkeit liegt darin, dass Funktionen bzw. deren lokale Variablen nur während der Abarbeitung dieser POE existieren, andernfalls undefiniert sind.

7.6 Test&Inbetriebnahme-Funktionen

283

7.6.5 Forcing Um das Programm- und Anlagenverhalten bei der Inbetriebnahme testen zu können, ist das „Zwangssetzen“ bestimmter Speicherbereiche der SPS hilfreich. Um dem zu testenden Programm einen gewissen Anlagenzustand vorzuspiegeln – damit soll z.B. die Bearbeitung bestimmter Programmteile erzwungen werden – werden über Eingaben am Programmiersystem bestimmte Variablen fest mit Werten belegt und an die SPS übertragen, die diese Werte anstelle der tatsächlichen Werte verwendet.

Variable Var_Loc Var3 ...

%IW0: %IW1: ...

Datentyp BOOL INT

POE-Instanz FB1 FB1

Lokale Variablen zugewiesener Wert 1 20

Direkt dargestellte Variablen (WORD) (Bits 0 bis 15) (Bits 16 bis 31)

0 0 1 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0

Start Adresse %QW20: ...

Variablen-Name Endwert

Symbolische Variablen (Integer) zugewiesener Wert 11.233

Bsp. 7.9. Beispiel für das Forcing von Variablen und E/A-Peripherie (hier boolesche und ganzzahlige Werte). Bei der Namensangabe („POE-Instanz“) muss ggf. die Aufrufhierarchie berücksichtigt werden, bei Funktionen auch die Programmstelle; siehe dazu Abschn. 7.6.4.

Solange die SPS vom Programmiersystem im Zustand „Forcing“ gehalten wird und beispielsweise mit den in Bsp. 7.9 beschriebenen Parameter versorgt wird, erhält das Programm jedes Mal den eingegebenen booleschen Wert 1, wenn es %IX0.2, %IX0.6 oder %IX0.14 anspricht. Die Variablen werden beim Erreichen des Programmanfangs (Zyklus) einmal belegt und können dann vom Programm überschrieben werden. In anderen Implementierungsvarianten sorgt das SPS-System dafür, dass keinerlei Überschreiben erfolgt.

284

7 Innovative SPS-Programmiersysteme

7.6.6 Programmtest Zum Testen von Programmen gibt es die Funktionen Haltepunkt und Einzelschritt, die auch aus dem PC-Bereich bekannt sind: -

-

Haltepunkt (Rück-) Setzen. An einer vom Anwender beschriebenen Stelle soll die Programmausführung gestoppt werden und auf weitere Anweisungen des Anwenders gewartet werden. Komfortable Systeme bieten hierbei die Möglichkeit mehrstufiger Bedingungen an: „Wenn Funktion_1 aufgerufen, Variable_X gesetzt und Funktion_2 erreicht ist, dann halte bei Befehlszeile 20 des FB4...“. Auch hier gilt bei IEC-Programmen, dass neben der Angabe der Anweisungszeile der POE-Name bzw. Instanzname nicht ausreicht. Vielmehr muss die Stelle in der Aufruf-Hierarchie genannt werden; siehe Abb. 7.5. Einzelschritt. Nach dem Erreichen eines Haltepunkts erfolgt die Ausführung des nächsten Befehls bzw. grafischen Elements.

7.6.7 Programmtest in Ablaufsprache Eine besondere Hilfestellung ist bei AS-strukturierten Programmen gefordert. Je nach Komfort unterstützt das Programmiersystem den Anwender bei folgenden Aufgaben: -

(Rück-) Setzen von Transitionen, um die Weiterschaltung auf den nächsten oder den Verbleib im aktuellen Schritt zu erzwingen. Aktivierung von Schritten oder Transitionen, um die Bearbeitung der POE an einer bestimmten Stelle zu beginnen. Dauerhaftes Blockieren von Schritten und Transitionen, um die Aktivierung dieser Teile zu vermeiden. Setzen und Lesen von AS-relevanten Systemdaten wie Schritt-Merker, SchrittZeit, sowie Rückkopplungsvariable.

Es handelt sich hierbei um eine Art Forcing auf der Ebene der Ablaufsprache.

7.7 Datenbausteine und Rezepturen Eine Rezeptur im SPS-Sprachgebrauch stellt eine Sammlung von Datenwerten dar, die unter Beibehaltung des Programms je nach Steuerungsaufgabe der SPS gegen eine andere ausgetauscht werden kann. So lassen sich z.B. in einem Automatisierungsprozess unterschiedliche Produktionsvarianten steuern, die sich in Parametern wie Länge, Gewicht oder Temperatur unterscheiden. Mit Rezeptu-

7.7 Datenbausteine und Rezepturen

285

ren werden bestimmte Prozessdaten des Programms im laufenden Betrieb geändert. Diese Umparametrierung kann durch einen einfachen Austausch der Datensätze durch das Programm selbst erfolgen. In diesem Fall sind die möglichen Datensätze bereits im Speicher der SPS enthalten. Eine andere Möglichkeit besteht darin, den entsprechenden Datensatz während eines geeigneten Zeitpunkts im laufenden Betrieb neu in die SPS zu laden, d.h. einen dort vorhandenen Datensatz gegen den neuen auszutauschen. Einige SPS-Systeme lösen dies bisher durch sogenannte Datenbausteine (DB). Ein solcher Datenbaustein ist projektweit (global) bekannt. Er besteht aus einer Anzahl von Datenwörtern mit Datenformat (Datentypen). Über die Datenbaustein-Nummer erhält das Programm die Basisadresse des gerade aktiven Datenbausteins. Auf die Daten wird über einen Index (DatenwortNummer) zugegriffen. Bei einem DB-Wechsel wird lediglich die Basisadresse auf den neuen Baustein gestellt, d.h. der neue Datenbaustein aktiviert.

Programm:

Datenbaustein_1:

. . Wenn Eingangsschalter = 1 Lade DB-Adresse_1 Sonst Lade DB-Adresse_2 . . . . Lade Datenwort_1 (* des aktiven . Datenbausteins *) .

100 (* Länge des Werkstücks *) 0,445 (* Dehnungs-Konstante *) ... Datenbaustein_2: 200 (* Länge des Werkstücks *) 0,545 (* Dehnungs-Konstante *) ...

Abb. 7.6. Arbeiten mit Datenbausteinen. Genau ein Datenbaustein kann zu einem Zeitpunkt aktiv sein.

In Abb. 7.6 lädt „Lade Datenwort_1“, abhängig von der aktuell eingestellten Datenbaustein-Nummer, entweder 100 oder 200, ohne an dieser Stelle den aktiven Datenbaustein zu kennen. Frühere (nicht IEC 61131-3 konforme) Systeme nutzten diese DB auch zum (Zwischen-) Speichern eigener lokaler Daten.

286

7 Innovative SPS-Programmiersysteme

Zusammengefasst besitzen Datenbausteine üblicherweise folgende Eigenschaften: -

DBs sind selbständig wie Bausteine ladbar bzw. austauschbar, DBs stehen als globale Datenbereiche jedem Baustein zur Verfügung, Zu einem Zeitpunkt ist jeweils genau ein DB aktiv, DBs besitzen Informationen über die Datentypen ihrer Daten.

Spätestens hier stellt sich die Frage „wo finde ich die DBs in der IEC 61131-3 wieder?“, nachdem Datenbausteine in diesem Buch bisher kein Thema waren. Die IEC 61131-3 kennt in der Tat keine Datenbausteine. Anstelle der Aktivierung eines (globalen) Datenbausteins für Parametrierungsdaten und als Arbeitsbereich für FBs schlägt sie das in Kap. 2 erläuterte Instanziierungskonzept bei Funktionsbausteinen vor: jeder FB erhält automatisch seinen eigenen „lokalen“ Datensatz zugeordnet. Zusätzlich kann ein FB auf globale Daten zugreifen, so dass die Funktionalität der Datenbausteine für Parametrierung und Arbeitsbereich durch die IEC 61131-3 abgedeckt wird. Allerdings sind solche „Instanzdatenbereiche“ von FBs nicht wie POEs separat austauschbar und initialisierbar. Datensätze wie Rezepturen sind also entweder im Programm der SPS bereits enthalten oder werden durch Austausch der gesamten POE, die die neuen Daten enthält, gewechselt. Im Folgenden wird beschrieben, wie sich DB-Eigenschaften weitgehend mit Mitteln der IEC 61131-3 realisieren lassen. Zusammengehörende Daten werden über Strukturen und Felder deklariert; wie Datenbausteine bestehen diese aus einer Anzahl von Werten und Datenformaten. Diese Datenbereiche können flexibel als Ein- oder Ausgangsparameter, lokale oder globale Daten verwendet werden. Über solche Strukturen können auch Rezepturen komfortabel gebildet werden. Der Wechsel von Datensätzen kann auf unterschiedliche Arten erfolgen: 1) Die SPS wird angehalten und ein Programm mit anderen Daten komplett vom Programmiersystem auf die SPS geladen. Dies erfordert, dass der PC stets mit der SPS verbunden ist und der zu steuernde Prozess eine solche Unterbrechung zulässt. 2) Es werden einzelne Bausteine (POEs) ausgewechselt. Die vom PC nachgeladenen POEs ersetzen POEs mit gleichem Namen, besitzen aber unterschiedliche Anfangswerte für ihre Variablen oder rufen andere POEs auf. Dazu muss das SPS Betriebssystem Funktionen zur Bausteinverwaltung bereitstellen, die ein Nachladen im laufenden Betrieb ermöglichen. 3) Die (z.B. globalen) Datensätze werden dynamisch durch ein Programm zum „Bedienen & Beobachten“ gesetzt bzw. ausgetauscht (via Kommunikation). 4) Es befinden sich alle benötigten Datensätze bereits in der SPS. Das Programm ruft je nach Situation unterschiedliche POEs auf, die unterschiedliche Datensätze besitzen, oder versorgt seine FBs mit unterschiedlichen Parametersätzen.

7.7 Datenbausteine und Rezepturen

287

Ein Austausch erscheint für solche POEs sinnvoll, die vor allem: -

globale Daten zur Verfügung stellen, Daten kopieren bzw. initialisieren.

Eine übliche Methode zur Werteversorgung von Programmteilen wie FBs erfolgt über globale bzw. externe Variable:

Type-Definition: TYPE rez_struct: STRUCT par1:int; par2:int; ... END_STRUCT; END_TYPE

Haupt-Programm PROGRAM main VAR_GLOBAL rezept:rez_struct; END_VAR VAR rez1: rez_struct := ...; rez2: rez_struct := ...; Bearb1: Bearb; END_VAR

bearbeitende POE: ... FUNCTION_BLOCK Bearb VAR EXTERNAL rezept:rez_struct; END_VAR ... LD rezept.par1 ...

IF Bedingung THEN rezept := rez1; ELSE rezept := rez2; END_IF; ... Bearb1 (); ...

Bsp. 7.10. Im Hauptprogramm stehen verschiedene lokale Datensätze (rez1, rez2) zur Verfügung. Die global deklarierte Struktur rezept erhält bedingungsabhängig Werte zugewiesen, die von allen anderen POEs mit entsprechender EXTERNAL-Deklaration bearbeitet werden können.

Diese Werteversorgung über GLOBAL-Deklarationen besitzt den Nachteil, dass ständig alle Datensätze auf der SPS geladen sein müssen. Systeme, die die Konfiguration von globalen Variablen unterstützen, können dies umgehen. Eine Ressource kann Werte ihrer globalen Daten von anderen Ressourcen oder über Zugriffspfade (VAR_ACCESS) erhalten. Globale Daten sind bei Programm-Änderungen prinzipiell fehleranfällig, da aufgrund der möglichen Seiteneffekte sämtliche Stellen zu berücksichtigen sind, an denen sie verwendet werden. Sie verletzen in diesem Zusammenhang die von der IEC 61131-3 beabsichtigte Informationskapselung (Objektorientierte Daten). Um diesen Nachteil zu vermeiden, können die in Bsp. 7.10 verwendeten globalen Daten auch durch Aufrufparameter ersetzt werden:

288

7 Innovative SPS-Programmiersysteme

Haupt-Programm PROGRAM main VAR rez1: rez_struct := ...; rez2: rez_struct := ...; Bearb1: Bearb; END_VAR IF Bedingung THEN Bearb1 (rez1); ELSE Bearb1 (rez2); END_IF;

bearbeitende POE: ... FUNCTION_BLOCK Bearb VAR_IN_OUT rezept : rez_struct; END_VAR ... LD rezept.par1 ...

Bsp. 7.11. Um Seiteneffektfreiheit gegenüber der Methode in Bsp. 7.10 zu erhalten, werden die Rezepturdatensätze rez1 und rez2 als Ein/Ausgangsparameter (per Zeiger; damit muss nicht die gesamte Datenstruktur kopiert werden) weitergereicht.

7.8 FB-Verschaltung

7.8.1 Datenaustausch und Koordination von Bausteinen in verteilten Systemen Die IEC 61131-3 definiert PROGRAM-Bausteine, die hierarchisch FBs und Funktionen aufrufen (mit CAL) und mit Parametern versorgen. Jedes PROGRAM bzw. ein Teil der FB-Instanzen erhält eine Task zugeordnet. Zwischen den Tasks kann über Globale Variable oder ACCESS-Variable kommuniziert werden.

7.8 FB-Verschaltung

Datenverbindung zu anderen PROGRAM

289

PROGRAM ABC VAR_GLOBAL END_VAR Cal FB_inst Y

FB x

Prozeduraler Aufruf eines Bausteins mit Übergabe von Datenwerten über Ein/ Ausgangsvariable

Fun Y Var1

"Versenden" von Dateninformation

Var2

Var3

Y

Var4

Abb. 7.7. Ein Programm ruft weitere Bausteine auf (prozedural) und versorgt den aufgerufenen Baustein über Parameter mit Information. Mit anderen Programmen werden lediglich Daten ausgetauscht.

Dezentrale SPS-Systeme, vorwiegend in der Anlagentechnik, Energieversorgung oder Gebäudeautomatisierung eingesetzt, erfordern: -

eine parallele autonome Bearbeitung einzelner Verarbeitungsaufgaben, geografisch getrennte Verarbeitungsknoten, einen asynchronen Datenaustausch.

Zur Realisierung verteilter Anwendungen wird heute zumeist folgendes Vorgehen angewendet: Aus Programm-Bibliotheken werden vorgefertigte Bausteine in das zu entwickelnde Projekt kopiert, individuell erstellte Bausteine ergänzen fehlende Funktionalität. Ein PROGRAM bildet zusammen mit den aufzurufenden FBs und Funktionen eine ablauffähige Einheit. Allen PROGRAM-Bausteinen werden nun einzelne Netzknoten (Tasks von Steuerungen im Netzwerk) zugewiesen und die Ein- und Ausgänge miteinander verbunden. Nicht-verbundene Eingänge von Programm-Instanzen erhalten bei Bedarf individuelle Parameterwerte. Dies ist in Abb. 7.8 dargestellt. Bibliotheksbausteine erstellen meist Spezialisten der Hardwarehersteller bzw. stehen als fest installierter Code (EPROM, ...) in Steuerungen bzw. Netzwerkknoten zur Verfügung. Dies stellt einen Extremfall des IEC 61131-3-Modells dar. Das Anwenderprogramm wird über vorgefertigte Bausteine „konfiguriert“. Die Programme laufen weitgehend autonom ab, ohne von einem anderen Baustein „aufgerufen“ zu

290

7 Innovative SPS-Programmiersysteme

werden. Vom PROGRAM aufgerufene Funktionen und FBs im Sinne der IEC 61131-3 werden lokal vom Knoten zur Verfügung gestellt. Ein direkter Aufruf (CAL) eines Bausteins der benachbarten CPU ist nicht möglich (PROGRAM darf kein PROGRAM aufrufen).

Knotennr: Task-Nr: Priorität: Zykluszeit:

____ ____ ____ ____ FUNCTION fun FUNCTION_BLOCK 2 FUNCTION_BLOCK 1

PROGRAM ABC

PROGRAM DEF

I_ABC_1 O_ABC_1

O_ABC_2

Eingabewert: ____ Wertebereich: ____ Netz-Variable: ____

I_DEF_1

O_DEF_1

I_DEF_2

O_DEF_2

PROGRAM GHI I_GHI_1

O_GHI_1

Abb. 7.8. Zuweisung von Bausteinen an Netzwerkknoten und SPS-Tasks. Die PROGRAMBausteine laufen alle unabhängig und sind nur über ACCESS-Variable verbunden.

Weicht man von der Definition der IEC 61131 ab, dass nur Programme Verbindungen zu Task-fremden Bausteinen haben dürfen, kann man FBs beliebig auf Verarbeitungsknoten (Tasks) verteilen und miteinander verschalten. Damit kann ein Algorithmus wesentlich granularer und modularer auf die Netzwerk-Architektur verteilt werden. Die Leistung einer Automatisierungsanlage kann ohne Programmänderung durch Hinzunahme weiterer Verarbeitungsknoten und Umkonfiguration erweitert werden. Wie mit Abb. 7.8 verdeutlicht wird, ergeben sich daraus zwei Schwierigkeiten: 1) Das Ablaufverhalten der einzelnen Bausteine muss stärker aufeinander abgestimmt werden, denn eine Koordination allein über die Datenleitungen ist sehr unübersichtlich. 2) Es bedarf eines Mechanismus, der die Konsistenz des Datenflusses zwischen den Bausteinen (Netzknoten) sicherstellt, d.h. definiert, wann ein Datenwert oder eine Gruppe von Datenwerten gültig ist. Solange so verschaltete Bausteine auf „einem“ Netzwerkknoten ablaufen, kann das Ablaufverhalten durch implizite Festlegungen (Aktivierung der Bausteine gemäß

7.8 FB-Verschaltung

291

FB-Netzwerk von oben nach unten oder links nach rechts) oder explizite Vorgaben (Vergabe von Ausführungsnummern) konfiguriert werden. Besitzen die Tasks der Bausteine jedoch keine gemeinsame Zeitbasis, da sie auf unterschiedlicher Hardware ablaufen, sind weitere Kontrollmechanismen einzuführen. Durch eine solche Verschaltungstechnik erfolgt eine weitere Trennung von Programmierung und Konfigurierung: Der Programmierer beschreibt sein Programm mit FBs, Funktionen und deren Verbindungen. Danach erfolgt die Zuweisung der Funktionsblöcke auf die Verarbeitungsknoten. Dieselbe Anwendung kann lokal auf einer Task, aber auch verteilt auf vielen Tasks ablaufen, ohne dass die Programmstruktur geändert werden muss. Diese Vorgehensweise wurde im Wesentlichen in der IEC 61499 aufgegriffen; Kapitel 9 beschreibt dazu das grundsätzliche Vorgehen. Eine weitere Möglichkeit des Informationsaustausches zwischen Bausteinen unterschiedlicher Konfigurationen sind die Kommunikationsbausteine, welche in der IEC 61131-5 [DIN EN 61131-5] beschreiben sind. Sie werden vom Hersteller zur Verfügung gestellt und dienen auch dazu, mit Nicht IEC 61131-3 Systemen zu kommunizieren.

7.8.2 Makrotechnik bei FB-Verschaltung Ein Projekt mit einer in Abschn. 7.8.1 genannten Verschaltungstechnik besteht aus einer Vielzahl von Bausteinen. Zur Strukturverbesserung können lokal platzierte Bausteine zeichnerisch zusammengefasst werden; diese werden im Weiteren als einzelner Baustein dargestellt. Zusammengehörende Funktionsteile können einzelnen Arbeitsblättern, sogenannten Funktionsplänen, zugeordnet werden. Auf diese Makrotechnik wird im Folgenden eingegangen. Bsp. 7.12 zeigt ein Beispiel aus der Anlagentechnik.

Temp_Test:

S1

S2

S3

Hole_Aktuellen_Wert Konsistenzprüfung Hole_Aktuellen_Wert

Hole_Aktuellen_Wert

Schreibe_Wert

Regel_Wert

Schreibe_Wert

Prot

Temperatur_ Ausgleich

Kalibrierung

Bsp. 7.12. Verschaltung einfacher Grundelemente in der Anlagentechnik

292

7 Innovative SPS-Programmiersysteme

Die Platzierung und Verbindung von Bausteinen (Hole_Aktuellen_Wert mit Konsistenzprüfung) erfolgt grafisch durch den Anwender. Die Bausteine haben eine genau beschriebene Funktionalität. Datendeklarationen müssen nicht eingegeben werden, da sie implizit durch die Instanziierung des Bausteins vorgenommen werden. Lediglich bei den Ein-/Ausgangsparametern muss beachtet werden, dass die beiden Datentypen zusammenpassen (Typverträglichkeit). Die vom Hersteller zur Verfügung gestellten Elementar-Bausteine können nun durch eine Art „Makrotechnik“ zu größeren Funktionsblöcken zusammengefasst werden. Diese Methode entspricht dem Aufbau von Datenstrukturen aus Elementaren Datentypen, man spricht deshalb auch von Abgeleiteten Funktionsbausteinen.

Temp_Regelung:

Temp_Test S1

Schiebe_Regler

RegelWert

Sauerstoff

S2 S3

Brennstoff Prot

Kalibrierung Protokoll_Drucker

Bsp. 7.13. Die Bausteine aus Bsp. 7.12 erreichen durch eine Makrotechnik, d.h. Zusammenfassung von Bausteinen, eine immer höhere Funktionalität und Spezialisierung.

Nach der Festlegung des Bsp. 7.13 steht der Baustein Temp_Regelung als eigener Baustein für weitere Aufgaben zur Verfügung. Handelt es sich bei den elementaren FBs beispielsweise um Hersteller-Bausteine mit einem genau beschriebenen Zeitverhalten, lassen sich auch gute Simulationsergebnisse (Laufzeit, Änderungsverhalten bei anderer Hardware-Zuteilung oder Änderung der Kommunikationswege,...) erzielen.

7.9 Diagnose, Fehlererkennung und -Reaktion Diagnose heißt im Wesentlichen: „Erkennen von Fehlerzuständen im laufenden Betrieb und deren Lokalisierung“. Es gibt vier Bereiche, in denen Fehler auftreten können:

7.9 Diagnose, Fehlererkennung und -Reaktion

1) 2) 3) 4)

293

Hardware der SPS inkl. Verbindungen zu anderen Geräten, Software der SPS (Betriebssystem), Software des Anwenders, Prozessverhalten. Der zu steuernde Prozess gerät in unerwünschte Zustände.

Dabei kann generell zwischen Systemfehlern und Programmierfehlern unterschieden werden. Die Hersteller bieten verschiedene Hilfsmittel zur Diagnose-Unterstützung an. Dies kann zusätzliche Hardware sein, die Fehlersituationen abprüft und relevante Daten liefert, oder Softwarefunktionen, die eingebunden werden. Auch AS eignet sich sehr gut, um Fehler in der laufenden Anlage zu finden (wie: „Transition XY schaltet nicht“) oder nach Ausnahmesituationen vordefinierte Reaktionen anzusteuern. Allgemeines Fehlerkonzept der IEC 61131-3. Die IEC 61131-3 beschränkt sich auf einen allgemeinen Ansatz, der dem Anwender gewisse Hilfen für 2) und 3) in die Hand gibt. Sie beschreibt in einer Fehlerliste, siehe Anh. E, mögliche Fehlerquellen, die jeweils in einem SPS-System durch eine der folgenden Möglichkeiten berücksichtigt sein müssen: 1) Der Fehler wird nicht beachtet; dies muss in einer separaten AnwenderDokumentation festgehalten sein. 2) Das System macht auf mögliche Fehlersituationen beim Erstellen oder Laden aufmerksam (Warnung). 3) Das System meldet während der Programm-Ausführung (Laufzeit) in geeigneter Weise Fehler und bietet herstellerspezifische Möglichkeiten zum Eingriff. Qualitätssicherung spielt in der Automatisierungswelt eine sehr gewichtige Rolle. Die Güte heutiger Compiler verhindert manche typischen Fehler bereits während der Programmerstellung. Die Sprachdefinition der IEC 61131-3 bietet Konzepte wie die strenge Typüberprüfung von Daten, die manche Fehler erst gar nicht entstehen lassen. Im Wesentlichen handelt es sich dabei um „Fehlerprophylaxe“ während der Programmierung. Viele Fehler lassen sich jedoch erst während der Laufzeit feststellen. Es gibt eine Reihe von Fehlersituationen wie Division durch Null (siehe Anhang E), die vom SPS-System abgeprüft werden sollten. Die IEC 61131-4 mit ihrer Hilfestellung für Programmierer [DIN EN 61131-4] schlägt vor, eine einheitliche globale (herstellerspezifische) Datenstruktur als Fehler-Datentyp zu definieren, die den Status (Fehler ja/nein) einer Operation, den Fehlertyp (Division durch Null, ...) und die Fehlerstelle (POE-Namen, ...) beinhaltet. Eine solche Statuskennung kann dann vom Anwender-Programm abgefragt werden oder, falls realisiert, mit dem SINGLE-Eingang einer TASK verbunden werden, siehe auch Abschn. 6.3.4. Diese Task wird mit einer System- oder Anwenderroutine verbunden, welche sich um eine fehlerspezifische Abarbeitung kümmert. Diese kann eine „Online-“ Korrektur, ein Hinweis an den Benutzer, einen Warmstart o.ä. initiieren.

294

7 Innovative SPS-Programmiersysteme

Im Fehlerfall setzt ein solches SPS-System den Wert des Fehlerstatus auf TRUE und belegt den Fehlertyp. Der erst genannte Wert startet mit steigender Flanke die Fehlertask. Erweitertes Fehlermodell (nicht IEC). Zur Verbesserung der Programm-Qualität wäre es wünschenswert, wenn der Anwender selbst Fehler-Situationen in standardisierter Form definieren könnte. Vorstellbar hierfür wären Sprachhilfsmittel wie „zugesicherte Eigenschaften“. Dies sind vom Programmierer eingestreute System-Testroutinen, die spezielle Überprüfungen z.B. von Variablen durchführen: -

befindet sich eine Variable noch innerhalb des an dieser Programmstelle gültigen Wertebereichs? besteht Übereinstimmung zwischen zwei Variablen?

FBS: Var1

(ASSERTION > 0) AND

MUL

(ASSERTION < 1000)

Var2

ADD Var3

Spule

AWL: LD Var1 MUL Var2 ASSERTION((AE > 0) AND (AE < 1000)) ADD Var3 ST Spule

Bsp. 7.14. Zur Erkennung von Laufzeitfehlern sollten Abfragen möglich sein, die vom System selbst berechnet werden. In der grafischen Darstellung könnten Verbindungen über Zusicherungs-Symbole abgesichert werden. Die Ausdrücke sollten in einer genormten Sprache (z.B. ST) geschrieben sein.

Diese Zusicherungen könnten einfache Ausdrücke für das Aktuelle Ergebnis (AE) in AWL wie in Bsp. 7.14 sein. Mit Hilfe von Zusicherungen (engl.: assertion) werden zur Laufzeit „wichtige“ Werte überprüft, die das SPS-Programm zum korrekten Ablauf benötigt. Es sind auch komplexe Ausdrücke denkbar, die an vorgegebenen Programmstellen Ein- und Ausgangswerte vergleichen, Datenkonsistenzberechnungen durchführen oder wichtige Prozessparameter in ihrem Zusammenhang überprüfen.

7.10 Hardware-Abhängigkeiten

295

Erste Ansätze zur automatischen Fehlerüberwachung sind in einigen Programmiersystemen zu finden, die z.B. eine Feldüberwachung durchführen, d.h. der Index zu einem Feld darf die deklarierte Feldanzahl nicht überschreiten oder negativ werden. Diese Vorgaben werden auch durch die IEC 61131-3 sprachlich unterstützt; siehe dazu Kap. 3. Es muss parametrierbar sein, was bei einer Verletzung der Zusicherung zu geschehen hat: Programm-Stopp, Ausgabe einer Fehlermeldung an die Visualisierungs-Soft- und Hardware. Für ein sogenanntes „Exception Handling“ sollten mehrere Fehler-Routinen (Anwender- oder Standard-Fehler-POEs), ähnlich dem oben beschriebenen Mechanismus, definierbar sein, die jeweils – abhängig vom Reaktionswunsch – einer oder mehreren Zusicherungen zugewiesen werden. Diesen Routinen sollten Sonderrechte wie die Möglichkeit eines Programmstopps, Neustarts o.ä. eingeräumt werden. Derzeit müssen solche Zusicherungsbedingungen und die entsprechende FehlerReaktion (ohne Sonderrechte) vom Anwender selbst programmiert werden, was nicht unbedingt zur Übersichtlichkeit des Programms beiträgt. Die Architektur der Fehlerbehandlung zieht sich quer durch die Programme und derzeitige Lösungen sind herstellerabhängig. Das Fehlen von standardisierten Fehlerüberwachungs- und -Reaktionsmöglichkeiten erschwert die Portierung von Programmen auf Fremdsysteme und erfordert wieder Systemspezialisten mit besonderer Ausbildung.

7.10 Hardware-Abhängigkeiten Untersuchungen bei der Portierung von Nicht-IEC-Programmen auf IEC Programmiersysteme haben gezeigt, dass selbst bei sehr guten Cross-Compilern selten mehr als 60 % automatisch übersetzt werden können. Ursache dafür sind starke Hardware-Abhängigkeiten, die an vielen Stellen der Programme benutzt werden. Es werden Bausteine zur Ansteuerung weiterer Steuerbaugruppen, herstellerspezifische Kommunikationsbausteine eingesetzt oder HardwareAdressen (Statusregister, spezielle Speicherbereiche, ...) zugelassen. Diese Herstellerbesonderheiten kann und will die IEC 61131-3 nicht eliminieren. Schließlich soll durch eine Vielzahl unterstützender Soft- und Hardware eine möglichst hohe Funktionalität erreicht werden. Um die Portierbarkeit zu erleichtern, schlägt die IEC 61131-3 folgende Mechanismen vor:

296

-

-

7 Innovative SPS-Programmiersysteme

Alle Informationen, die ein Programm von außerhalb benötigt, erhält es über die IEC 61131-3 konformen globalen Variablen oder Zugriffspfade, sowie über spezielle Kommunikations-FBs, die in der IEC 61131-5 beschrieben sind. Verwendung von E/A-Peripherie ist im PROGRAM oder der Konfiguration zu deklarieren. Hardwareabhängigkeiten sind in einer speziellen Tabelle zu hinterlegen, die jeder Hersteller mit seiner Software mitzuliefern hat.

Die Liste der implementierungsabhängigen Parameter ist in Anh. F zu finden.

8 Stärken der IEC 61131-3

Kapitel 1 beschreibt Ziele und Nutzen der Norm IEC 61131-3 für Hersteller und Anwender. Nun geht es um die Frage: Inwieweit erfüllt dieser Programmierstandard die an ihn gestellten Erwartungen? In den vorangegangenen Kapiteln wurden viele Eigenschaften und Konzepte dieser SPS-Programmierung beschrieben und erläutert. Darin spiegelten sich die zentralen Konzepte wider, die hier abschließend zusammengefasst werden. Folgende Eigenschaften der SPS-Programmierung mit IEC 61131-3 sind besonders bemerkenswert: -

Komfort und Sicherheit durch Variablen und Datentypen, Bausteine mit erweiterten Möglichkeiten, SPS-Konfiguration mit Laufzeitverhalten, Einheitliche (Programmier-) Sprachen, Strukturierte SPS-Programme, Trend zu offeneren SPS-Programmiersystemen.

8.1 Komfort und Sicherheit durch Variablen und Datentypen Lokale und Globale Variable statt Hardware-Adressen Bisher war es üblich, auf sämtliche Datenbereiche der SPS über globale Adressen zuzugreifen, wobei der Programmierer selbst dafür sorgen musste, dass Teilprogramme nicht versehentlich Daten eines anderen Programmteils überschreiben. Dies gilt insbesondere beim Zugriff auf Peripherie, Merkerbereiche oder Datenbausteine. Durch die IEC 61131-3 werden die globalen Hardware-Adressen durch Variable ersetzt und für sie Gültigkeitsbereiche eingeführt: Das Programmiersystem trennt automatisch die Verwendung POE-lokaler und globaler Variablen. Auf globale

298

8 Stärken der IEC 61131-3

Hardware-Adressen kann dennoch zugegriffen werden, indem im Deklarationsteil eine Zuweisung der Adresse an einen später verwendeten Variablennamen erfolgt. Typgerechter Zugriff auf SPS-Daten Der SPS-Programmierer musste in der Vergangenheit darauf achten, dass eine SPS-Adresse jeweils mit demselben Datentyp gelesen und beschrieben wird. So ist es möglich, ein Merker- oder Datenwort an verschiedenen Programmstellen einmal als Ganzzahl (Integer) oder als Gleitpunktzahl (Real) zu interpretieren. Dadurch entstehende Programmierfehler können mit der IEC 61131-3 ausgeschlossen werden, da jeder Variablen (auch direkte Hardware-Adressen) ein Datentyp zugeordnet werden muss. Dadurch kann das Programmiersystem eine Überprüfung automatisch vornehmen. Jederzeit definierte Anfangswerte für Anwenderdaten Sämtliche Daten werden zusammen mit ihrem Datentyp als Variable explizit bekanntgegeben. Jeder Datentyp besitzt (standardmäßig oder benutzerdefiniert) einen Anfangswert, so dass jede Programm-Variable ihren Eigenschaften entsprechend korrekt initialisiert wird. Variable können zusätzlich mit dem Attribut „batteriegepuffert“ versehen werden, die Zuordnung zu physikalisch gepufferten Speicherbereichen erfolgt dann automatisch. Felder und Datenstrukturen für jeden Zweck Basierend auf vordefinierten Datentypen kann der SPS-Programmierer Felder und komplexe Datenstrukturen für anwendungsgerechte Daten entwerfen, wie sie bereits von höheren Programmiersprachen her bekannt sind. Feldgrenzen und Wertebereiche werden durch das Programmiersystem sowie zur Laufzeit überwacht. Einheitliche Variablendeklaration Die umfangreichen Möglichkeiten der Verwendung von Variablen sind weitgehend für alle IEC-61131- Sprachen identisch.

8.2 Bausteine mit erweiterten Möglichkeiten Wiederverwendbarkeit von Bausteinen Bausteine (POEs) wie Funktionen und Funktionsbausteine können unabhängig vom herstellerspezifischen System formuliert werden. Daraus ergibt sich die Möglichkeit, Baustein-Bibliotheken herstellerübergreifend in verschiedenen SPSProjekten einzusetzen. Aufruf-Parameter, Rückgabewerte sowie lokale Daten jedes FBs, d.h. jeder FBInstanz bleiben zwischen den Aufrufen erhalten. Jede Instanz besitzt nach der

8.3 SPS-Konfiguration mit Laufzeitverhalten

299

Norm automatisch ihren eigenen Datenbereich („gekapselt“), auf dem sie unabhängig von externen Daten ihre Berechnungen ausführen kann. Der vorherige Aufruf eines Datenbausteins, auf dem der FB arbeitet, kann dadurch entfallen. Auch (Haupt-) Programme können als Instanzen für mehrere Tasks einer CPU gleichzeitig verwendet werden. Leistungsfähige Baustein-Parametrierung Zur Übergabe von Daten an Bausteine werden mehrere Mechanismen zur Verfügung gestellt, mit denen POE-Parameter übergeben bzw. zurückgegeben werden können: -

VAR_INPUT: VAR_IN_OUT: VAR_OUTPUT: VAR_EXTERNAL: VAR_ACCESS:

Wert einer Variable Zeiger auf eine Variable Rückgabewert Globale Variable einer anderen POE Zugriffspfad innerhalb der Konfiguration

Aus diesem Spektrum wurden bei bisherigen SPS-Systemen zumeist nur globale Daten sowie die Möglichkeit der Übergabe von Werten an den aufgerufenen Baustein realisiert (und nicht umgekehrt). Standardisierte SPS-Funktionalität Um typische SPS-Funktionalität zu standardisieren, führt die Norm StandardFunktionen und -Funktionsbausteine ein, die bzgl. Aufrufschnittstelle, grafischer Darstellung und ihrem Laufzeitverhalten fest vorgegeben sind. Diese standardisierte Baustein- „Bibliothek“ für jedes SPS-System bildet eine wichtige Grundlage für die einheitliche und herstellerübergreifende Ausbildung, Programmierung und Dokumentation.

8.3 SPS-Konfiguration mit Laufzeitverhalten Konfigurationen strukturieren ein SPS-Projekt Die Zuordnung der Bausteine zur Steuerung erfolgt auf der obersten Ebene eines SPS-Projekts (Konfiguration). Dabei werden Laufzeiteigenschaften, Schnittstellen nach außen, SPS-Adressen und -Peripherie der Teilprogramme festgelegt. Laufzeiteigenschaften für SPS-Programme Während bei bisherigen SPS-Systemen Laufzeiteigenschaften wie Zyklusdauer oder Priorität von SPS-Programmen oft systemspezifisch vorgegeben wurden, können solche Parameter nun individuell durch die Definition von Tasks vorgegeben und dokumentiert werden.

300

8 Stärken der IEC 61131-3

SPS-Programme dürfen nicht rekursiv sein. Daher kann der zur Laufzeit benötigte Speicherplatz off-line ermittelt werden und die Programme werden sicherer gegen versehentliche Rekursion.

8.4 Einheitliche Sprachen Die IEC 61131-3 definiert fünf Programmiersprachen, mit denen ein breites Spektrum von Anwendungen abgedeckt werden kann. Aufgrund der internationalen Normierung erhalten SPS-Fachleute eine einheitlichere Ausbildung. Sie sprechen firmen- und branchenübergreifend „dieselbe Sprache“. Ausbildungs- und Weiterbildungskosten sind seit Einführung des Standards deutlich gesunken, da sich der herstellerspezifische Anteil auf die Besonderheiten eines SPS-Systems beschränken kann. Die Anlagendokumentation wird beim gemischten Einsatz unterschiedlicher SPS-Systeme einheitlicher.

8.5 Strukturierte SPS-Programme Durch Verwendung der vielfältigen Sprachelemente der IEC 61131-3 lassen sich Anwenderprogramme gut strukturieren; der Bogen reicht von der Baustein- und Datendefinition bis zur Konfiguration. Dies unterstützt sowohl den strukturierten Programmentwurf (top down, bottom up) als auch die Pflege und Wartung der Programme wesentlich. Mit dem „Strukturierungsmittel“ Ablaufsprache steht dem Anwender darüber hinaus eine geeignete Sprache zur übersichtlichen und anwendungsbezogenen Formulierung der Steuerungsaufgabe zur Verfügung.

8.6 Trend zu offeneren SPS-Programmiersystemen

301

8.6 Trend zu offeneren SPS-Programmiersystemen Eine Standardisierung von Programmiersprachen führt zu Standardsoftware, die herstellerunabhängigere, portable Programme ermöglicht, wie es beispielsweise bei den gängigen Programmiersprachen (Assembler, C, COBOL) im Personal Computer-Bereich inzwischen der Fall ist. Der Bewertungsmaßstab ist durch die „feature tables“ der IEC 61131-3 vorgegeben. Dadurch werden SPS-Programmiersysteme unterschiedlicher Hersteller mit einer gemeinsamen Grundfunktionalität vergleichbarer. Differenzierungsmerkmale der Hersteller erstrecken sich jetzt mehr auf Zusatzfunktionen wie Logik-Analysator und Off-Line-Simulator als auf die Merkmale der Programmiersprachen selbst. Das gemeinsame Look&Feel der SPS-Programmierung wird auch international einheitlicher. Selbst bisher sich abgrenzende SPS-Märkte in Europa, USA oder Asien rücken näher zusammen.

SPS-Programmiersystem nach IEC 1131-3

Compiler Editoren Import Export

Standardisierte Grundkomponenten Bedienen& Beobachten Visualisierung Simulation

Integriertes SPS-Programmiersystem

Abb. 8.1. Trend zu offenen, standardisierten Komponenten auf der Basis von IECkonformen Programmiersystemen

302

8 Stärken der IEC 61131-3

SPS-Programmiersysteme heutiger Generation beinhalten standardisierte Grundkomponenten neben hoch differenzierten Zusatzpaketen, um ein breites Anwendungsspektrum abdecken zu können. Wie es Abb. 8.1 ausdrückt, fördert die Standardisierung der IEC 61131-3 integrierte Systeme auf Basis von austauschbaren Standard-Komponenten wie Editoren, Compiler oder Export- und Importfiltern mit offenen, d.h. mehrfach nutzbaren Schnittstellen. Bisher oft außerhalb der SPS-Programmiersysteme realisierte klassische Zusatzpakete wie Bedienen&Beobachten, Simulation oder Visualisierung bewirken die Entstehung von De-facto-Standard-Schnittstellen dieser Komponenten.

8.7 Fazit Die Einführung der IEC 61131-3 bedeutete sowohl für SPS-Hersteller als auch für Anwender Umsteigen von „eingefahrenen Geleisen“ zugunsten einer fortschrittlicheren Programmier-Technologie. Der Schritt zur umfassenden Programmiernorm IEC 61131 war sicher notwendig, um ein einheitliches Vorgehen bei der Innovation von Konfiguration und Programmierung von SPS-Systemen zu erreichen. Mit der herstellerübergreifenden Einheitlichkeit sinkt der Einarbeitungs- und Schulungsaufwand für die SPS-Programmierer, es werden zuverlässigere Programme geschrieben und die Funktionalität der SPS-Programmiersysteme wird sich den leistungsfähigen Software-Produktionsumgebungen der PCs weiter angleichen. Konformitätsgrad zur IEC 61131-3, Migrationspfade von bestehenden Systemen hin zu neuen Architekturen sowie eine ergonomische, leistungsfähige Bedienoberfläche bilden für die Anwender die wichtigsten Kriterien zur Akzeptanz neuer SPS-Programmiersysteme. Insgesamt führen die heutigen komplexen Anforderungen und wirtschaftlichen Randbedingungen des Marktes zu flexiblen, offenen und damit herstellerübergreifenden SPS-Programmiersystemen.

9 Programmierung durch Konfigurierung nach IEC 61499

Die Programmierung mit Hilfe von grafischen Elementen, die der Vorstellungswelt der zu programmierenden Anwendung entnommen sind, ist heute nicht mehr weg zu denken. Mit den bisher vorgestellten grafischen Programmiersprachen KOP, FBS oder AS lassen sich Datenfluss und logische Verarbeitungsfolge symbolisch programmieren bzw. dokumentieren. Es liegt nahe, daneben auch die topologische Verteilung von Programmen, ihre übergreifende Konfiguration und Vernetzung mit anderen Teilen eines verteilten Automatisierungs-Projekts grafisch darzustellen. Dies erfolgt auf einer höheren, abstrakteren Ebene als die bisher kennengelernte Programmierung von POEs. Dementsprechend heißen solche Werkzeuge zur Konfiguration komplexer verteilter Anwendungen „Konfigurations-Editoren“. Programmteile wie Funktionsbausteine werden zu größeren Einheiten zusammengefasst. Die Methode wird „Verschaltung von Funktionsbausteinen“ genannt. Um die sprachlichen Mittel für diese Zwecke einheitlich zu definieren, wurde die internationale Norm IEC 61499 definiert, die als eigenständige Norm oder auch als Ergänzung zur IEC 61131 gesehen werden kann. Dieses Kapitel gibt einen Überblick über die Grundlagen und Ideen dieser weiteren Norm und stellt den Zusammenhang zur IEC 61131 her. Eine detailliertere Darstellung der Norm IEC 61499 ist eher Gegenstand eines weiteren Buchs, siehe auch [IEC 61499-1], [IEC 61499-2] und [IEC 61499-4].

304

9 Programmierung durch Konfigurierung nach IEC 61499

9.1 Programmierung durch FB-Verschaltung mit IEC 61131-3 Um die Unterschiede zwischen IEC 61499 und IEC 61131-3 zu verdeutlichen, wird im Folgenden zunächst auf Besonderheiten der verteilten Programmierung eingegangen. Die in Kap. 4 beschriebenen Programmiersprachen werden verwendet, um Algorithmen für Bausteine zu definieren. Funktionsbausteine und Funktionen rufen sich gegenseitig auf, teilen sich Information über ihre Parameter mit und bilden zusammen mit der POE PROGRAM ein Programm. Ein Programm läuft als Task auf einer Ressource, d.h. Prozessoreinheit (CPU) einer SPS, ab. Die IEC 61131-3 konzentriert sich weitgehend auf die Beschreibung einzelner Programme mit ihren Ausführungs-Bedingungen. Der Informationsaustausch der Programme untereinander erfolgt über ACCESS-Variable oder globale Datenbereiche. Diese Thematik wurde bereits in Abschn. 7.8 angesprochen und mit Abb. 7.8 verdeutlicht. Komplexe dezentrale Automatisierungs-Aufgaben besitzen eine umfangreiche Kommunikations- und Ausführungsstruktur. Räumlich getrennte Steuerungen tauschen intensiv Daten aus. Die inhaltlichen und zeitlichen Abhängigkeiten sind zu spezifizieren. Dazu werden Programme den Tasks der Netzwerkknoten zugeordnet, Ausführungsbedingungen wie in Abschn. 6.1 beschrieben festgelegt sowie die Ein- und Ausgänge der Programme (wie Netzwerkadressen oder Parameterwerte) verschaltet. Die Verteilung einer Automatisierungs-Lösung, d.h. Funktionsbausteine auf physikalisch und örtlich unterschiedliche Hardware zu konfigurieren sowie deren Synchronisation, ist Gegenstand der Norm IEC 61499. Die Verteilung auf mehrere Automatisierungsgeräte bildet sicherlich den Schwerpunkt des Konzepts, doch macht es auch Sinn, eine IEC 61499 Anwendung auf einer einzigen Steuerung zu betreiben.

9.2 IEC 61499 - die Norm für verteilte Systeme Der sequentielle Bausteinaufruf der IEC 61131-3 ist keine geeignete Methode zur Programmstrukturierung in verteilten Systemen. Dies wird bereits in Abb. 7.8 deutlich. Ziel eines verteilten, dezentral organisierten Systems ist es, Programme auf mehrere Steuerungen zu verteilen und dadurch parallel auszuführen (im Unterschied zur sequentiellen Abarbeitung beim Bausteinaufruf über CAL). Dabei ist besonders wichtig, Datenkonsistenz zwischen Knoten des vernetzten Systems

9.2 IEC 61499 - die Norm für verteilte Systeme

305

sicherzustellen, also Zeitpunkte des gegenseitigen Datenaustauschs eindeutig zu definieren. In der IEC 61499 spielen zwei Arten des Informationsaustausches eine wesentliche Rolle: 1) der Datenfluss mit Anwenderdaten, 2) der Kontrollfluss, der die Gültigkeit der Anwenderdaten als Ereignisinformation steuert. Das Zusammenspiel von Daten- und Kontrollfluss kann auch mit Mitteln der IEC 61131-3 unter Verwendung von globalen Variablen und Zugriffspfaden programmiert werden. Das Gesamtprogramm wird dabei jedoch leicht unübersichtlich und langsamer. Um in einem verteilten, also vernetzten Automatisierungssystem die Beziehung zwischen Programmteilen und Elementen der Steuerungs-Hardware einfach und exakt beschreiben zu können, verwendet die IEC 61499 ein Modell („top down“Ansatz) mit mehreren hierarchischen Ebenen: -

System Gerät Ressource

-

Anwendung Funktionsbaustein

Die Begriffe Ressource und Funktionsbaustein werden allerdings gegenüber der IEC 61131-3 in einem erweiterten Sinn definiert, wie im Folgenden näher erläutert wird. Anstelle der Zuordnung von PROGRAM und TASK zu einer Ressource können den Funktionsbausteinen der IEC 61499 über die Ressource Laufzeiteigenschaften direkt zugeordnet werden.

9.2.1 System-Modell In einer realen Automatisierungsumgebung bearbeiten mehrere Steuerungen, im weiteren „Geräte“ genannt, dieselbe oder verschiedene Anwendungen parallel, dies wird in Abb. 9.1 skizziert.

306

9 Programmierung durch Konfigurierung nach IEC 61499 Kommunikationsnetzwerk

Gerät 1

Gerät 2

Gerät 3

Gerät 4

Anwendung A Anwendung B Anw.C zu steuernderAutomatisierungsprozeß

Abb. 9.1. Die Steuerung eines Prozesses kann auf mehrere Geräte verteilt erfolgen. Weiterhin können wie bei der IEC 61131-3 mehrere Programme für ein Gerät konfiguriert werden. Die Programmteile tauschen dazu Informationen über Netzwerke aus.

9.2.2 Geräte-Modell Betrachtet man ein Gerät wie in Abb. 9.2 im Detail, besteht es aus: -

seinen Anwenderprogrammen, einer Schnittstelle zum Kommunikationsnetz, einer Schnittstelle zum Automatisierungsprozess und aus der Geräte-Hardware, auf der Ressourcen ablaufen.

Eine Ressource stellt eine eigenständig ablauffähige und parametrierbare Einheit (Task im allgemeinen Sinne) dar. Es können mehrere Ressourcen auf einem Gerät laufen, die dieselbe oder unterschiedliche Anwendungen realisieren. Die IEC 61499 verwendet zwei Sichten auf ein verteiltes Programm, die im Weiteren nacheinander aufzuzeigen sind. Zum einen betrachtet diese Norm die Hierarchie System—Gerät—Ressource, um den Systemaufbau und die dazugehörigen Ablaufeigenschaften zu beschreiben. Zum anderen wird orthogonal dazu auch die anwendungsbezogene Sicht eines verteilten Programms definiert. Diese Anwendersicht wird durch weiter unten zu beschreibende Anwendungs- und Funktionsbaustein-Modelle zusammengefasst.

9.2 IEC 61499 - die Norm für verteilte Systeme

307

Kommunikationsnetzwerk Kommunikations-Schnittstelle Ressource x

Ressource y

Ressource z

Anwendung A

Anw. C Prozeß-Schnittstelle zu steuernder Automatisierungsprozeß

Abb. 9.2. Ein Gerät kann mehrere Ressourcen enthalten, die über gemeinsame Schnittstellen Information mit anderen Automatisierungs-Einheiten sowie dem Automatisierungsprozess austauschen.

9.2.3 Ressource-Modell Die Bausteine einer Ressource bestehen aus Funktionsblöcken, die über besondere Schnittstellen sowohl Ereignis- als auch Daten-Information austauschen. Man unterscheidet zwei Arten von Funktionsbausteinen: 1) „Service-Schnittstellen-“ Funktionsbausteine, die als Standard-FBs die Schnittstellen zum Automatisierungsprozess und dem Kommunikationsnetzwerk bilden. 2) benutzerdefinierte Funktionsbausteine, die das eigentliche Anwenderprogramm darstellen. Wie in der IEC 61131-3 erfolgt eine Unterscheidung zwischen FB-Typ und FBInstanz. Jedem Funktionsbaustein werden in der Ressource Laufzeiteigenschaften zugeordnet: maximale Anzahl von Instanzen, seine Ausführungszeit, die Anzahl der Verbindungen etc. Die „Verschaltung“ der FBs durch den Anwender erfolgt nicht auf der Ebene der Ressource, sondern der Anwendung; siehe nächster Abschnitt. Der tatsächliche Informationsaustausch zwischen den einzelnen FBs eines Anwenderprogramms erfolgt für den Anwender „unsichtbar“ über die Kommunikations- und ProzessSchnittstelle. Eine oder mehrere Ressourcen können eine Anwendung realisieren.

308

9 Programmierung durch Konfigurierung nach IEC 61499

9.2.4 Anwendungs-Modell Dieser Abschnitt geht auf die anwendungsbezogene Sicht eines Programms ein. Diese Sicht entspricht dem horizontalen, grauen Balken „Anwendung“ in Abb. 9.3, der sich über mehrere Geräte oder Ressourcen erstrecken kann.

Kommunikations-Schnittstelle ServiceSchnittstellenFB Ereignisse

Daten

Anwendung FB

FB

FB

...

FB

...

FB

FB

FB

FB FB

FBs (Algorithmus) Ereignisse

Daten

ServiceSchnittstellenFB

Prozeß-Schnittstelle

Abb. 9.3. Eine Ressource besteht aus Funktionsbausteinen zur Steuerung und Datenverarbeitung (Algorithmen) mit Schnittstellenbausteinen (Kommunikation / Prozess).

Die Anwendungsebene bildet die eigentliche Programmierebene, indem FBs unabhängig von den Ressourcen miteinander verbunden und verschaltet werden. Sie beschreibt die - später gegebenenfalls auf mehrere Ressourcen - verteilte Anwendung. Nach der Zuweisung eines Anwenderprogramms, bestehend aus mehreren FBs, an die Ressourcen und dem Programmstart, erfolgt die Kommunikation implizit oder explizit (abhängig vom Hersteller) über die Service-Schnittstellen gemäß der vom Anwender spezifizierten Verschaltung. Abb. 9.4 zeigt, wie eine Anwendung sowohl steuernde Programmteile (mit Ereignissen) als auch Daten verarbeitende Teile (Algorithmen) zusammenfasst. In dieser Abbildung ist die gegenüber IEC 61131-3 andere graphische Darstellung der Funktionsbausteine zu sehen.

9.2 IEC 61499 - die Norm für verteilte Systeme

Steuerung

Steuerung

Steuerung

Algorithmus

Algorithmus

Algorithmus

Kontrollfluß: Datenfluß:

309

Ereignisse Daten

Abb. 9.4. Die Anwendung besteht aus verschalteten Funktionsbausteinen, von denen jeder sowohl steuernde (Kontrollfluss) als auch Daten verarbeitende (Datenfluss) Funktionen besitzt.

Steuer- und Dateninformation fließt jeweils von links in einen Funktionsbaustein hinein und wird, entsprechend verarbeitet, von seinen rechten Anschlüssen weitergegeben.

9.2.5 Funktionsbaustein-Modell Die Funktionsbausteine bilden die Ebene der kleinsten Programmeinheit (wie POEs). Im Unterschied zu den gleichnamigen FBs der IEC 61131-3 besteht hier ein Funktionsbaustein prinzipiell aus zwei Teilen: 1) Ausführungskontrolle: Erzeugen und Verarbeiten von Ereignissen mit Steuerein- und ausgängen (Kontrollfluss-Steuerung), 2) Algorithmus mit Datenein- und ausgängen sowie internen Daten (Datenfluss und -verarbeitung). Die Spezifikation kann textuell oder grafisch erfolgen. Funktionsbausteine werden zur Programmierung wie in der IEC 61131-3 instanziiert. Daher sind die sprachlichen Hilfsmittel zur Beschreibung der FB-Schnittstelle sehr ähnlich; siehe dazu auch Kap. 2.

310

9 Programmierung durch Konfigurierung nach IEC 61499

Abb. 9.5 zeigt die grafische Darstellung eines Funktionsbausteins nach IEC 61499.

Instanzname Ereigniseingänge

Ereignisausgänge

AusführungsKontrolle Bezeichner Algorithmus

Dateneingänge

Datenausgänge

mit internen Daten

Abb. 9.5. Grafische Darstellung eines Funktionsbausteins. Inhalte der Ausführungskontrolle, des Algorithmus’ sowie interne Daten werden auf dieser Ebene nicht dargestellt.

Der Algorithmus-Teil wird wie ein POE-Rumpf nach IEC 61131-3 programmiert. Der Teil Ausführungskontrolle wird durch ein Zustandsdiagramm bzw. Ablaufsprache (AS nach IEC 61131-3) dargestellt. Die Ereignis-Eingänge dienen als Eingangswerte für sogenannte „Zustandsdiagramme“ (engl.: ECC: Execution Control Chart). Dabei handelt es sich um Zustandsautomaten, die, abhängig vom Zustand und eintreffenden Ereignissen, die Ausführungszeitpunkte des Algorithmus regeln.

Verteiler&Zaehler EVENT EVENT

INITI REQ

UINT BOOL INT INT

START G IN0 IN1

INITO CNF

EVENT EVENT

SEL_Zaehler SEL_OUT COUNT

BEGINN

INT UINT

1

INIT_ZUST

TI INI

RE Q

INIT

INITO

1

MAIN_ZUST

MAIN

Bsp. 9.1. Beispiel eines Funktionsbausteins mit typisierten formalen Parametern und Zustandsdiagramm

CNF

9.2 IEC 61499 - die Norm für verteilte Systeme

311

BEGINN

INITI INIT_ZUST

REQ N INIT

INITO

Algorithmus INIT

MAIN_ZUST

N MAIN

CNF

Algorithmus MAIN

1

Bsp. 9.2. Ausführungskontrolle des Bsp. 9.1 mit Ablaufsprache (AS) nach IEC 61131-3. Die Ausgangs-Ereignisse CNF und INITO werden vom Anwenderprogramm gesetzt bzw. durch den Aufruf von Standard-FBs verwaltet.

Das Bsp. 9.1 enthält den Funktionsbaustein SEL_ZAEHLER (Instanzname Verteiler&Zaehler), der aus einem ECC-Kontrollteil und dem Algorithmusteil besteht, welcher sich wiederum aus den beiden Algorithmen INIT und MAIN zusammensetzt. Die Ausführungskontrolle bestimmt, welcher Algorithmusteil wann aktiv ist. In Bsp. 9.1 wird bei Eintreffen des Ereignisses INITI die FB-Steuerung vom Initialzustand BEGINN in den Zustand INIT_ZUST versetzt und der Algorithmus INIT ausgeführt. Danach erfolgt ein SET der Ereignis-Ausgangsvariablen INITO, gefolgt von einem RESET (insgesamt also ein Signalimpuls). Jetzt wertet die Ausführungskontrolle die folgende Transition, hier mit „1“ parametriert, aus. Dadurch wird in den Zustand BEGINN weitergeschaltet. Bei Eintreffen von REQ wird sinngemäß verfahren. Dieses Verhalten ist äquivalent zu den Aktionen der Ablaufsprache (AS) der IEC 61131-3 und wird mit Bsp. 9.2 angedeutet. Die IEC 61499 geht allerdings davon aus, dass es günstiger ist, die Ausführungskontrolle über Zustandsgrafen zu spezifizieren, da bei dieser Methode zu einem Zeitpunkt immer nur genau ein Zustand aktiv sein kann. In Ablaufsprache kann man dies erreichen, indem Simultan-Verzweigungen verboten werden. In Bsp. 9.3 wird die textuelle Definition des FB-Typs von Bsp. 9.1 dargestellt.

312

9 Programmierung durch Konfigurierung nach IEC 61499

FUNCTION_BLOCK SEL_ZAEHLER EVENT_INPUT INITI WITH START; REQ WITH G, IN0, IN1; END_EVENT EVENT_OUTPUT INITO WITH COUNT; CNF WITH SEL_OUT, COUNT; END_EVENT VAR_INPUT START: G: IN0, IN1: END_VAR

UINT; BOOL; INT;

VAR_OUTPUT SEL_OUT: COUNT: END_VAR

INT; UINT;

ALGORITHM INIT: INTERNAL_COUNT := START; COUNT := INTERNAL_COUNT; END_ALGORITHM

ALGORITHM MAIN: IF G = 0 THEN SEL_OUT := IN0; ELSE SEL_OUT := IN1; END_IF INTERNAL_COUNT := INTERNAL_COUNT +1; COUNT := INTERNAL_COUNT;

VAR INTERNAL_COUNT: UINT; END_VAR

END_ALGORITHM

END_FUNCTION_BLOCK

Bsp. 9.3. Bsp. 9.1 in textueller Repräsentation (Structured Text ST der IEC 61131-3).

Das Schlüsselwort WITH verbindet ein Ereignisein- oder ausgang mit einem Datenein- oder ausgang. Ist ein solcher Ereignis-Parameter gesetzt, zeigt er die Gültigkeit der mit WITH zugeordneten Datenleitung an. Zusammengesetzte Funktionsbausteine. Für eine übersichtliche bzw. objektorientierte Darstellung können die bisher erläuterten „Basis-Funktionsbausteine“ zu sogenannten „Zusammengesetzten Funktionsbausteinen“ (engl.: Composite function block) verbunden werden, die, einmal verschmolzen, einen neuen Funktionsbaustein darstellen, wie es Abb. 9.6 zeigt.

9.2 IEC 61499 - die Norm für verteilte Systeme

313

b)

a)

Heizung_EG

FB Name

INIT REQ

INIT0 CNF

Heiz_Kontrolle FB-Typ

tmp Zeit cm

Ausdehnung Kontrollzahl A_Meldung

Abb. 9.6. Ein zusammengesetzter Funktionsbaustein besteht aus mehreren Funktionsbausteinen, die durch Verschaltung über eine gemeinsame Schnittstelle verfügen. a) Beispiel: Innere Struktur eines Zusammengesetzten FBs b) Beispielhaftes äußeres Erscheinungsbild dieses FBs

Zusammengesetzte Funktionsbausteine besitzen keine eigene Ausführungskontrolle, denn diese ergibt sich aus der Summe der Steuerungen der einzelnen FBs. In der grafische Darstellung der Abb. 9.6 a) ist daher der „FB-Kopf leer“.

9.2.6 Erstellung einer Anwendung Anwenderprogrammierer der IEC 61499 programmieren, indem sie vorgefertigte Funktionsbausteine konfigurieren und parametrieren.

FB Standard-FBs

Benutzerdefinierte FBs

Erläuterung x FBs mit Funktionalität wie in IEC 61131-3, x Service-Schnittstellen-FBs (standardisierte Kommunikationsdienste), x Ereignis-FBs (standardisierte Ereigniserzeugung und verarbeitung) Algorithmen und ECC-Ausführungskontrolle z.B. nach IEC 61131-3 programmiert

Tab. 9.1. Unterscheidung von Funktionsbausteinen nach IEC 61499

Die in Tab. 9.1 genannten Funktionsbausteine können als Basis-FBs oder zusammengesetzte FBs mit gemeinsamer Schnittstelle realisiert sein.

314

9 Programmierung durch Konfigurierung nach IEC 61499

Die Ereignis-FBs stellen beispielsweise Funktionen zur Zusammenführung (Merge) und Vervielfachung (Split) oder zur Erzeugung einmaliger oder zyklisch wiederkehrender Ereignisse zur Verfügung. Mit einem Konfigurations-Editor erfolgt die Verteilung der Bausteine auf die Ressourcen (Geräte) sowie die Verbindung der FBs untereinander.

9.3 Überblick über die Teile der IEC 61499 Die Norm IEC 61499 besteht aus drei Teilen, mit den in Tab. 9.2 zusammengefassten Schwerpunkten ([IEC 61499-08]) mit Stand von Mai 2008. Eine Neufassung dieser Norm ist für etwa 2010 vorgesehen.

Teil 1. Architecture

2. Software Tool Requirements 3. Rules for Compliance Profiles

Stichworte zum Inhalt Einführung und Modellbildung, beschreibt den Geltungsbereich, definiert gemeinsame Begriffe, Spezifikation der Funktionsbausteine, ServiceSchnittstellen, Konfiguration und Syntax. enthält Beschreibungen zur Unterstützung des Lebenszyklus von verteilten Programmen. Dieses Dokument befindet sich noch in der Entwurfsphase. Beschreibt Regeln zur Überprüfung der Verträglichkeit von Anwenderprogrammen mit der Norm, ähnlich wie bei IEC 61131-3.

Tab. 9.2. Aufbau und Inhalte der Norm IEC 61499

10 Inhalt der beiliegenden CD und DVD

10.1 IEC-Programmiersysteme STEP 7 und OpenPCS Auf DVD bzw. CD liegen diesem Buch folgende Informationen und Programme bei: 1) DVD: STEP 7 Professional 2006 SR5 Engineering Software für SIMATIC S7 / M7 / C7 1 als System zur SPS-Programmierung nach IEC 61131-3 mit den Sprachen: AWL, KOP, FUP, S7-GRAPH und S7-SCL sowie zusätzlich der SPS-Simulation PLCSIM und das Addon iMAP. Der Automation License Manager sowie elektronische Handbücher runden das Paket ab; ablauffähig unter Windows XP Professional SP3, Windows Server 2003 SP2 standard edition und Windows Vista 32 Bit Ultimate/Business mit/ohne SP1. 2) CD: Open PCS, ein auf dem PC ablauffähiges Programmiersystem (Vollversion) nach IEC 61131-3 mit den Sprachen: AWL, KOP, FBS, AS, ST und CFC2; ablauffähig unter Windows Server 2003, Windows XP SP2 oder Windows Vista 32bit. Zur Simulation der Programme auf dem PC steht die SPS- Simulation SmartPLC zur Verfügung. SmartPLC/OPC ist der zugehörige OPC- Server, nur erforderlich bei zusätzlichem Anschluss von Fremdhardware und / oder externen OPC- Clients. 3) CD: Beispiele dieses Buchs als Quelldateien, 4) CD: Einkaufsberater für Programmiersysteme nach IEC 61131-3. Die auf CD mitgelieferte Datei LIESMICH.TXT beinhaltet wichtige Informationen zur Installation und Benutzung der Dateien und Programme. Sie zeigt insbesondere, wie die Dateien auf Festplatte kopiert werden können und gibt Hinweise zur Benutzung der Beispiele und des Einkaufsberaters. Die Datei LIESMICH.TXT ist eine ASCII-Datei und kann mit einem üblichen Editor (z.B. in Windows) gelesen werden. Die übrigen Dateien der beiden Programmiersysteme sind in einem selbstentpackenden Format bzw. als Installationsroutinen hinterlegt, d.h. sie können nicht 1 2

FUP entspricht FBS, S7-GRAPH entspricht AS, S7-SCL entspricht ST kein Teil der IEC 61131-3

316

10 Inhalt der beiliegenden CD und DVD

direkt gelesen werden, sondern müssen sich erst selbst dekomprimieren oder installieren. Zusätzliche Software ist nicht erforderlich. Demo-Versionen STEP 7 (Siemens, www.siemens.com) und Open PCS (infoteam, www.infoteam.de). Mit Hilfe der oben beschriebenen Versionen zweier ausgewählter Programmiersysteme kann der Leser Beispiele des Buchs sowie eigene programmieren, verändern, erweitern und prüfen lassen, um die SPS-Programmierung nach IEC 61131-3 zu trainieren. STEP 7 Professional beinhaltet neben den Programmiersprachen auch eine SPSSimulation S7-PLCSIM, um Programme auch ohne physikalische Hardware testen zu können. OpenPCS liegt die Programmiersprache CFC bei sowie ein Ausführungspaket (Smart PLC/SIM), das zusätzlich die Ausführung eines SPSProgramms auf dem PC erlaubt (Offline-Simulation), und der OPC-Server SmartPLC/OPC. Hinweise zum Einsatz von kommerziellen Versionen sowie Bezugsmöglichkeiten (auch Hardware) zu den einzelnen Programmiersystemen sind den jeweiligen Unterverzeichnissen der CD bzw. DVD zu entnehmen. Die Verfasser zeichnen für Inhalt und Funktionsweise dieser Programmierversionen nicht verantwortlich. Sie enthalten teilweise Einschränkungen gegenüber der Funktionalität der Produkte. Ihre Verwendung ist nur im Zusammenhang mit dem Buch zu Lern- und Schulungszwecken gestattet (bestimmungsgemäßer Gebrauch). AWL - Beispiele Um die Programmteile dieses Buchs nicht abtippen zu müssen, liegen die wichtigsten AWL-Beispiele auf CD vor. Nähere Informationen dazu sind ebenfalls im LIESMICH.TXT zu finden.

10.2 Einkaufsberater für SPS-Programmiersysteme nach IEC 61131-3

317

10.2 Einkaufsberater für SPS-Programmiersysteme nach IEC 61131-3 Diesem Buch liegt ein Einkaufsberater (CD) als Datei im Format „Word für Windows (1997-2003, 2007)“ bei. Inhalt des Einkaufsberaters (Datei Eink-Ber.doc):

Einkaufsberater IEC 61131-3

für

SPS-Programmiersysteme

nach

Checklisten zur Bewertung von SPS-Programmiersystemen Benutzung der Checklisten Checklisten für SPS-Programmiersysteme Konformität zur IEC 61131-3 Sprachumfang, Rück- und Querübersetzbarkeit Werkzeuge Arbeitsumgebung, Offenheit und Dokumentation Allgemeines, Kosten Dieser Einkaufsberater besteht im Kern aus „Checklisten“ genannten Tabellen, mit denen eine objektive Bewertung von SPS- Programmiersystemen möglich ist, die normkonform zur IEC 61131-3 sind. Der Gebrauch dieser Checklisten wird zunächst ausführlich erläutert, bevor die einzelnen Bewertungskriterien für SPSProgrammiersysteme vorgestellt werden. Durch Kopieren der Datei kann sowohl eine mehrfache Produktzusammenstellung als auch eine individuelle Bearbeitung der Checklisten vorgenommen werden. Die Tabellen sind in drei verschiedenen Dateiformaten hinterlegt: 1) Microsoft Word für Windows (1997-2003, 2007) (Datei TABELLEN.DOC), 2) Microsoft Excel für Windows (1997-2003, 2007) (Datei TABELLEN.XLS), 3) als RTFI- Text (Datei TABELLEN.RTF). Die Excel-Version besitzt den Vorteil, dass sämtliche Berechnungen automatisch erfolgen.

“This page left intentionally blank.”

A Standard-Funktionen

Dieser Anhang stellt die in Kap. 2 exemplarisch beschriebenen SPS-StandardFunktionen vollständig zusammen. Für jede Standard-Funktion der IEC 61131-3 werden hier ihre: -

Grafische Deklaration, (Semantische) Beschreibung, Spezifizierung einiger Funktionen in Strukturiertem Text (ST)

angegeben. Standard-Funktionen (Std.-FUN) besitzen Eingangsvariablen (Formalparameter) sowie einen Funktionswert (der Rückgabewert der Funktion). Einige Eingangsvariablen sind namenlos. Um ihr Funktionsverhalten zu beschreiben, gelten folgende Vereinbarungen: -

eine einzelne Eingangsvariable ohne Namen wird mit „IN“ bezeichnet, mehrere Eingangsvariablen ohne Namen werden mit „IN1, IN2, ... INn“ durchnumeriert, der Funktionswert wird mit „F“ bezeichnet.

Zur Beschreibung werden u.a. Allgemeine Datentypen (wie ANY oder ANY_BIT) verwendet, deren Bedeutung in Abschn. 3.4.3 erläutert wird und die in Tab. 3.9 zusammengefasst werden. Die Bezeichnung ANY steht dabei als Abkürzung für einen beliebigen der Datentypen: ANY_BIT, ANY_NUM, ANY_STRING, ANY_DATE oder TIME. Viele Standard-Funktionen besitzen einen textuellen Namen sowie eine alternative Darstellung mit einem Symbol (z.B. ADD und „+“). In den Abbildungen und Tabellen werden jeweils beide Varianten angegeben.

320

A Standard-Funktionen

A.1 Funktionen zur Typwandlung

*

*_TO_**

**

ANY_REAL

TRUNC

ANY_INT

ANY_BIT

BCD_TO_**

ANY_INT

ANY_INT

*_TO_BCD

ANY_BIT

* **

Datentyp des Eingangs, z.B. REAL Datentyp des Funktionswerts, z.B. IN

*_TO_**

Funktionsname, z.B. REAL_TO_INT

Abb. A.1. Grafische Deklarationen der Funktionen zur Typumwandlung

Diese Standard-Funktionen wandeln die Eingangsvariablen in den Datentyp ihres Funktionswerts (Typumwandlung, Konvertierung). Name *_TO_**

TRUNC BCD

Funktion / Beschreibung Bei der Umwandlung von REAL-Werten in INT-Werte wird zur nächsten ganzzahligen Zahl auf- bzw. abgerundet, halbe Anteile wie 0,5 oder 0,05 werden dabei aufgerundet. Mit dieser Funktion werden die Stellen eines REAL-Wertes hinter dem Komma abgeschnitten, um einen ganzzahligen Wert zu bilden. Die Ein- bzw. Ausgangswerte vom Typ ANY_BIT stellen BCDkodierte Bitfolgen für die Datentypen BYTE, WORD, DWORD und LWORD dar. Die BCD-Kodierung wird durch die IEC 61131-3 nicht festgelegt, sie ist implementierungsabhängig.

Tab. A.1. Beschreibung der Funktionen zur Typwandlung

A.2 Numerische Funktionen

A.2 Numerische Funktionen

ANY_NUM ANY_REAL

***

Kürzel für:

ABS

ANY_NUM

***

ANY_REAL

SQRT, LN, LOG, EXP, SIN, COS, TAN, ASIN, ACOS, ATAN

Abb. A.2. Grafische Deklarationen der Numerischen Funktionen

Name ABS SQRT LN LOG EXP SIN COS TAN ASIN ACOS ATAN

Funktion Absolutwert Quadratwurzel Natürlicher Logarithmus Logarithmus Basis 10 Exponent Basis e Sinus, IN in Bogenmaß Cosinus, IN in Bogenmaß Tangens, IN in Bogenmaß Arcsin, Hauptwert Arccos, Hauptwert Arctan, Hauptwert

Beschreibung F := | IN | F := —IN F := loge (IN) F := log10 (IN) F := eIN F := SIN (IN) F := COS (IN) F := TAN (IN) F := ARCSIN (IN) F := ARCCOS (IN) F := ARCTAN (IN)

Tab. A.2. Beschreibung der Numerischen Funktionen

321

322

A Standard-Funktionen

A.3 Arithmetische Funktionen ***

ANY_NUM

ANY_NUM

ANY_NUM

***

ANY_NUM

ANY_NUM

.... ANY_NUM

***

ANY_NUM

Kürzel für:

ADD, + MULT, *

***

Kürzel für:

SUB, DIV, /

Abb. A.3. Grafische Deklarationen der Arithmetischen Funktionen ADD, MUL, SUB und DIV

MOD

ANY_INT

ANY_NUM ANY_NUM

ANY_INT

ANY_NUM

***

ANY_NUM ***

***

Kürzel für:

***

Kürzel für:

ANY_NUM

EXPT, **

ANY_NUM MOVE, :=

Abb. A.4. Grafische Deklarationen der Arithmetischen Std-FUN MOD, EXPT und MOVE

Name ADD MUL SUB DIV MOD EXPT MOVE

Symbol + * / ** :=

Funktion Addition Multiplikation Subtraktion Division Restbildung Exponentiation Zuweisung

Beschreibung F := IN1 + IN2 + ... + INn F := IN1 * IN2 * ... * INn F := IN1 - IN2 F := IN1 / IN2 F := IN1 - (IN1/ IN2)*IN2 F := IN1IN2 F := IN

Tab. A.3. Beschreibung der arithmetischen Funktionen. ADD und SUB verwenden den Typ ANYMAGNITUDE. Bei EXPT hat IN1 den Typ ANY_REAL und IN2 den Typ ANY_NUM. MOVE verwendet ANY für Ein- und Ausgang.

A.4 Bitschiebe-Funktionen

323

Bei der Division von ganzen Zahlen muss das Ergebnis wieder eine ganze Zahl sein, ggf. wird das Ergebnis in Richtung Null abgeschnitten. Falls der Eingangsparameter IN2 Null ist, wird zur Laufzeit ein Fehler mit Fehlerursache „Division durch Null“ gemeldet, vgl. Anh. E.

A.4 Bitschiebe-Funktionen *** ANY_BIT

IN

ANY_INT

N

***

Kürzel für:

ANY_BIT

SHL, SHR, ROL, ROR

Abb. A.5. Grafische Deklarationen der Bitschiebe-Funktionen SHL, SHR, ROR und ROL.

Name Funktion SHL Schieben nach links SHR ROR ROL

Beschreibung IN um N Bits nach links schieben, von rechts mit Nullen füllen Schieben nach rechts IN um N Bits nach rechts schieben, von links mit Nullen füllen Rotieren nach rechts IN um N Bits ringförmig nach rechts schieben Rotieren nach links IN um N Bits ringförmig nach links schieben

Tab. A.4. Beschreibung der Bitschiebe-Funktionen. Der Eingang N muss dabei Werte größer gleich Null annehmen.

324

A Standard-Funktionen

A.5 Bitweise Boolesche Funktionen

***

ANY_BIT

ANY_BIT

NOT

ANY_BIT

ANY_BIT .... ANY_BIT

***

ANY_BIT

Kürzel für:

AND, &, OR, >=1, XOR, =2k+1

Abb. A.6. Grafische Deklarationen der Bitweise Booleschen Funktionen AND, OR, XOR und NOT

Name AND OR XOR NOT

Symbol & >=1 =2k+1

Funktion Bitweise UND Bitweise ODER Bitweise EXODER Negation

Beschreibung F := IN1 & IN2 & ... & INn F := IN1 v IN2 v ... v INn F := IN1 XOR IN2 XOR ... XOR INn F := ¬ IN

Tab. A.5. Beschreibung der Bitweise Booleschen Funktionen

Die Verknüpfung zwischen den Eingangsparametern erfolgt bitweise, d.h. jede Bitstelle eines Eingangs wird mit der entsprechenden Bitstelle des anderen Eingangs zur gleichen Bitstelle des Funktionswerts verknüpft. Die grafische Darstellung einer Invertierung kann auch durch einen Kreis „o“ am booleschen Ein- oder Ausgangs einer Funktion erfolgen.

A.6 Auswahl-Funktionen für Max., Min. und Grenzwert

325

A.6 Auswahl-Funktionen für Max., Min. und Grenzwert

ANY_ELEMENTARY

***

ANY_ELEMENTARY

.... ANY_ELEMENTARY

***

Kürzel für:

ANY_ELEMENTARY

MIN, MAX

LIMIT ANY_ELEMENTARY

MN

ANY_ELEMENTARY

IN

ANY_ELEMENTARY

MX

ANY_ELEMENTARY

Abb. A.7. Grafische Deklarationen der Auswahlfunktionen MAX, MIN und LIMIT

Name MAX MIN LIMIT

Funktion Maximum-Bildung Minimum-Bildung Begrenzung

Beschreibung F := MAX (IN1, IN2, ... , INn) F := MIN (IN1, IN2, ... , INn) F := MIN (MAX (IN, MN), MX)

Tab. A.6. Beschreibung der Auswahlfunktionen MAX, MIN und LIMIT

Diese drei Standard-Funktionen werden in Bsp. A.1 und Bsp. A.2 durch Deklaration in ST spezifiziert.

326

A Standard-Funktionen

FUNCTION VAR_INPUT VAR

MAX : ANY_ELEMENTARY (* Maximum-Bildung *) IN1, IN2, ... INn : ANY_ELEMENTARY; END_VAR Elem : ANY_ELEMENTARY; END_VAR (* ANY_ELEMENTARY steht für beliebige Datentypen*)

IF IN1 > IN2 THEN Elem := IN1; ELSE Elem := IN2; END_IF; IF IN3 > Elem THEN Elem := IN3; END_IF; ... IF INn > Elem THEN Elem := INn; END_IF; MAX := Elem; END_FUNCTION

(* erster Vergleich *)

(* nächster Vergleich *)

(* letzter Vergleich *)

(* Schreiben des Funktionswerts *)

Bsp. A.1. Spezifizierung der Auswahlfunktion MAX in ST; für MIN sämtliche „>“ durch „<“ ersetzen.

Die Spezifizierung der Minimum-Funktion MIN kann man aus MAX dadurch erhalten, dass in Bsp. A.1 sämtliche Vorkommen von „>“ durch „<“ ersetzt werden.

FUNCTION LIMIT : ANY_ELEMENTARY (* Grenzwert-Bildung *) VAR_INPUT MN : ANY_ELEMENTARY; IN : ANY_ELEMENTARY; MX : ANY_ELEMENTARY; END_VAR MAX := MIN ( MAX ( IN, MN), MX); (* Aufrufe von MIN von MAX *) END_FUNCTION

Bsp. A.2. Spezifizierung der Auswahlfunktion LIMIT in ST

A.7 Auswahl-Funktionen für Binäre Auswahl und Multiplexer

327

A.7 Auswahl-Funktionen für Binäre Auswahl und Multiplexer

MUX

SEL BOOL

ANY_INT

G

ANY

IN0

ANY

IN1

ANY

ANY

KK

...

1 2

ANY

n

ANY

Abb. A.8. Grafische Deklarationen der Auswahlfunktionen SEL und MUX

Name SEL MUX

Funktion Binäre Auswahl Multiplexer

Beschreibung F := IN0, falls G = 0, IN1 sonst F := INi, falls K = i und 0
Tab. A.7. Beschreibung der Auswahlfunktionen SEL und MUX

Diese beiden Standard-Funktionen werden im folgenden durch Deklaration in ST spezifiziert:

FUNCTION SEL : ANY (* Binäre Auswahl *) VAR_INPUT G : BOOL; IN0 : ANY; IN1 : ANY; END_VAR IF G = 0 THEN SEL := IN0; (* Auswahl des oberen Eingangs *) ELSE SEL := IN1; (* Auswahl des unteren Eingangs *) END_IF; END_FUNCTION

Bsp. A.3. Spezifizierung der Auswahlfunktion SEL in ST

328

A Standard-Funktionen

FUNCTION MUX : ANY (* Multiplexer *) VAR_INPUT K : ANY_INT; IN0 : ANY; IN1 : ANY; ... INn : ANY; END_VAR IF (K < 0) OR (K>=n) THEN ... Fehlermeldung Nr....; (* K negativ oder zu groß *) END_IF; CASE K OF 0: MUX := IN0; (* Auswahl des oberen Eingangs *) 1: MUX := IN1; (* Auswahl des zweiten Eingangs *) ... n: MUX := INn; (* Auswahl des untersten Eingangs *) END_CASE; END_FUNCTION

Bsp. A.4. Spezifizierung der Auswahlfunktion MUX in ST

A.8 Vergleichs-Funktionen

ANY_ELEMENTARY

***

ANY_ELEMENTARY

ANY_ELEMENTARY

***

ANY_ELEMENTARY

BOOL

.... ANY_ELEMENTARY ***

Kürzel für:

BOOL GT, >, GE, >=, LT, <, LE, <=, EQ, =

***

Kürzel für:

NE, <>

(nicht erweiterbar)

Abb. A.9. Grafische Deklarationen der Vergleichsfunktionen GT, GE, LT, LE, EQ, NE

A.8 Vergleichs-Funktionen

Name GT GE LT LE EQ NE

Funktion Vergleich auf „> “ Vergleich auf „> =“ Vergleich auf „< “ Vergleich auf „< =“ Vergleich auf „= “ Vergleich auf „<>“

Beschreibung F := 1, falls INi F := 1, falls INi F := 1, falls INi F := 1, falls INi F := 1, falls INi F := 1, falls INi

> >= < <= = <>

IN(i+1), IN(i+1), IN(i+1), IN(i+1), IN(i+1), IN(i+1),

329

0 sonst 0 sonst 0 sonst 0 sonst 0 sonst 0 sonst

Tab. A.8. Beschreibung der Vergleichsfunktionen

Diese Standard-Funktionen werden in Bsp. A.5 stellvertretend durch Deklaration von GT in ST spezifiziert, von der die übrigen leicht abgeleitet werden können.

FUNCTION GT : BOOL (* Vergleich auf größer *) VAR_INPUT IN1, IN2, ... INn : ANY_ELEMENTARY; END_VAR IF (IN1 > IN2) AND (IN2 > IN3) ... AND (IN(n-1) > INn) THEN GT := TRUE; (* Eingänge sind „sortiert“: monoton steigend *) ELSE GT := FALSE; (* Bedingung nicht erfüllt *) END_IF; END_FUNCTION

Bsp. A.5. Spezifizierung der Vergleichsfunktion GT in ST

330

A Standard-Funktionen

A.9 Funktionen für Zeichenfolgen *** ANY_STRING ANY_INT ***

IN ANY_STRING

L

Kürzel für:

LEFT, RIGHT

MID ANY_STRING

IN

ANY_INT

L

ANY_INT

P

ANY_STRING

ANY_STRING

LEN

ANY_INT

Abb. A.10. Grafische Deklarationen der Zeichenfolge-Funktionen LEFT, RIGHT, MID und LEN

CONCAT ANY_STRING ANY_STRING ... ANY_STRING

ANY_STRING

Abb. A.11. Grafische Deklarationen der Zeichenfolge-Funktion CONCAT

A.9 Funktionen für Zeichenfolgen

331

INSERT ANY_STRING

IN1

ANY_STRING

IN2

ANY_INT

P

ANY_STRING

DELETE ANY_STRING

IN1

ANY_INT

L

ANY_INT

P

ANY_STRING

Abb. A.12. Grafische Deklarationen der Zeichenfolge-Funktionen INSERT und DELETE

REPLACE ANY_STRING

IN1

ANY_STRING

IN2

ANY_INT

L

ANY_INT

P

FIND

ANY_STRING

ANY_STRING

IN1

ANY_STRING

IN2

ANY_INT

Abb. A.13. Grafische Deklarationen der Zeichenfolge-Funktionen REPLACE und FIND

332

A Standard-Funktionen

Name LEN LEFT RIGHT MID CONCAT INSERT DELETE REPLACE

FIND

Funktion ermittelt die Länge einer Zeichenfolge Anfangsabschnitt einer Zeichenfolge Endeabschnitt einer Zeichenfolge Mittelabschnitt einer Zeichenfolge Aneinanderreihung von Zeichenfolgen Einfügen einer Zeichenfolge in eine andere Löscht Abschnitt in einer Zeichenfolge Ersetzt einen Abschnitt in einer Zeichenfolge durch einen anderen ermittelt die Position eines Abschnitts in einer Zeichenfolge

Beschreibung F := Anzahl der Zeichen in IN F := Anfangsabschnitt mit L Zeichen F := Endeabschnitt mit L Zeichen F := Mittelabschnitt ab Position P mit L Zeichen F := Gesamt-Zeichenfolge F := Gesamt-Zeichenfolge mit neuem Teil ab Position P F := Rest-Zeichenfolge mit gelöschtem Teil (L Zeichen) ab Position P F := Gesamt-Zeichenfolge mit ersetztem Teil (L Zeichen) ab Position P F := Index der gefundenen Position, sonst 0

Tab. A.9. Beschreibung der Zeichenfolge-Funktionen

Die Position eines Zeichens innerhalb einer ANY_STRING wird beginnend mit „1“ angegeben.

Zeichenfolge

vom

Die Eingänge L und P müssen dabei Werte größer gleich Null annehmen.

Typ

A.10 Funktionen für Datentypen der Zeit

333

A.10 Funktionen für Datentypen der Zeit

*** TIME

IN1

TIME

IN2

***

***

TIME

Kürzel für:

TOD

IN1

TIME

IN2

***

TOD

DT

IN1

TIME

IN2

DT

ADD, +, SUB, -

Abb. A.14. Grafische Deklarationen der gemeinsamen Zeit-Funktionen für Addition und Subtraktion

*** DATE

IN1

DATE

IN2

***

TIME

***

TOD

IN1

TOD

IN2

Kürzel für:

***

TIME

DT

IN1

DT

IN2

TIME

SUB, -

Abb. A.15. Grafische Deklarationen der zusätzlichen Zeit-Funktionen für Subtraktion

CONCAT

*** TIME

IN1

ANY_NUM

IN2

TIME

***

Kürzel für:

DT

IN1

TOD

IN2

DT

MUL, *, DIV, /

Abb. A.16. Grafische Deklarationen der Zeit-Funktionen für MUL, DIV und CONCAT

334

A Standard-Funktionen

DT

DATE_AND_TIME_TO_TIME_OF_DAY

TOD

DT

DATE_AND_TIME_TO_DATE

DATE

Abb. A.17. Grafische Deklarationen der Zeit-Funktionen zur Typumwandlung

Die Abkürzungen TOD und DT können gleichwertig anstelle der längeren Schlüsselworte TIME_OF_DAY bzw. DATE_AND_TIME verwendet werden. Anstelle der Funktionsnamen ADD und SUB können auch die Varianten ADD_TIME, SUB_TIME und die Kombinationen ADD_TOD_TIME, ADD_DT_TIME, SUB_DATE_DATE, SUB_TOD_TIME, SUB_TOD_TOD, SUB_DT_TIME, MULTIME, DIVTIME, CONCAT_DATE_TOD verwendet werden. Von dem Gebrauch der arithmetischen Bezeichnungen „+“, „-“, „/“ oder „*“ sowie ADD, SUB, DIV und MUL rät die Norm inzwischen explizit ab, um Verwechselungen und dadurch fehlerhafte Anwendung zu vermeiden.

A.11 Funktionen für Datentypen der Aufzählung Die Standard-Funktionen SEL, MUX, EQ und NE können ebenfalls für Aufzählungs-Datentypen verwendet werden. Sie sind in diesen Fällen sinngemäß wie für ganze Zahlen anzuwenden (Werte von Aufzählungen entsprechen vom Programmiersystem „codierten“ Konstanten).

B Standard-Funktionsbausteine

Dieser Anhang stellt die in Kap. 2 exemplarisch beschriebenen StandardFunktionsbausteine vollständig zusammen. Für jeden Standard-FB der IEC 61131-3 werden hier seine: -

Grafische Deklaration, (Semantische) Beschreibung, Spezifizierung einiger FBs in Strukturiertem Text (ST)

angegeben. In diesem Buch werden die Ein- und Ausgänge der Std.-FBs mit den in der IEC 61131-3 festegelegten Namen versehen. Es soll jedoch darauf hingewiesen werden, dass aufgrund der Aufrufmöglichkeit der FBs als „AWL-Operatoren“ Konflikte entstehen können. Diese treten auf für die AWL-Operatoren (vgl. Abschn. 4.1.) LD, R und S, die zur Überprüfung der korrekten Programmsyntax von den FB-Eingängen LD, R und S unterschieden werden müssen. Diese drei Formaloperanden könnten beispielsweise auch (je nach Programmiersystem) mit LOAD, RESET und SET benannt werden, um Verwechselungen zu vermeiden.

336

B Standard-Funktionsbausteine

B.1 Bistabile Elemente (Flip-Flops) SR BOOL

S1

BOOL

R

Q1

RS

BOOL

BOOL

S

BOOL

R1 Q1

BOOL

Abb. B.1. Grafische Deklarationen der Funktionsbausteine SR und RS

FUNCTION_BLOCK SR (* FlipFlop mit vorrangigem Setzen *) VAR_INPUT S1 : BOOL; R : BOOL; END_VAR VAR_OUTPUT Q1 : BOOL; END_VAR Q1 := S1 OR ( NOT R AND Q1); END_FUNCTION_BLOCK FUNCTION_BLOCK RS (* FlipFlop mit vorrangigem Rücksetzen *) VAR_INPUT S : BOOL; R1 : BOOL; END_VAR VAR_OUTPUT Q1 : BOOL; END_VAR Q1 := NOT R1 AND ( S OR Q1); END_FUNCTION_BLOCK

Bsp. B.1. Spezifizierung der Funktionsbausteine SR und RS in ST

Diese beiden Flip-Flops realisieren Vorrangiges Setzen und Rücksetzen.

B.2 Flankenerkennung

337

B.2 Flankenerkennung R_TRIG BOOL

CLK

Q

F_TRIG BOOL

BOOL

CLK

Q

BOOL

Abb. B.2. Grafische Deklarationen der Funktionsbausteine R_TRIG und F_TRIG

FUNCTION_BLOCK R_TRIG VAR_INPUT CLK : BOOL; END_VAR VAR_OUTPUT Q : BOOL; END_VAR VAR RETAIN MEM : BOOL := 0; END_VAR Q := CLK AND NOT MEM; MEM := CLK; END_FUNCTION_BLOCK

(* steigende Flanke *)

(* beispielhafter Gebrauch der Pufferung *) (* Flankenmerker initialisieren *) (* steigende Flanke erkennen *) (* Flankenmerker rücksetzen *)

FUNCTION_BLOCK F_TRIG (* fallende Flanke *) VAR_INPUT CLK : BOOL; END_VAR VAR_OUTPUT Q : BOOL; END_VAR VAR RETAIN MEM : BOOL := 1; (* Flankenmerker initialisieren *) END_VAR Q := NOT CLK AND NOT MEM; (* fallende Flanke erkennen *) MEM := NOT CLK; (* Flankenmerker rücksetzen *) END_FUNCTION_BLOCK

Bsp. B.2. Spezifizierung der Funktionsbausteine R_TRIG und F_TRIG in ST

Bei den FBs R_TRIG und F_TRIG ist zu beachten, dass sie bereits beim ersten Aufruf eine „Flanke“ erkennen, wenn der Eingang bei R_TRIG auf TRUE und bei F_TRIG auf FALSE liegt.

338

B Standard-Funktionsbausteine

B.3 Zähler CTU BOOL BOOL INT

CU R PV

CTD Q

CV

BOOL BOOL INT

BOOL INT

CD LD PV

Q CV

BOOL INT

CTUD BOOL

CU

QU

BOOL

BOOL BOOL

CD R LD PV

QD

BOOL

CV

INT

BOOL INT

Abb. B.3. Grafische Deklarationen der Funktionsbausteine CTU, CTD und CTUD

FUNCTION_BLOCK CTU (* Vorwärts-Zähler *) VAR_INPUT CU : BOOL R_EDGE; (* CU mit steigender Flanke *) R : BOOL; PV : INT; END_VAR VAR_OUTPUT Q : BOOL; CV : INT; END_VAR IF R THEN (* Zähler rücksetzen *) CV := 0; ELSIF CU AND ( CV < PV) THEN CV := CV + 1; (* hochzählen *) ENDIF; Q := (CV >= PV); (* Grenzwert erreicht *) END_FUNCTION_BLOCK

Bsp. B.3. Spezifizierung der Funktionsbausteine CTU und CTD in ST (wird fortgesetzt)

Die Zähler CTU und CTD gibt es auch in den Varianten für DINT, LINT, UDINT, ULINT und werden dann entsprechend mit CTU_DINT usw. bis CTD_ULINT bezeichnet.

B.3 Zähler FUNCTION_BLOCK CTD (* Rückwärts-Zähler *) VAR_INPUT CD : BOOL R_EDGE; (* CD mit steigender Flanke *) LD : BOOL; PV : INT; END_VAR VAR_OUTPUT Q : BOOL; CV : INT; END_VAR IF LD THEN (* Zähler rücksetzen *) CV := PV; ELSIF CD AND ( CV > PV) THEN CV := CV - 1; (* runterzählen *) ENDIF; Q := (CV <= 0); (* Null erreicht *) END_FUNCTION_BLOCK

Bsp. B.3. (Fortsetzung)

FUNCTION_BLOCK CTUD (* Vorwärts/Rückwärts-Zähler *) VAR_INPUT CU : BOOL R_EDGE; (* CU mit steigender Flanke *) CD : BOOL R_EDGE; (* CD mit steigender Flanke *) R : BOOL; LD : BOOL; PV : INT; END_VAR VAR_OUTPUT QU : BOOL; QD : BOOL; CV : INT; END_VAR IF R THEN (* Zähler vorrangig rücksetzen *) CV := 0; ELSIF LD THEN CV := PV; (* auf Zählwert setzen *) ELSE IF NOT (CU AND CD) THEN IF CU AND ( CV < PV) THEN CV := CV + 1; (* hochzählen *) ELSIF CD AND ( CV > PV) THEN CV := CV - 1; (* runterzählen *) ENDIF; ENDIF; ENDIF QU := (CV >= PV); (* Grenzwert erreicht *) QD := (CV <= 0); (* Null erreicht *) END_FUNCTION_BLOCK

Bsp. B.4. Spezifizierung des Funktionsbausteins CTUD in ST

339

340

B Standard-Funktionsbausteine

B.4 Zeitgeber (Zeiten) *** BOOL TIME ***

IN PT

Q ET

Kürzel für:

BOOL TIME TON, T---0,

TOF, 0---T,

TP

Abb. B.4. Grafische Deklarationen der Funktionsbausteine TON, TOF und TP

Die Spezifizierung der Zeitgeber-Elemente TP, TON und TOF wird im Folgenden anhand von Zeitdiagrammen vorgenommen. Dieses Zeitverhalten setzt jeweils voraus, dass die Zykluszeit des periodischen SPS-Programms, in dem die Zeit verwendet wird, vernachlässigbar gering zur Zeitdauer PT ist, wenn die Zeit im Zyklus nur einmal aufgerufen wird. In den Diagrammen wird das an den Ausgängen Q und ET zu beobachtende Verhalten der Zeit in Abhängigkeit vom Eingang IN dargestellt. Die Zeitachse läuft dabei von links nach rechts und ist mit „t“ beschriftet. Die booleschen Variablen IN und Q wechseln zwischen „0“ und „1“ und für ET wird der Verlauf des anwachsenden Zeitwerts dargestellt.

IN Q PT

PT

PT

PT ET t0

t1

t0+PT

t2 t3

t4

t2+PT

t5

Zeit t

t4+PT

Abb. B.5. Zeitverhalten für Zeitimpuls TP abhängig vom Eingang IN

B.4 Zeitgeber (Zeiten)

341

Der Std-FB „TP“ stellt einen Impulsgeber dar, der bei steigender Flanke am INEingang am Ausgang Q einen konstant langen Impuls liefert. Am Ausgang ET kann jederzeit die bis dahin aufgelaufene Zeit abgefragt werden. Wie man in Abb. B.5 erkennt, sind Zeiten vom Typ TP nicht „re-triggerbar“. Falls die Abstände zwischen den Eingangsimpulsen auf IN kürzer sind als die voreingestellte Zeitdauer, bleibt die Impulsdauer dennoch konstant; siehe Zeitraum [t2; t2+PT]. Die Zeitdauer beginnt also nicht mit jeder steigenden Flanke an IN.

IN Q PT

PT

PT

PT ET t0

t1

t0+PT

t2 t3

t4

t5

Zeit t

t4+PT

Abb. B.6. Zeitverhalten für Einschalt-Verzögerung TON abhängig vom Eingang IN

Die Einschaltverzögerung TON liefert an Q zeitverzögert den Eingangswert IN, wenn für IN eine steigende Flanke erkannt wird. Ist der Eingang IN jedoch nur für einen kurzen Impuls (kleiner PT) auf „1“, wird die Zeit für diese Flanke nicht mehr gestartet. Am Ausgang ET kann die aufgelaufene Zeit abgelesen werden.

342

B Standard-Funktionsbausteine

IN Q PT

PT

PT ET t0

t1

t2 t3 t4

t1+PT

t5

Zeit t

t5+PT

Abb. B.7. Zeitverhalten für Ausschalt-Verzögerung TOF abhängig vom Eingang IN

Die Ausschaltverzögerung ist die inverse Funktion zu TON, d.h. sie verzögert in derselben Weise eine fallende Flanke wie TON eine steigende. Wie sich die Zeit verhält, wenn PT während der Zeitoperation verändert wird, ist implementierungsabhängig.

C AWL-Beispiele

Dieser Anhang beinhalte für jeden POE-Typ jeweils ein ausführliches Beispiel zur SPS-Programmierung nach IEC 61131-3, um die Erläuterungen in Kap. 2 und Kap. 4 zu unterstützen. Diese Beispiele sind auf der diesem Buch beiliegenden CD zu finden.

C.1 Beispiel für FUNCTION Die Funktion ByteExtr extrahiert das obere oder untere Byte eines Eingangsworts und gibt es als Funktionswert zurück.

FUNCTION ByteExtr : BYTE VAR_INPUT Wort : WORD; Oben : BOOL; END_VAR LD Oben EQ FALSE JMPCN ObByte LD Wort WORD_TO_BYTE ST ByteExtr RET ObByte: LD Wort SHR 8 WORD_TO_BYTE ST ByteExtr RET

(* Extraktion Byte aus Wort *) (* Beginn Deklarationsteil *) (* Eingangsvariablen *) (* Wort besteht aus oberem + unterem Byte *) (* TRUE: oberes Byte, sonst unteres nehmen *) (* Beginn Anweisungsteil *) (* Oberes oder unteres Byte extrahieren? *) (* unteres? *) (* Sprung bei Extraktion des oberen Bytes *) (* Wort laden *) (* Umwandlung fuer Typvertraeglichkeit *) (* Zuweisung an den Funktionswert *) (* nix zu tun *) (* Sprungmarke *) (* Wort laden *) (* oberes Byte 8 Bits nach rechts schieben *) (* Umwandlung fuer Typvertraeglichkeit *) (* Ruecksprung mit Funktionswert in AE *) (* FUN-Ende *)

END_FUNCTION

Bsp. C.1. Beispiel für die Deklaration einer Funktion in AWL

344

C AWL-Beispiele

Die Funktion ByteExtr in Bsp. C.1 besitzt den Eingangsparameter „Wort“ vom Typ WORD und den booleschen Eingang Oben. Der Rückgabewert der Funktion ist vom Typ BYTE. Diese Funktion benötigt keine lokalen Variablen, weshalb der Deklarationsteil VAR ... VAR_END fehlt. Der Rückgabewert steht im aktuellen Ergebnis (AE), wenn die Funktion mit RET zum Aufrufer zurückkehrt. Das AE ist an dieser Stelle (Sprungmarke Ende:) vom Datentyp WORD, denn Wort wurde zuvor geladen, der Funktionswert nach der Typkonvertierung vom Typ BYTE. Die IEC 61131-3 fordert an Stellen wie dieser immer eine strenge „Typverträglichkeit“, welche das Programmiersystems sicher zu stellen hat. Daher wird in Bsp. C.1 eine Standard-Funktion zur Typumwandlung aufgerufen (WORD_TO_BYTE). Bsp. C.2 zeigt den Anweisungsteil von ByteExtr in der Programmiersprache ST.

FUNCTION ByteExtr : BYTE (* Extraktion Byte aus Wort *) VAR_INPUT ... END_VAR (* wie oben *) IF Oben THEN ByteExtr := WORD_TO_BYTE (SHR (Wort, 8) ); ELSE ByteExtr := WORD_TO_BYTE (Wort); END_IF; END_FUNCTION

Bsp. C.2. Anweisungsteil von Bsp. C.1 in ST

FUNCTION ByteExtr WORD

Wort

BOOL

Oben

ByteExtr BYTE

%MW4 TRUE

Wort

%MB4

Oben

... END_FUNCTION

Bsp. C.3. Grafischer Deklarationsteil der Funktionsdeklaration zu Bsp. C.1 (links) mit einem Aufruf-Beispiel (rechts)

Bsp. C.3 zeigt den Deklarationsteil und einen Beispiel-Aufruf der Funktion ByteExtr in grafischer Darstellung. Der Aufruf ersetzt das untere Byte des Merkerworts 4 durch sein oberes Byte.

C.2 Beispiel für FUNCTION_BLOCK

345

C.2 Beispiel für FUNCTION_BLOCK Der Funktionsbaustein DivMRest berechnet das Divisionsergebnis zweier ganzer Zahlen und liefert sowohl das Divisionsergebnis als auch den Divisionsrest zurück. In einem Ausgangsflag wird „Division durch Null“ angezeigt.

FUNCTION_BLOCK DivMRest VAR_INPUT Dividend : INT; Divisor : INT; END_VAR VAR_OUTPUT RETAIN Quotient : INT; DivRest : INT; DivFehler : BOOL; END_VAR LD EQ JMPC LD DIV ST MUL ST LD SUB ST LD ST JMP Fehler: LD ST ST LD ST Ende: RET

0 Divisor Fehler Dividend Divisor Quotient Divisor DivRest Dividend DivRest DivRest FALSE DivFehler Ende 0 Quotient DivRest TRUE DivFehler

(* Division mit Rest *) (* Beginn Deklarationsteil *) (* Eingangsparameter *) (* zu teilende ganze Zahl *) (* ganzzahliger Teiler *) (* batteriegepufferte Ausgangsparameter *) (* Ergebnis der Division *) (* Divisionsrest *) (* Flag für Division durch Null *) (* Beginn Anweisungsteil *) (* Null laden *) (* Ist Divisor Null? *) (* Fehlerfall abfangen *) (* Dividenden laden, Divisor ungleich Null *) (* Division durchfuehren *) (* ganzzahliges Divisionsergebnis speichern *) (* Divisionsergebnis mit Divisor multiplizieren *) (* Zwischenergebnis merken *) (* Dividenden laden *) (* Zwischenergebnis davon abziehen *) (* ergibt den ganzzahligen „Rest“ der Division *) (* logisch „0“ für Fehlerflag: ruecksetzen *) (* Fehlerflag ruecksetzen *) (* fertig, Sprung auf FB-Ende *) (* Behandlung des Fehlers „Division durch Null“ *) (* Null, da Ausgaenge im Fehlerfall ungueltig sind *) (* Resultat ruecksetzen *) (* Rest ruecksetzen *) (* logisch „1“ fuer Fehlerflag: setzen *) (* Fehlerflag setzen *)

(* FB-Ende *) END_FUNCTION_BLOCK

Bsp. C.4. Beispiel für die Deklaration eines Funktionsbausteins in AWL

Der FB DivMRest in Bsp. C.4 berechnet die ganzzahlige Division mit Rest der beiden Eingangsparameter Dividend und Divisor. Bei Division durch Null wird der Fehler-Ausgang DivFehler gesetzt und die beiden anderen Ausgänge werden definiert auf Null gesetzt, da sie ungültig sind. Die Ausgänge sind batteriegepuffert, d.h. sie bleiben innerhalb der FB-Instanz erhalten, von der aus DivMRest aufgerufen wurde.

346

C AWL-Beispiele

Dieses Beispiel kann auch als Funktion formuliert werden, da keine statische Information zwischen den Aufrufen erhalten bleiben muss. Bsp. C.5 zeigt den Anweisungsteil von DivMRest in der Programmiersprache ST.

FUNCTION_BLOCK DivMRest (* Division mit Rest *) VAR_INPUT ... END_VAR (* wie oben *) VAR_OUTPUT RETAIN ... END_VAR IF Divisor = 0 THEN Quotient := 0; DivRest := 0; DivFehler := TRUE; ELSE Quotient := Dividend / Divisor; DivRest := Dividend - (Quotient * Divisor); DivFehler := FALSE; END_IF; END_FUNCTION_BLOCK

Bsp. C.5. Anweisungsteil von Bsp. C.4 in ST

FUNCTION_BLOCK DivMRest

INT INT

Divident Divisor

Quotient DivRest DivFehler

INT INT BOOL

... END_FUNCTION_BLOCK

DivInst DivMRest 100 3

Divident Divisor

Quotient DivRest DivFehler

Resultat Rest Fehler

Bsp. C.6. Grafischer Deklarationsteil zu Bsp. C.4 (oben) und ein Aufruf-Beispiel der FBInstanz DivInst (unten)

C.3 Beispiel für PROGRAM

347

Bsp. C.6 zeigt den Deklarationsteil und einen Beispiel-Aufruf der Funktion DivMRest in grafischer Darstellung. Der Aufruf setzt die Instanziierung dieses FB voraus (DivInst). Die Ausgangsvariablen dieser Instanz besitzen nach Ausführung des FB die Werte: DivInst.Quotient = 33, DivInst.DivRest = 1 und DivInst.DivFehler = FALSE. Diese Rückgabewerte werden jeweils den Variablen Resultat, Rest und Fehler zugewiesen.

C.3 Beispiel für PROGRAM Das Programm HptProg in Bsp. C.7 ist kein abgeschlossenes Programmierbeispiel, sondern zeigt Möglichkeiten zur Realisierung von Aufgaben und Benutzung von Variablen durch den POE-Typ PROGRAM. HptProg startet zunächst eine Echtzeituhr DatUhr, die Datum und Uhrzeit mitführt (Hersteller-FB RTC: Realtime Clock). Anhand dieser Zeit wird festgestellt, wie lange eine Unterbrechung dieses Programm gedauert hat (ZeitDiff). Voraussetzung dafür ist, dass das SPS-System die Unterbrechung feststellen kann (Ress_Laeuft) und eine Hardware-Uhr von der E/A-Peripherie abfragen kann (AktDatum).

PROGRAM HptProg (* Beispiel für ein Hauptprogramm *) VAR_INPUT (* Eingangsvariablen *) T_Start : BOOL := FALSE; (* Eingang Startbedingung *) END_VAR VAR_OUTPUT (* Ausgangsvariablen *) T_Stoerung : BOOL := FALSE; (* Ausgang „Stoerung“ *) END_VAR VAR_GLOBAL RETAIN (* globaler gepufferter Datenbereich *) Ress_Laeuft AT %MX255.5 : BOOL; (* Laeuft-Flag der Ressource/SPS-CPU *) DatUhr : RTC; (* Programm-Uhr: Datum mit Uhrzeit *) AktDatum AT %MD2 : DT; (* Hardware-Uhr: Akt. Datum mit Uhrzeit *) END_VAR VAR_GLOBAL (* globaler Datenbereich *) NotAus AT %IX255.0 : BOOL; (* Kontakt NOT-AUS *) ProgRun : BOOL := FALSE; (* „laeuft“-Merker *) Fehler : BOOL; (* Fehler-Merker *) F_Code : UDINT := 0; (* Fehler-Code, 32 Bit ohne Vorzeichen *) END_VAR VAR (* lokale Variablen *) AT %IX250.2 : BOOL; (* direkt dargestellte Variable *) FehlerBeh : ZFehBeh; (* FB-Instanz *) Flanke : R_TRIG; (* Flankenerkennung *) ZeitDiff : TIME := t#0s; (* Zeit-Differenz *) END_VAR

Bsp. C.7. Beispiel für die Deklaration eines Hauptprogramms in AWL. Der FB ZFehBeh („Zentrale Fehler-Behandlung“) muss bereits vorhanden sein (wird fortgesetzt).

348

C AWL-Beispiele (* Beginn Anweisungsteil *)

LD ST ...

FALSE Fehler

LD t#0s ST ZeitDiff LD DatUhr.Q JMPC Weiter LD AktDatum SUB DatUhr.CDT ST ZeitDiff Weiter: ... LD Ress_Laeuft ST DatUhr.IN LD AktDatum ST DatUhr.PDT

(* Fehler ruecksetzen *) (* Dauer von Stromausfall bzw. Unterbrechung ermitteln *) (* Uhr „DatUhr“ ist batteriegepuffert *) (* Null Sekunden *) (* ruecksetzen *) (* Zeit gueltig = Uhr laeuft *) (* gueltig - nichts zu tun *) (* aktuelle Zeit abfragen *) (* letzte Zeit vor Stromausfall *) (* Zeitdauer Stromausfall *)

(* CPU laeuft *) (* Uhr laeuft, falls CPU laeuft *) (* Anfangswert Datum/Uhrzeit *) (* Anfangswert Uhr wird geladen, *) (* falls steigende Flanke an IN *) (* Starte Echtzeit-Uhr)

CAL DatUhr ... ... LD ZeitDiff LT t#50m JMPC MachtNichts NOT S Fehler LD 16#000300F2 ST F_Code MachtNichts: LD NotAus ST Flanke.CLK CAL Flanke LDN Flanke.Q AND T_Start ANDN Fehler AND FehlerBeh.Quitt ST ProgRun ....

(* Unterbrechungsdauer *) (* weniger als 50 Sekunden? *) (* Anlage noch warm genug... *) (* Fehler setzen *) (* Fehlerursache merken *) (* Not-Aus gedrueckt? *) (* Eingang Flankenerkennung *) (* Vergleich Eingang mit Flankenmerker *) (* Flanke an NotAus erkannt? *) (* UND Start-Flag gesetzt *) (* UND kein neuer Fehler *) (* Fehlerursache behoben *) (* Globale „laeuft“-Bedingung *) (* ...eigentliche Anweisungen, Aufrufe von FUN/FBs... *)

LD Fehler AND %IX250.2 R ProgRun LD ProgRun JMPNC Ende CALC FehlerBeh (Code := F_Code) LD FehlerBeh.Quitt Ende: LD ProgRun ST T_Stoerung RET END_PROGRAM

Bsp. C.7. (Fortsetzung)

(* Fehler aufgetreten? *) (* Globale Startbedingung ruecksetzen *) (* bei Fehler: starte Fehlerbehandlung *) (* FB mit zentraler Fehlerbehandlung *) (* Flag: Fehler wurde quittiert *) (* Programm laeuft nicht *) (* Ausgangsparameter setzen *) (* Ruecksprung bzw. Ende *)

C.3 Beispiel für PROGRAM

349

In diesem Programm wird weiterhin eine Flankenerkennung verwendet, um festzustellen, ob die NotAus-Taste betätigt wurde. Im globalen Datenbereich wird die Variable ProgRun deklariert, die auch allen unterhalb von HptProg aufgerufenen FBs zur Verfügung steht (dort als VAR_EXTERNAL). Mit ihr wird die Startbedingung verknüpft unter der Bedingung, dass kein NotAus gegeben wurde. Die FB-Instanz FehlerBeh kann die Bearbeitung eines aufgetretenen Fehlers mit Fehlercode F_Code übernehmen. Wenn der Fehler behoben und quittiert wurde, wird der entsprechende Ausgang Quitt auf TRUE gesetzt.

RESOURCE ZentralEinh_1 ON CPU_001 TASK Periodisch (INTERVAL := time#13ms, PRIORITY := 1); PROGRAM Applik WITH Periodisch : HptProg ( T_Start := %I250.0, T_Stoerung => %Q0.5); END_RESOURCE Bsp. C.8. Ressource-Definition mit Laufzeitprogramm Applik zu Bsp. C.7

Das Programm HptProg wird mit den Eigenschaften der periodischen Task Periodisch versehen und dadurch zum Laufzeitprogramm Applik der Ressource (SPS-CPU) ZentralEinh_1. Dieses Laufzeitprogramm läuft mit höchster Priorität (1) als zyklische Task mit einer maximalen Zykluszeit von 13 ms ab. HptProg wird mit dem Wert des Peripheriebits %I250.0 für die Eingangsvariable T_Start aufgerufen und setzt mit T_Stoerung das Ausgangsbit %Q0.5.

“This page left intentionally blank.”

D Standard-Datentypen

Dieser Anhang fasst sämtliche Elementaren Datentypen zusammen und charakterisiert tabellenartig ihre Eigenschaften. Ihre Verwendung wird in Kap. 3 erläutert. Die IEC 61131-3 definiert fünf Gruppen von Elementaren Datentypen, zu denen in Klammern der Allgemeine Datentyp angegeben wird (siehe Tab. 3.9): -

Bitfolge Ganzzahl mit und ohne Vorzeichen Gleitpunkt Datum, Zeitpunkt Zeichenfolge, Zeitdauer

(ANY_BIT), (ANY_INT), (ANY_REAL), (ANY_DATE), (ANYSTRING, TIME).

Zu jedem dieser Datentyp-Gruppen wird im folgenden eine Tabelle angegeben, die seine Eigenschaften charakterisiert: -

Name (Schlüsselwort), Stichworte (Kurzbeschreibung), Anzahl der Bits (Datenbreite), Werte-Bereich (unter Verwendung der IEC-Literale), Anfangswerte „initial“ (Standardwerte).

Die Datenbreite der Datentypen in Tab. D.5 und Tab. D.6 ist ebenso wie der zulässige Wertebereich implementierungsabhängig.

Datentyp BOOL BYTE WORD DWORD LWORD

Stichworte boolesch Bitfolge 8 Bitfolge 16 Bitfolge 32 Bitfolge 64

Bits 1 8 16 32 64

Tab. D.1. Datentypen „Binär und Bitfolge“

Bereich [0,1] [0,...,16#FF] [0,...,16#FFFF] [0,...,16#FFFF FFFF] [0,...,16#FFFF FFFF FFFF FFFF]

initial 0 0 0 0 0

352

D Standard-Datentypen

Datentyp SINT INT DINT LINT

Stichworte kurze Ganzzahl Ganzzahl Doppelte Ganzzahl Lange Ganzzahl

Bits 8 16 32 64

Bereich [-128,...,+127] [-32768,...,+32767] [-231,...,+ 231-1] [-263,...,+ 263-1]

initial 0 0 0 0

Tab. D.2. Datentypen „Ganzzahl mit Vorzeichen“

Datentyp USINT UINT UDINT ULINT

Stichworte kurze Ganzzahl Ganzzahl Doppelte Ganzzahl Lange Ganzzahl

Bits 8 16 32 64

Bereich [0,...,+255] [0,...,+65535] [0,...,+232-1] [0,...,+264-1]

initial 0 0 0 0

Tab. D.3. Datentypen „Ganzzahl ohne Vorzeichen“

Datentyp REAL LREAL

Stichworte Gleitpunktzahl lange Gleitpunktzahl

Bits 32 64

Bereich s. IEC 60559 s. IEC 60559

initial 0.0 0.0

Tab. D.4. Datentypen „Gleitpunktzahl“

Datentyp DATE TOD DT

Stichworte Datum Uhrzeit Datum mit Uhrzeit

initial d#0001-01-01 tod#00:00:00 dt#0001-01-01-00:00:00

Tab. D.5. Datentypen „Datum und Zeiten“

Anstelle der Bezeichnung TOD kann gleichwertig auch das Schlüsselwort TIME_OF_DAY, anstelle von DT auch DATE_AND_TIME benutzt werden. Datentyp TIME STRING WSTRING

Stichworte Zeitdauer Zeichenfolge (Einzelbytes) Zeichenfolge (Doppelbytes)

initial t#0s '' “““

Tab. D.6. Datentypen „Zeitdauer und Zeichenfolge“. Die Anfangswerte für STRING und WSTRING sind die „leeren“ Zeichenfolgen.

E Fehlerursachen

Die IEC 61131-3 fordert vom Hersteller eine Liste, in der er seine Fehlerreaktion zu den nachfolgenden Fehlersituationen beschreibt; siehe dazu auch Abschn. 7.9. Die Meldung erfolgt auf vier verschiedene Arten: 1) 2) 3) 4)

keinerlei Systemreaktion (%), als Warnung während der Programmerstellung (PeW), als Fehlermeldung während der Programmerstellung (PeF), Fehlermeldung und Fehlerreaktion während der Laufzeit (LzF).

Nr. 1 2 3 4 5 6 7 8 9 10 11

12 13

Fehlerursache Geschachtelter Kommentar Wert einer Aufzählungstyp ist mehrdeutig Wert einer Variablen übersteigt den festgelegten Bereich. Adressauflösung in der Konfiguration nicht vollständig („*“ Angabe) Schreibzugriff auf eine CONSTANT deklarierte Variable Variable ist als VAR_GLOBAL CONSTATNT deklariert und wird als VAR_EXTERNAL ohne CONSTATNT referenziert. Referenzierung einer Direkt dargestellten oder Externen Variablen in einer Funktion Unzulässige Zuweisung an eine VAR_IN_OUT Variable (z.B. einer Konstanten) Die Zuweisung an eine VAR_IN_OUT Variable ist nicht eindeutig Typ-Verletzung bei Konvertierung. Numerisches Ergebnis einer Standard-Funktion überschreitet den Wertebereich eines Datentyps; Division durch Null einer Standard-Funktion. Bitschiebefunktion mit negativer Shiftanzahl Unterschiedliche Eingangsdatentypen bei einer Auswahlfunktion (Std.-FUN); Selektor (K) ist außerhalb des Bereichs der MUX-Funktion.

Zeitpunkt PeF PeF LzF PeF PeF PeF PeF PeF PeF PeF LzF PeF, LzF LzF PeF LzF

Tab. E.1. Fehlerursachen; der Hersteller liefert eine Tabelle mit, in der die Systemreaktion auf oben beschriebene Fehlerfälle vermerkt ist. Der angegebene Zeitpunkt ist die gemäß IEC 61131-3 geeignete Stelle (wird fortgesetzt).

354

E Fehlerursachen

14 Zeichenfolge- Funktionen: PeW, LzF Ungültige Angabe einer Zeichenposition; PeW, LzF Ergebnis überschreitet die maximale Zeichenkettenlänge (INSERT/CONCAT Ergebnis ist zu lang). Ein ANY_INT Eingang ist negativ. LzF 15 Ergebnis überschreitet den Bereich des Datentyps „Zeit“. LzF 16 Die als Eingangsparameter übergebene FB-Instanz besitzt keine PeF Parameterwerte. 17 Ein VAR_IN_OUT Parameter besitzt keinen Wert. PeF PeF 18 Kein oder mehr als ein Anfangsschritt in einem AS-Netzwerk; Anwenderprogramm versucht, den Schritt-Merker oder -Zeit zu ändern. PeF 19 Seiteneffekte bei der Auswertung von Transitionsbedingungen. PeF 20 Fehler innerhalb des Aktionskontrollblocks. PeW, LzF 21 Auswahl einer AS Auswahlverzweigung besitzt mehrere erfüllte PeW, PeF Transitionen, ohne dass eine Priorisierung vorhanden ist. 22 Ein unsicheres oder nicht erreichbares AS- Netzwerk existiert. PeW 23 Typ-Konflikt bei VAR-ACCESS Variablen. PeF 24 Anforderungen einer Task bzgl. Prozessor-Ressourcen zu hoch; PeF Ausführungsende wurde nicht erreicht. PeW, LzF 25 Das numerische Ergebnis einer Operation überschreitet den DatenPeW, LzF typbereich (AWL). 26 Das Aktuelle Ergebnis und der Operandentyp stimmen nicht überein PeF (AWL). PeW,PeF,LzF 27 Division durch NULL (ST); PeF Ungültiger Datentyp einer Operation (ST). LzF Das numerische Ergebnis einer Operation überschreitet den Datentypbereich (ST). 28 Rücksprung einer Funktion ohne Funktionswert (ST). PeF 29 Iterationsschleife terminiert nicht (ST). PeW,PeF,LzF 30 Doppelter Bezeichner für Marke und Elementname (KOP / FBS). PeF 31 Nicht initialisierte Rückkopplungsvariable PeF

Tab. E.1. (Fortsetzung)

Diese Tabelle ist als Anhaltspunkt zu sehen. Es gibt weitere Fehlermöglichkeiten, die in der IEC-Tabelle nicht aufgeführt sind. Aus diesem Grund sollte sie von jedem Hersteller in geeigneter Form erweitert werden.

F Implementierungsabhängige Parameter

Tab. F.1 gibt die implementierungsabhängigen Parameter wieder, die durch die IEC 61131-3 benannt werden; siehe auch Abschn. 7.10.

Nr. 1 2 3 4 5

6

7 8

Implementierungsabhängige Parameter Maximale Zeichenanzahl von Bezeichnern. Maximale Länge eines Kommentars (ohne führende/schließende Klammerzeichen). Syntax und Semantik von Pragmas Syntax und Semantik für “, wenn keine Doppelbytestrings damit deklariert werden Wertebereich und Genauigkeit von Variablen des Datentyps TIME (z.B. 0<=TIME_VAR<1000 Tage), DATE, TIME_OF_DAY und DATE_AND_TIME Genauigkeit der Sekundenangaben bei Datentypen TIME_OF_DAY und DATE_AND_TIME. Maximale - Anzahl von Elementen in einem Aufzählungs- Datentyp, - Anzahl von Elementen in einem Feld (wie viele Datenelemente), - Feldgröße (wie viele Bytes kann ein Array max. besitzen), - Anzahl von Elementen in einer Struktur, - Strukturgröße (wie viele Bytes kann eine Struktur max. besitzen), - Anzahl von Variablen pro Deklaration, die (durch Komma getrennt) mit einem Datentyp deklariert werden können, - Anzahl der Schachtelungstiefe von Strukturen. Maximale Standardlänge von String- und WString Variablen; Maximale Länge von String- und WString Variablen. Anzahl der Hierarchie-Ebenen bei direkten Variablen (%QX1.1.1.2...); Abbildung der Namen (%IX....) auf die reale Hardware.

Tab. F.1. Implementierungsabhängige Parameter, die jeder Hersteller eines IEC 61131-3 Systems beschreiben muss. Die Gliederung in einzelne Gruppen bezieht sich auf einzelne Abschnitte in der Norm. Werden keine konkreten Zahlen gefordert, kann der Hersteller eine informelle Beschreibung beifügen (wird fortgesetzt).

356

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

33 34

F Implementierungsabhängige Parameter

Initialisierungswert der Eingänge (%IX...) beim Systemstart. Maximale Anzahl von Variablen pro Deklarationsblock Verhalten eines AT- Bezeichners als Teil einer FB-Instanz- Deklaration Verhalten beim Warmstart, wenn die Variable weder mit RETAIN oder NON_RETAIN deklariert wurde Information zur Bestimmung der Ausführungszeiten von POEs (es sind keine näheren Angaben in der IEC 61131-3 vermerkt). Werte der Baustein- Ausgänge, wenn der Baustein mit ENO=FALSE beendet wurde (Zuweisung ja/ Nein) Max. Anzahl möglicher Anwenderfunktionen (soweit Begrenzung vorhanden). Max. Anzahl von Eingängen bei erweiterbaren Funktionen. Genauigkeit der einzelnen Typ-Umwandlungsfunktionen (REAL_TO_INT,...) sowie implementierte Fehlerbehandlung Genauigkeit der numerischen Funktionen Ergebnis von Typkonvertierungen zwischen Zeit- Datentypen und den restlichen Datentypen Maximale Anzahl von Anwender-Funktionsbausteinen und möglichen Instanzen (soweit Begrenzung vorhanden). Zuweisungsverhalten von Baustein Eingängen, wenn EN= FALSE (Zuweisung ja/ Nein) Wertebereich des Parameters PV (Endewert bei Standard-Zählerbausteinen). Reaktion des Systems auf eine Änderung des PT-Eingangs (Endewert bei StandardZeitbausteinen) während einer laufenden Zeitoperation . Maximale Länge von Programmen (ausführbarer Code). Zeitauflösung der Variablen Schritt-Zeit. Maximale Anzahl von Schritten pro AS-Netzwerk. Maximale Anzahl von Transitionen pro AS-Netzwerk und pro Schritt. Maximale Anzahl von Aktionsblocks pro Schritt. Funktionsweise der Aktions-Steuerung (ACTION-CONTROL Baustein soweit vorhanden) und Zugriffsmöglichkeit auf Werte des Q- und A-Ausgangs Minimale Transitionsschaltzeit (verursacht durch Berechnungszeit der SPS), Maximale Anzahl von Vorgänger und Nachfolger Schritten (bei Simultan- / Alternativ Verzweigungen). Beschreibung der Ressource-Bibliothek. Jede Verarbeitungseinheit (z.B. Prozessortyp) erhält eine Beschreibung aller Funktionen (Std-FBs, Std.Funktionen, Datentypen, ....), die von dieser Ressource verarbeitet werden können. Wirkung der Verwendung des READ_WRITE Zugriffs auf FB Ausgänge Maximale Anzahl von Tasks / Ressource; Task Intervall Auflösung (Zeitbereich möglicher Aufrufe für periodische Tasks); Art der Task-Steuerung (mit / ohne Pre-emptive Scheduling).

Tab. F.1. (Fortsetzung)

F Implementierungsabhängige Parameter 35 36 37 38 39 40

357

Maximallänge von ST Ausdrücken (Anzahl von Operanden, Operatoren). Maximallängen von ST Anweisungen (IF; CASE; FOR; ...), Einschränkungen. Maximale Anzahl von möglichen CASE Alternativen. Wert der Laufvariablen von FOR-Schleifen nach Verlassen der Schleife. Einschränkungen bzgl. der Netzwerktopologie bei KOP /FBS. Auswertungsreihenfolge von Rückkopplungsschleifen.

Tab. F.1. (Fortsetzung)

Darüber hinaus gibt es eine Vielzahl weiterer Parameter, die bei der Implementierung eines Programmiersystems nach IEC 61131-3 zu beachten sind. Aus dieser Menge stellt die Tab. F.2 eine subjektive Auswahl zusammen.

Nr. Implementierungsabhängige Parameter 1 Umfang der syntaktischen und semantischen Überprüfung, die von den textuellen und grafischen Editoren angeboten wird (bereits während der Eingabe). 2 Beschreibung der Ausführungsreihenfolge von Netzwerken. 3 Freie Platzierung von grafischen Elementen bei Editoren mit Linien-Aktualisierung („Gummiband“) oder automatische Platzierung nach syntaktischen Regeln. 4 Deklaration und Verwendung Direkt dargestellter Variablen (DdV): - Die Deklaration erfolgt immer mit symbolischem Namen; im Anweisungsteil darf nur das Symbol oder beide (Symbol; direkte Adresse) verwendet werden oder - DdV können auch ohne symbolische Namen deklariert werden (Verwendung nur der direkten Adresse) oder - DdV werden vom Programmiersystem implizit deklariert. 5 Reihenfolge der VAR_*...VAR_END Blöcke, sowie Mehrfachverwendung gleichnamiger Blöcke. 6 Realisierte Funktions-Aufrufmöglichkeiten (mit / ohne Formal-Parameter) in ST. 7 Umfang der Realisierung der EN/ENO Parameter in KOP und FBS, sowie mögliche Auswirkungen auf AWL/ST-Quellen. 8 Möglichkeit der Übergabe von benutzerdefinierten Strukturen (TYPE) als Funktions- und FB-Parameter (derzeit nicht in der Norm festgelegt). 9 Bekanntmachung von Anwender definierten Datentypen (TYPE...END_TYPE): global- und POE-weit (derzeit nicht in der Norm festgelegt). 10 Umfang der Datenbereichsüberprüfung bei der Programm-Erstellung und während der Laufzeit. 11 Grafische Darstellung der Bestimmungszeichen/Attribute bei der Variablendeklaration. Tab. F.2. Weitere implementierungsabhängige Parameter (nicht Teil der IEC 61131-3) (wird fortgesetzt)

358

F Implementierungsabhängige Parameter

12 Umfang der Datenbereichsüberprüfung bei der Programm-Erstellung und während der Laufzeit. 13 Einschränkung in der Verwendung komplexer Datentypen (Funktionstyp auch für Typ „String“ oder anwenderdefinierte Typen zugelassen, ...?). 14 Algorithmus zur Auswertung von KOP/FBS-Netzwerken (siehe Abschn. 4.3.4 und 7.3.1). 15 Hilfen zur Nachvollziehbarkeit der Querübersetzung (soweit vorhanden). ... Tab. F.2. (Fortsetzung)

Die IEC 61131-3 erlaubt Funktionalitäten, die über den Standard hinausgehen. Sie müssen allerdings beschrieben sein. Einige davon wurden für Tab. F.3 zusammengestellt.

Nr. Erweiterungen 1 Ausdehnung der Wertebereichsüberprüfung auf mehrere Datentypen (z.B. ANY_NUM) als nur Integer (ANY_INT). 2 FB-Instanzen als Feld-Variable zulassen. 3 FB-Instanzen in Strukturen erlauben. 4 Überladen auch für benutzerdefinierte Funktionen, FBs, und Programme. 5 Zeitpunkt der Berechnung der Schrittweite bei FOR-Anweisungen. 6 Möglichkeit der Verwendung von Präprozessor-Anweisungen für Literale, Makros, bedingte Übersetzung, Include-Anweisungen (zum Einlesen von Dateien mit FBSchnittstelleninformation, mit der Liste der verwendeten Direkt darstellbaren Variablen oder EXTERNAL-Deklarationen, ...). 7 Verwendung unterschiedlicher Speichermodelle in der SPS (Small; Compact; ...). ... Tab. F.3. Mögliche Erweiterungen (nicht Teil der IEC 61131-3)

G Beispiel einer AWL-Syntax

Viele der in diesem Buch aufgeführten Beispiele sind in Anweisungsliste (AWL) formuliert. Diese Programmiersprache ist weit verbreitet und wird von den meisten Programmiersystemen unterstützt. Durch die Möglichkeit, Datentypen verwenden zu können, die meist nur in Hochsprachen zu finden waren wie Felder oder Strukturen, ergeben sich mit der IEC 61131-3 gegenüber herkömmlichem AWL neue Möglichkeiten. Die nachfolgend beschriebene AWL-Syntax wird mit Hilfe von Syntaxgraphen in vereinfachter Form wiedergegeben. Syntaxgraphen erläutern die zulässige Verwendung von Begrenzungszeichen, Schlüsselworten, Literalen und Bezeichnern auf anschauliche Weise. Sie können zur Entwicklung von Compilern leicht in eine textuelle Form gebracht werden und definieren so den formalen Aufbau einer Programmiersprache (Syntax einer Sprache). Der Anwender kann sich ihrer bedienen, um nachzuschlagen, wie die von ihm zu programmierenden Sprachkonstrukte aufzubauen sind. Die Syntaxbeschreibung dieses Kapitels geht über die IEC 61131-3 hinaus, da zusätzlich zu der reinen Syntaxbeschreibung semantische Bedingungen (Folgerichtiger Gebrauch des Aktuellen Ergebnisses, Verwendung von Funktionsparametern,...) mit eingearbeitet sind; die IEC 61131-3 bietet hierfür lediglich eine informelle Beschreibung. Die Regeln sind im Abschn. G.1 zu finden. Die Verwendung dieser Graphen wird im Abschn. G.2 anhand eines Beispiels erklärt.

360

G Beispiel einer AWL-Syntax

G.1 Syntaxgraphen für AWL Gibt es für einen Knoten des Syntaxgraphen eine weitere Untergliederung (Untergraphen), ist der Name dieses Knoten kursiv geschrieben. Schlüsselwörter oder terminale Symbole, die nicht weiter ersetzt werden, besitzen Normalschrift. Die Verwendung von Kommentaren wurde aus Gründen der Übersichtlichkeit weggelassen. Kommentar ist seit der Ausgabe 2 der Norm an jeder Stelle erlaubt, an der auch ein Leerzeichen (außer Zeichenketten) stehen kann. Ein Kommentar beginnt mit „(*“,endet mit „*)“ und enthält dazwischen beliebig viele alphanumerische Zeichen ohne EOL. Kommentare können nicht geschachtelt werden.

AWL-Anweisungssequenz: EOLs Lade-Anweisung Sprungmarke

BedAnw

Unbedingter FB-Aufruf Unbedingter Sprung Unbedingter Rücksprung

BedAnw:

AnwMitKl

Zuweisung

AnwOhneKl

S/R-Anweisung

FUN-Aufruf

Bedingter FB-Aufruf Bedingter Sprung Bedingter Rücksprung

Abb. G.1. Syntaxgraphen einer AWL-Anweisungs-Sequenz mit den Unterelementen „Bedingte Anweisung“ und „Sprungmarke“ (wird fortgesetzt)

G.1 Syntaxgraphen für AWL

361

Sprungmarke:

Markenname

: EOLs

Abb. G.1. (Fortsetzung)

Eine AWL-Anweisungs-Sequenz beginnt optional mit einer Sprungmarke; es schließt sich entweder eine Lade-Anweisung, gefolgt von einer oder mehreren bedingten Anweisungen BedAnw, eine unbedingte Anweisung mit FB-Aufruf, Sprung oder Rücksprung an; siehe dazu den Syntaxgraphen der Abb. G.1. Die Bedingte Anweisung beginnt mit einer Folge von Anweisungen mit und ohne Klammern bzw. Funktionsaufrufen. Daran schließt sich eine Folge von (S/R-) Zuweisungen, bedingten Aufrufen oder Sprüngen an. Die Sprungmarke besteht aus einer Marken-Bezeichnung, gefolgt von einem Doppelpunkt. Sie steht entweder unmittelbar vor der ersten Anweisung der Folge oder wird von EOLs (engl.: end-of-line) gefolgt. Es folgen die Syntaxgraphen für Anweisungen, Aufrufe und Sprünge.

AnwOhneKl: Operator

Operand

EOLs

Abb. G.2. Syntaxgraph einer Anweisung ohne Klammer

Eine Anweisung ohne Klammer (Abb. G.2) besteht aus einem AWL-Operator mit einem Operanden und dem Zeilenabschluss durch EOLs.

362

G Beispiel einer AWL-Syntax

EOLs

AnwMitKl: Operator

LD

(

Operand

AnwInKl

)

EOLs

EOLs

AnwInKl:

AnwMitKl AnwOhneKl FUN-Aufruf Zuweisung S/R-Anweisung Abb. G.3. Syntaxgraphen einer Anweisung mit Klammer

Die in Abb. G.3 gezeigten Syntaxgraphen zeigen den Aufbau einer Anweisung mit Klammer. Diese Anweisungsart beginnt mit einem die Klammerung einleitenden Operator mit Operanden als erste Anweisung. Darauf folgen beliebig viele Anweisungen AnwInKl innerhalb der Klammer, die mit einer schließenden Klammer und EOLs abgeschlossen wird. Diese inneren Anweisungen können wiederum Klammern einschließen (Schachtelung) sowie FUN-Aufrufe und Zuweisungen besitzen.

G.1 Syntaxgraphen für AWL

363

FUN-Aufruf mit Aktualparameter: FUN-Name

EOLs , Operand

FUN-Aufruf mit Formalparameter: FUN-Name

Formalparameter

EOLs

Abb. G.4. Syntaxgraph für den Aufruf einer Funktion

Formalparameter:

(

EOL ,

ParAufruf

EOL ,

)

ParAufruf: EOL ,

,

FormPar

:=

AktPar

=> Abb. G.5. Formale Parameterübergabe

Wie Abb. G.4 zeigt, besteht der Aufruf einer Funktion aus der Angabe des Funktionsnamens sowie einer Anzahl durch Kommata getrennter Operanden als Aktualparameter dieser Funktion. Eine Funktion kann auch wie ein Funktionsbaustein mit Formalparametern aufgerufen werden.

364

G Beispiel einer AWL-Syntax

FB-Aufruf mit Aktualparameter: CAL

FB-Name

EOLs , Operand

Unbedingter FB-Aufruf: CAL

FB-Name

Formalparameter

EOLs

FB-Name

Formalparameter

EOLs

Bedingter FB-Aufruf: CALC CALCN Abb. G.6. Syntaxgraphen für den Aufruf eines Funktionsbausteins

Die Syntaxgraphen für bedingten und unbedingten Aufruf eines Funktionsbausteins zeigt Abb. G.6. Der Aufruf wird beim unbedingten Aufruf mit CAL, beim bedingten mit CALC bzw. CALCN begonnen. Darauf folgen der Name der FB-Instanz sowie in Klammern die Parameter des FB. Die Übergabe eines Aktualparameters an einen Formalparameter wird durch eine Zuweisung mit „:=“ dargestellt. Solche Zuweisungen sind für jeden Parameter erforderlich und werden durch Kommata und Zeilenwechsel getrennt.

G.1 Syntaxgraphen für AWL

365

FB- Aufruf Methode 3 S

FB-Name

S1 R R1 CLK CU PV CD IN PT Abb. G.7. FB Aufruf mit Methode 3

Bei der in Abb. G.7 gezeigten Syntax ist darauf zu achten, dass dieser Aufruf je nach Parameter nur eine Parameterinitialisierung oder die Ausführung des FBs bewirkt.

Unbedingter Sprung: JMP

Markenname

EOLs

Markenname

EOLs

Bedingter Sprung: JMPC

JMPCN Abb. G.8. Syntaxgraphen für Bedingten und Unbedingten Sprung

366

G Beispiel einer AWL-Syntax

Bei Sprüngen wird hinter dem Sprung-Operator JMP (unbedingt) bzw. JMPC oder JMPCN (bedingt) der Name der Sprungmarke angegeben (Abb. G.8).

Unbedingter Rücksprung: RET

EOLs

Bedingter Rücksprung: RETC

EOLs

RETCN Abb. G.9. Syntaxgraphen für Bedingten und Unbedingten Rücksprung

Die in Abb. G.9 gezeigten Rücksprünge besitzen keine Operanden bzw. Parameter.

Lade-Anweisung: LD

Operand

EOLs

LDN Abb. G.10. Syntaxgraph für die Lade-Anweisung

Die Lade-Anweisung der Abb. G.10 besitzt einen einzelnen (invertierbaren) Operanden. Sie kann nicht mit einer Klammer kombiniert werden oder innerhalb einer Klammerung verwendet werden.

G.1 Syntaxgraphen für AWL

367

Zuweisung: ST

Operand

EOLs

STN Abb. G.11. Zuweisung

Zuweisungen (Abb. G.11) bestehen aus dem Operator ST bzw. STN und der Angabe des zu speichernden Operanden.

S/R-Anweisung:

S

Operand

EOLs

R Abb. G.12. S/R-Anweisung

Eine S/R-Anweisung (Abb. G.12) besteht aus den AWL-Operatoren S oder R und einem Operanden.

Operator: N-Erw. Operator

Erw. Operator Abb. G.13. Operator als Zusammenfassung der Erweiterbaren und Nicht-Erweiterbaren Operatoren

Die in Abb. G.13 dargestellten Operatoren besitzen eine verknüpfende Funktion, dienen also nicht zum Laden oder Speichern. Es wird dabei zwischen Erweiterbaren und Nicht-Erweiterbaren Operatoren unterschieden, die im Folgenden dargestellt werden.

368

G Beispiel einer AWL-Syntax

Erw. Operator: AND ANDN & &N OR ORN XOR XORN ADD MUL Abb. G.14. Erweiterbare Operatoren: Bitweise Operationen sowie Addition und Multiplikation

Die Erweiterbaren Operatoren zeigt Abb. G.14. Sie können mehr als zwei Eingangsparameter besitzen. Die bitweise booleschen Operatoren (StandardFunktionen) können optional mit Invertierung verwendet werden.

G.1 Syntaxgraphen für AWL

369

N-Erw. Operator: GT GE LT LE EQ NE SUB DIV MOD NOT Abb. G.15. Nicht-Erweiterbare Operatoren: Vergleichen, Subtraktion, Division

Die Nicht-Erweiterbaren Operatoren in Abb. G.15 haben (einschließlich AE) genau zwei Eingangsparameter.

EOLs: EOL

Abb. G.16. Syntaxgraph für das Zeilenende (engl.: end of line) einer AWL-Anweisung

Eine AWL-Zeile wird mit einem einzelnen EOL-Zeichen (z.B. Carriage Return / Line Feed), dem oft ein erklärender Zeilen-Kommentar vorangestellt ist, abgeschlossen (Abb. G.16). Diese Elemente können einmal oder beliebig oft hintereinander vorkommen.

370

G Beispiel einer AWL-Syntax

AktPar:

Operand: Operand

VarBez LITERAL

Markenname: FUN-Name: FB-Name: FormPar:

VarBez:

VarBez

IDENTIFIER

Abb. G.17. Operanden, Parameter und Bezeichner werden durch Identifier bzw. Literale gebildet.

Abb. G.17 zeigt die Abbildung von Parametern, Operand und verschiedenen Bezeichnertypen auf Bezeichner (IDENTIFIER) und Werte (LITERAL). Zur Vereinfachung werden hier die Syntaxgraphen der Bezeichner und Literale nicht dargestellt. Ihre prinzipielle Darstellung ist in Abschn. 3.2 erläutert.

G.2 AWL-Beispiel zu Syntaxgraphen Zu den soeben dargestellten AWL-Syntaxgraphen wird nun ein Beispiel gegeben. Dieses zeigt, wie aus Syntaxgraphen Programmbeispiele konstruiert werden und umgekehrt, wie nämlich AWL-Beispiele auf ihre Richtigkeit hin überprüft werden können.

G.2 AWL-Beispiel zu Syntaxgraphen

0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012 0013 0014

SequenzEins: LD

Var1

ANDN ORN AND ) AND ST S RETC

Var2 ( Var3 Var4

371

Beginn der AWL-Sequenz (* Sprungmarke *) (* Einfache Verknüpfung mit Sprung *) (* Lade-Anweisung *) (* Beginn bedingte Anweisungen *) (* Anweisung ohne Klammer *) (* Anweisung mit Klammer *) (* Ende der Klammerung *)

Var5 Var6 Var7

(* Zuweisung *) (* S/R-Anweisung *) (* Bedingter Rücksprung *) (* Ende der bedingten Anweisungen *) (* Ende der AWL-Sequenz *)

Bsp. G.1. AWL-Beispiel. Die Kommentare weisen auf den entsprechenden Syntaxgraphen hin. Die links stehenden Zeilennummern dienen der Referenzierung in Tab. G.1.

Um zu sehen, wie sich das AWL-Beispiel in Bsp. G.1 aus den Syntaxgraphen des Abschn. G.1 aufbauen lässt, werden in Tab. G.1 zu jeder AWL-Zeile die anzuwendenden Syntaxgraphen angegeben.

Zeile in Bsp. G.1 0001-0014 0001-0002 0003-0004 0005 0005 0006-0008 0006,0007 0007,0009 0007,0009 0010 0011 0012-0014

Syntaxgraph AWL-Anweisungs-Sequenz Sprungmarke Lade-Anweisung Anweisung ohne Klammer Erweit. Operator ANDN Anweisung mit Klammer Erweit. Operatoren ORN, AND Anweisung ohne Klammer Erweit. Operator AND Zuweisung S/R-Anweisung Bedingter Rücksprung

Abbildung Abb. G.1 Abb. G.1 Abb. G.10 Abb. G.2 Abb. G.14 Abb. G.3 Abb. G.14 Abb. G.2 Abb. G.14 Abb. G.11 Abb. G.12 Abb. G.9

Tab. G.1. Anzuwendende Syntaxgraphen zu Zeilen der AWL-Sequenz in Bsp. G.1

Dieses Beispiel zeigt, wie sich durch mehrfache Anwendung der Syntaxgraphen ein konkretes AWL-Programm ergibt: Im Syntaxgraphen für eine AWLAnweisungs-Sequenz (Abb. G.1) wird zunächst die Sprungmarke mit Bezeichner, Doppelpunkt und Kommentaren eingesetzt, gefolgt von der ersten (Lade-) Anweisung.

372

G Beispiel einer AWL-Syntax

Der Teil „bedingte Anweisungen“ ergibt sich aus zwei Anweisungen, von denen die erste mit Klammer wiederum einige Anweisungen in Klammern enthält. Nach den bedingten Anweisungen wird die Sequenz mit Zuweisungen und Rücksprung abgeschlossen. Auf diese Weise ist es möglich, aus den einzelnen Syntaxgraphen zulässige AWLSequenzen zu erzeugen. Ebenso können umgekehrt zu AWL-Zeilen die erforderlichen Syntaxgraphen gefunden werden, um festzustellen, ob ein Programmstück syntaktisch korrekt ist.

H Reservierte Schlüsselworte und Begrenzungszeichen

Es wird von der IEC 61131-3 ausdrücklich zugelassen, dass Schlüsselworte und Begrenzungszeichen durch Übersetzungstabellen an nationale Zeichensätze angepasst werden können.

H.1 Reservierte Schlüsselworte In Tab. H.1 sind sämtliche Reservierten Schlüsselworte für Programmiersprachen der IEC 61131-3 in alphabetischer Reihenfolge aufgelistet. Sie dürfen nicht als Namen für benutzter-definierte Elemente verwendet werden. In dieser Aufzählung wurden zusätzlich zur Norm auch sämtliche Formalparameter von FUN bzw. FB sowie Datentypen mit aufgenommen, um Verwechselungen zu vermeiden.

A

ABS

ACOS

ACTION

ADD

AND

ANDN

ANY

ANY_BIT

ANY_DATE

ANY_DERIVED

ANY_ELEMENTARY

ANY_INT

ANY_MAGNITUDE

ANY_NUM

ANY_REAL

ARRAY

ASIN

AT

ATAN

B

BOOL

BY

BYTE

Tab. H.1. Reservierte Schlüsselworte der IEC 61131-3 (wird fortgesetzt)

374

C

D

E

H Reservierte Schlüsselworte und Begrenzungszeichen

CAL

CALC

CALCN

CASE

CD

CDT

CLK

CONCAT

CONFIGURATION

CONSTANT

COS

CTD

CTU

CTUD

CU

CV

D

DATE

DATE_AND_TIME

DELETE

DINT

DIV

DO

DS

DT

DWORD

ELSE

ELSIF

END_ACTION

END_CASE

END_CONFIGURATION

END_FOR

END_FUNCTION

END_FUNCTION_BLOCK

END_IF

END_PROGRAM

END_REPEAT

END_RESOURCE

END_STEP

END_STRUCT

END_TRANSITION

END_TYPE

END_VAR

END_WHILE

EN

ENO

EQ

ET

EXIT

EXP

EXPT

F

G I

FALSE

F_EDGE

F_TRIG

FIND

FOR

FROM

FUNCTION

FUNCTION_BLOCK

GE

GT

IF

IN

INITIAL_STEP

INSERT

INT

INTERVAL

Tab. H.1. (Fortsetzung)

H.1 Reservierte Schlüsselworte

J

JMP

JMPC

JMPCN

L

L

LD

LDN

LE

LEFT

LEN

LIMIT

LINT

LN

LOG

LREAL

LT

LWORD

M

MAX

MID

MIN

MOD

MOVE

MUL

MUX

N

N

NE

NEG

NON_RETAIN

NOT

O P

OF

ON

OR

ORN

P

PRIORITY

PROGRAM

PT

PV

Q R

Q

Q1

QU

QD

R

R1

R_EDGE

R_TRIG

READ_ONLY

READ_WRITE

REAL

RELEASE

REPEAT

REPLACE

RESOURCE

RET

RETAIN

RETC

RETCN

RETURN

RIGHT

ROL

ROR

RS

Tab. H.1. (Fortsetzung)

375

376

S

H Reservierte Schlüsselworte und Begrenzungszeichen

S

S1

SD

SEL

SEMA

SHL

SHR

SIN

SINGLE

SINT

SL

SQRT

SR

ST

STEP

STN

STRING

STRUCT

SUB

T

U

V

W X

T

TAN

TASK

THEN

TIME

TIME_OF_DAY

TO

TOD

TOF

TON

TP TRUE

TRANSITION TYPE

UDINT

UINT

ULINT

UNTIL

USINT

VAR

VAR_ACCESS

VAR_CONFIG

VAR_EXTERNAL

VAR_GLOBAL

VAR_INPUT

VAR_IN_OUT

VAR_OUTPUT

VAR_TEMP

WHILE

WITH

WORD

WSTRING

XOR

XORN

Tab. H.1. (Fortsetzung)

H.2 Begrenzungszeichen

377

H.2 Begrenzungszeichen Begrenzungszeichen stellen „Sonderzeichen“ in der Syntax der Programmiersprachen dar und besitzen je nach Verwendung unterschiedliche Bedeutung. So können runde Klammern beispielsweise zur Kennzeichnung von Anfang und Ende einer Aktualparameterliste bei einem Funktionsaufruf oder zusammen mit dem Stern zur Begrenzung von Kommentaren benutzt werden. Sämtliche Begrenzungszeichen und deren Kombinationen werden in Tab. H.2 mit ihren möglichen Bedeutungen aufgeführt. Zeichen zur grafischen Darstellung der Linienführung werden hier nicht berücksichtigt.

Begrenzungszeichen Leerzeichen

Zeilenende

Kommentaranfang Kommentarende Plus

(* *) +

Minus

-

Nummernkreuz

#

Bedeutung, Erläuterungen können überall eingefügt werden - außer innerhalb Schlüsselworten, Literalen, Bezeichnern, Direkt dargestellten Variablen oder Kombinationen von Begrenzungszeichen (wie „(*“ oder „*)“). Über Tabulatoren (TABs) macht die IEC 61131-3 keine Aussage, sie werden üblicherweise wie Leerzeichen behandelt. zum Abschluss einer Anweisungszeile in AWL, in ST auch innerhalb Anweisungen zulässig. Nicht zulässig innerhalb AWL-Kommentaren. (engl. EOL end of line), üblicherweise durch CR&LF (engl.: carriage return & Line feed) implementiert. Beginn eines Kommentars (nicht schachtelbar) Ende eines Kommentars 1. Führendes Vorzeichen eines Dezimal-Literals, auch im Exponenten eines Gleitpunkt-Literals 2. Additionsoperator in Ausdrücken 1. Führendes Vorzeichen eines Dezimal-Literals, auch im Exponenten eines Gleitpunkt-Literals 2. Subtraktionsoperator in Ausdrücken 3. Negationsoperator in Ausdrücken 4. Jahr-Monat-Tag-Trennzeichen in Zeitliteralen 1. Basiszahl-Trennzeichen in Literalen 2. Zeitliteral-Trennzeichen

Tab. H.2. Begrenzungszeichen der IEC 61131-3 (wird fortgesetzt)

378

H Reservierte Schlüsselworte und Begrenzungszeichen

Begrenzungszeichen Punkt

.

e, E Anführungszeichen ' Dollar-Zeichen $ Präfix Zeitliterale t#, T# d#, D# d, D h, H m, M s, S ms, MS date#, DATE# time#, TIME# time_of_day# TIME_OF_DAY# tod#, TOD# date_and_time# DATE_AND_TIME# dt#, DT# Doppelpunkt :

Zuweisung

Tab. H.2. (Fortsetzung)

:=

Bedeutung, Erläuterungen 1. Ganzzahl/Bruch-Trennzeichen 2. Trennzeichen innerhalb Hierarchischer Adressen von Direkt dargestellten und Symbolischen Variablen 3. Trennzeichen zwischen Komponenten einer Datenstruktur (beim Zugriff) 4. Trennzeichen für Komponenten einer FB-Instanz (beim Zugriff) führendes Zeichen für Exponenten der GleitpunktLiterale Anfang und Ende von Zeichenfolgen Anfang von Sonderzeichen innerhalb Zeichenfolgen Einleitende Zeichen von Zeitliteralen, Kombinationen von Klein- und Großbuchstaben sind ebenfalls zulässig.

Trennzeichen für: 1. Uhrzeit innerhalb Zeitliterale 2. Festlegung des Datentyps bei Variablendeklaration 3. Festlegung eines Datentyp-Namens 4. Schrittnamen 5. PROGRAM...WITH... 6. Funktionsname/Datentyp 7. Zugriffspfad: Name/Typ 8. Sprungmarke vor nächster Anweisung 9. Netzwerkname (Marke) vor nächster Anweisung 1. Operator für Anfangswert-Zuweisung 2. Eingangsverbindungs-Operator (Zuweisung von Aktualparameter an Formalparameter beim POEAufruf) 3. Anweisungsoperator

H.2 Begrenzungszeichen

Begrenzungszeichen Runde Klammerung (...)

Eckige Klammern

[...]

Komma

,

Semikolon

;

Punkt-Punkt

..

Prozent

%

Zuweisung2

=>

Vergleich

>, < >=, <=, =, <>, Exponent ** Multiplikation * Division / Kaufmanns-UND & Tab. H.2. (Fortsetzung)

379

Bedeutung, Erläuterungen Anfang und Ende für: 1. Aufzählungsliste 2. Anfangswert-Liste, auch: Mehrfache Anfangswerte (mit Wiederholungszahl) 3. Bereichsangabe 4. Feldindex 5. Folgenlänge 6. Operator in AWL (Berechnungsebene) 7. Parameterliste beim POE-Aufruf 8. 6. Unterausdruck-Hierarchie Anfang und Ende für: 1. Feldindex (Zugriff auf ein Feldelement) 2. Zeichenfolgenlänge (bei Deklaration) Trennzeichen für: 1. Aufzählungsliste 2. Anfangswert-Liste 3. Feldindex (mehrdimensional) 4. Variablennamen (bei Mehrfachdeklaration desselben Datentyps) 5. Parameterliste beim POE-Aufruf 6. Operandenliste in AWL 7. CASE-Werteliste Abschluss von: 1. Definition eines (Daten)-Typs 2. Deklaration (z.B. Variablen) 3. ST-Anweisung Trennzeichen für: 1. Bereichsangabe 2. CASE-Bereich Einleitendes Zeichen für Hierarchische Adressen bei Direkt dargestellten und Symbolischen Variablen Ausgangsverbindungs-Operator (Zuweisung von Formalparameter an Aktualparameter beim PROGRAM-Aufruf) Vergleichsoperatoren in Ausdrücken

als Operator in Ausdrücken Multiplikations-Operator in Ausdrücken Divisions-Operator in Ausdrücken AND-Operator in Ausdrücken

“This page left intentionally blank.”

I Glossar

Im Folgenden werden wichtige Begriffe und Abkürzungen erläutert, die in diesem Buch verwendet werden. Sie werden in alphabetischer Reihenfolge aufgeführt. Begriffe, die durch die IEC 61131-3 festgelegt sind, sind entsprechend mit „IEC“ gekennzeichnet.

Abgeleiteter Datentyp

IEC

Mit Hilfe einer Typdefinition wird ein benutzerspezifischer Datentyp erzeugt, dessen Elemente aus Elementaren und/oder wiederum Abgeleiteten Datentypen bestehen.

Ablaufsprache

IEC

Ablaufsprache AS (engl.: Sequential Function Chart – SFC) ist eine Programmiersprache zur Beschreibung sequentieller und paralleler Steuerungsabläufe mit Zeit- und Ereignis-Steuerung. Abk. für Aktuelles Ergebnis

AE Aktion

IEC

Boolesche Variable oder eine Reihe von Anweisungen, die über einen Aktionsblock angesteuert werden können, in AS.

Aktionsblock

IEC

Aktivierungsbeschreibung von Aktionen in AS

Aktionskontrollblock

IEC

Steuereinheit für jede Aktion in AS, die über Aktionsblöcke die Eingangsbedingung für die zugeordnete Aktionsfreischaltung erhält. Versorgung einer Eingangsvariablen (Formalparameter) einer POE mit einem aktuellen Wert.

Aktualparameter Aktuelles Ergebnis

IEC

Zwischenergebnis in AWL von beliebigem Datentyp

Allgemeiner Datentyp

IEC

Zusammenfassung von Elementaren Datentypen zu Gruppen, um Überladen von Funktionen beschreiben zu können; wird auch „Generischer Datentyp“ genannt.

Anfangswert

Wert einer Variable, der bei ihrer Initialisierung vergeben wird.

382

I Glossar

Anweisungsliste

IEC

Anweisungsliste (engl.: Instruction List – IL) ist eine weit verbreitete Assembler-ähnliche Programmiersprache für SPS-Systeme.

AS

IEC

Abk. für Ablaufsprache Besonderer Datentyp zur Definition textueller Sequenzen als Wertebereich. Intern zumeist als ganzzahlige Werte realisiert.

Aufzählung

AWL

IEC

Abk. für Anweisungsliste

Batteriepufferung

Fähigkeit einer SPS, bestimmte Datenbereiche bei Stromausfall gegen Verlust zu sichern. Die IEC 61131-3 verwendet dazu das Schlüsselwort RETAIN.

Baustein

Programmeinheit, aus denen SPS-Programme zusammengesetzt werden. Bausteine können oft unabhängig voneinander in die SPS geladen werden. vgl. POE. In anderen Programmiersprachen oft auch als „Unterprogramm“ bezeichnet.

Bereichsangabe

Angabe eines zulässigen Wertebereichs für einen Datentyp oder eine Variable.

CPU

Central Processing Unit (Zentraleinheit, z.B. einer SPS)

Datenbaustein

Global zur Verfügung stehender, aktivierbarer Datenbereich. vgl. Baustein. In der IEC 61131-3 gibt es dafür keine direkte Entsprechung, sie werden hier durch globale, strukturierte Datenbereiche bzw. FB-Instanz-Datenbereiche ersetzt.

Datentyp

definiert die Bitlänge und Eigenschaften des Wertebereichs einer Variablen.

Deklaration

IEC

Bekanntgabe von Variablen und FB-Instanzen in einem Deklarationsblock unter Angabe eines Bezeichners, des Datentyps bzw. FB-Typs sowie ggf. Anfangswerte, Bereichsangabe und Feldeigenschaften. Die Definition bzw. die Programmierung von POEs wird ebenfalls als Deklaration bezeichnet, da hierbei ihre Schnittstellen dem Programmiersystem bekannt gemacht werden.

Deklarationsblock

IEC

Zusammenfassung von Deklarationen einer Variablenart zu Beginn der POE.

Direkt dargestellte Variable

IEC

Variable ohne weiteren Bezeichner, die einer Hierarchischen Adresse entspricht. Die zu einem SPS-System gehörenden Eingangsund Ausgangs-Module mit ihren Hierarchischen Adressen.

E/A-Peripherie

Einzelelement-Variable

IEC

Variable, die auf einem einzelnen Datentyp basiert.

I Glossar

383

Elementarer Datentyp

IEC

Ein durch die IEC 61131-3 vordefinierter StandardDatentyp.

Erweiterung von Funktionen

IEC

Eine Funktion kann eine variable Anzahl von Eingängen besitzen.

FB

IEC

Abk. für Funktionsbaustein

FB-Instanz

IEC

siehe Instanz

FB-Typ

IEC

Name eines Funktionsbausteins mit Aufruf- und Rückgabeschnittstelle

FBS

IEC

Abk. für Funktionsbausteinsprache

Feld

Aneinanderreihung von Elementen gleichen Datentyps.

Flanke

Mit einer „steigenden“ Flanke wird der 0o1Übergang einer booleschen Variable bezeichnet. Eine „fallende“ Flanke ist dementsprechend der 1o0-Übergang.

Formalparameter

Name (Bezeichner) einer Eingangsvariablen (alle POEs) oder Ausgangsvariablen (Funktionsbaustein und Programm).

Funktion

IEC

Eine POE vom Typ FUNCTION

Funktionsbaustein

IEC

Eine POE vom Typ FUNCTION_BLOCK

Funktionsbausteinsprache

IEC

Funktionsbausteinsprache FBS (engl.: Function Block Diagram – FBD) ist eine grafische Programmiersprache zur Beschreibung von Netzwerken mit gleichzeitig arbeitenden booleschen und arithmetischen Elementen.

Hierarchische Adresse

IEC

Physikalische Steckplatzadressen der E/A-Module eines SPS-Systems (vgl. E/A-Peripherie). Aufruf einer FB-Instanz, dessen Name als VAR_IN_OUT-Parameter einer POE übergeben wurde.

Indirekter FB-Aufruf

Instanz

IEC

Strukturierter Datensatz eines FBs durch Deklaration eines Funktionsbausteins unter Angabe des FBTyps.

Kaltstart

IEC

Programmstart, bei dem sämtliche Variablen und Speicherbereiche (neu) initialisiert werden (engl.: Cold Restart). Dieser auch Neustart genannte Vorgang kann bei bestimmten Ereignissen automatisch oder auch manuell durch den Anwender erfolgen. Zwischen Klammern und Sternchen eingeschlossener Text (nicht schachtelbar!) zur Erläuterung des Programms, wird vom Programmiersystem nicht interpretiert.

Kommentar

Konfiguration

IEC

Sprachelement CONFIGURATION, das einem SPSSystem entspricht.

KOP

IEC

Abk. für Kontaktplan

384

I Glossar

Kontaktplan

IEC

Zu einer ausführbaren Einheit gebundenes Programm vom POE-Typ PROGRAM (durch Zuordnung einer Task).

Laufzeitprogramm

Multielement-Variable

Kontaktplan (engl.: Ladder Diagram – LD) ist eine grafische Programmiersprache zur Beschreibung von Netzwerken mit gleichzeitig arbeitenden booleschen, elektromechanischen Elementen wie Kontakten und Spulen.

IEC

Variable vom Typ Feld oder Struktur, die aus mehreren Datentypen zusammengesetzt ist.

Neustart

siehe Kaltstart

Pragma

Pragmas dienen typischerweise der automatischen Vor- oder Nachbearbeitung von Programmen und werden vom Programmiersystem angeboten.

PC

Personal Computer. Gleichzeitig in der IEC 61131 (englische Version) verwendete Abkürzung für „Programmable Controller“.

POE

IEC

Abk. für Programm-Organisationseinheit

Programm

IEC

Eine POE vom Typ PROGRAM

ProgrammOrganisationseinheit

IEC

Ein Baustein der IEC 61131-3 des Typs Funktion, Funktionsbaustein oder Programm, aus dem Anwenderprogramme hierarchisch aufgebaut werden.

Programmiergerät

siehe SPS-Programmiergerät

Programmiersystem

siehe SPS-Programmiersystem

Querübersetzung

Konvertierung der Darstellung einer POE zwischen verschiedenen Programmiersprachen, typischerweise zwischen textuellen und grafischen Sprachen.

Rekursion

ist in der IEC 61131-3 unzulässig. Bezeichnet: a) die Deklaration eines FBs unter Verwendung des eigenen Namens bzw. FB-Typs, b) den gegenseitigen Aufruf von FBs. Rekursion wird als Fehler betrachtet und muss bei der Programmierung bzw. zur Laufzeit erkannt werden.

Ressource

IEC

Rückgewinnung der Quelle einer POE aus der SPS.

Rückübersetzbarkeit Schritt

Semantik

Sprachelement RESOURCE, das einer Zentraleinheit des SPS-Systems entspricht.

IEC

Zustandsknoten in einem AS-Programm, in dem Anweisungen der zu einem Schritt zugehörigen Aktion angestoßen werden. Bedeutung der Sprachelemente einer Programmiersprache sowie ihre Auslegung und Anwendung.

I Glossar

385

SPS

Speicherprogrammierbare Steuerung (engl.: „Programmable Controller“).

SPS-Programmiergerät

Einheit aus Computer, Programmiersystem und sonstiger Peripherie zur Programmierung der SPS.

SPS-Programmiersystem

Gesamtheit aller Programme, die zur Programmierung eines SPS-Systems notwendig sind: Erstellung und Übersetzung des Programms, Übertragen in die SPS sowie Programmtest- und Inbetriebnahme-Funktionen.

SPS-System

Gesamtheit aller zur Ausführung eines SPSProgramms benötigten Betsandteile der Hardware und Firmware bzw. Betriebssystems.

ST

IEC

Abk. für Strukturierter Text

Standard-Funktionen

IEC

Menge der durch die IEC 61131-3 fest vordefinierten Funktionen zur Realisierung SPS-typischer Funktionalität.

Standard-Funktionsbausteine

IEC

Menge der durch die IEC 61131-3 fest vordefinierten Funktionsbausteine zur Realisierung SPStypischer Funktionalität. Abk. für Standard-Funktionsbausteine

Std.-FB

Abk. für Standard-Funktionen

Std.-FUN Strukturierter Text

IEC

Strukturierter Text (engl.: Structured Text) ist eine textuelle Programmiersprache zur Beschreibung von Algorithmen und Ausführungssteuerung mit den Mitteln einer modernen Hochsprache.

Symbolische Variable

IEC

Variable mit Bezeichner, der eine Hierarchische Adresse zugeordnet wird. Aufbau und strukturelles Zusammenwirken der Sprachelemente einer Programmiersprache.

Syntax Task

IEC

Definition von Laufzeiteigenschaften eines Programms.

Transition

IEC

Übergang von einem AS-Schritt zum nächsten durch Auswertung der Transitionsbedingung. Definition eines benutzerspezifischen Datentyps auf der Basis bereits vorhandener Datentypen.

Typdefinition Überladen von Funktionen

Variable

IEC

Eine Funktion stellt unter gleichem Namen Funktionsklassen mit unterschiedlichen EingangsDatentypen (jeweils vom gleichen Typ) zur Verfügung. Bezeichnung eines Datenspeichers, der Werte annehmen kann, die durch den Datentyp sowie Angaben bei der Variablen-Deklaration festgelegt werden.

386

I Glossar

Warmstart

IEC

Programmstart an der Stelle, an der ein Spannungsausfall stattgefunden hat (engl.: Hot Restart). Dabei bleiben sämtliche gepufferten Datenbereiche des Programms erhalten und das Programm kann weiterlaufen, als hätte es die Unterbrechung nicht gegeben. Im Unterschied zum Warmstart am Programmanfang muss die Unterbrechungsdauer prozessabhängig innerhalb eines vorgegebenen Intervalls liegen. Dazu muss das SPS-System eine separat gesicherte Echtzeit-Uhr besitzen, um die Unterbrechungsdauer berechnen zu können.

Warmstart am Programmanfang

IEC

Programmstart wie beim Warmstart mit dem Unterschied, dass am Programmanfang wieder begonnen wird, wenn die Unterbrechungszeit eine maximale Zeitspanne überschritten hat. Das Anwenderprogramm kann anhand eines entsprechenden Status-Flags diese Situation erkennen, um eine spezielle Vorbesetzung seiner Daten vornehmen zu können. (engl.: Warm Restart).

Wiederanlauf

Zusammenfassender Begriff für Warmstart bzw. Warmstart am Programmanfang.

Zuordnungsliste

Liste, die zentral die Zuordnung von Symbolen zu SPS-Adressen beinhaltet.

Zyklus

Ein Durchlauf des (periodisch aufgerufenen) Anwenderprogramms.

Zykluszeit

Die Zeit, die ein Anwenderprogramm für einen Zyklus benötigt.

J Literaturverzeichnis

Bücher zur SPS-Programmierung nach IEC 61131-3: [Adam-97]

Adam Hans-Joachim, Adam Mathias „Programmieren in Anweisungsliste nach IEC 1131-3“ Elektor Verlag, ISBN 3-89576-056-0

[Aspern-00]

Jens von Aspern „SPS-Softwareentwicklung mit IEC 61131“ Hüthig Verlag 2000, ISBN 978-3-7785-2681-1

[Becker-00]

Norbert Becker „Automatisierungstechnik“ Vogel Buchverlag 2006, ISBN 3-8343-3017-5

[Berger-03]

Hans Berger „Automatisieren mit STEP 7 in KOP und FUP“ Speicherprogrammierbare Steuerungen SIMATIC S7-300/400 Hrsg.: Siemens-Aktiengesellschaft, Berlin München, Publicis-MCD-Verlag Erlangen 2003, ISBN 978-3895782190

[Berger-06]

Hans Berger „Automatisieren mit STEP 7 in AWL und SCL“ Speicherprogrammierbare Steuerungen SIMATIC S7-300/400 Hrsg.: Siemens-Aktiengesellschaft, Berlin München, Publicis-MCD-Verlag Erlangen 2003, ISBN 978-3895782800

388

J Literaturverzeichnis

[Lepers-07]

Heinrich Lepers „SPS Programmierung nach IEC 61131-3“, aus Reihe Reihe: Franzis PC und Elektronik Franzis Verlag Poing, 2007, ISBN 978-3-7723-5805-0

[Lewis-98]

R. W. Lewis „Programming industrial control systems using IEC 1131-3“, IEE Control Engineering, The Institution of Electrical Engineers, 1998, ISBN 0-852-96950-3

[Lewis-01]

R. W. Lewis „Modelling Control Systems Using Iec 61499: Applying Function Blocks to Distributed Systems “, IEE Control Engineering, The Institution of Electrical Engineers, 2001, ISBN 0-852-96796-9

[Neumann-98]

Peter Neumann, Eberhard E. Grötsch, Christoph Lubkoll, René Simon „SPS - Standard: IEC 1131-3, Programmieren in verteilten Automatisierungssystemen“ R. Oldenbourg Verlag, München Wien 1998, ISBN 3-486-24153-2

[Rolle-98]

I. Rolle (Hrsg.), A. Lehmann, H.-P. Otto, L. Trapp, H. Wegmann „IEC 61131, Wozu?“, VDE Taschenbuch, 1998, ISBN 3-800-72309-3

[Seitz-03]

Matthias Seitz „Speicherprogrammierbare Steuerungen“, Fachbuchverlag Leipzig 2003, ISBN 3-446-22174-3

[Wratil-96]

Peter Wratil „Moderne Programmiertechnik für Automatisierungssysteme“, EN 61131 (IEC 1131) verstehen und anwenden Vogel Verlag Würzburg 1996, ISBN 3-8023-1575-8

J Literaturverzeichnis

389

Normen zur SPS-Programmierung: [DIN EN 61131-1]

DIN EN 61131-1 Norm , 2004-03 Speicherprogrammierbare Steuerungen - Teil 1: „Allgemeine Informationen“ (IEC 61131-1:2003); Deutsche Fassung EN 61131-1:2003 Beuth Verlag GmbH, www.beuth.de

[DIN EN 61131-2]

DIN EN 61131-2; VDE 0411-500:2004-02 Norm , 2004-02 Speicherprogrammierbare Steuerungen - Teil 2: „Betriebsmittelanforderungen und Prüfungen“ (IEC 611312:2003); Deutsche Fassung EN 61131-2:2003 Beuth Verlag GmbH, www.beuth.de In Vorbereitung: DIN EN 61131-2; VDE 0411-500:2007-01 Norm-Entwurf , 2007-01 Speicherprogrammierbare Steuerungen - Teil 2: „Betriebsmittelanforderungen und Prüfungen“ (IEC 65B/582/CDV:2006); Deutsche Fassung prEN 611312:2006 Beuth Verlag GmbH, www.beuth.de Berichtigung zum Teil 2: DIN EN 61131-2 Berichtigung 1; VDE 0411-500 Berichtigung 1:2004-10 Norm , 2004-10 „Berichtigungen zu DIN EN 61131-2“ (VDE 0411 Teil 500):2004-02 Beuth Verlag GmbH, www.beuth.de

[DIN EN 61131-3]

DIN EN 61131-3 Norm , 2003-12, Ed. 2 Speicherprogrammierbare Steuerungen - Teil 3: „Programmiersprachen (IEC 61131-3:2003)“; Deutsche Fassung EN 61131-3:2003 Beuth Verlag GmbH, www.beuth.de

[IEC 61131-4 TR]

DIN EN 61131-4 Technical Report , 2004-07 „User guidelines“ IEC, www.iec.ch

[DIN EN 61131-5]

DIN EN 61131-5 Norm , 2001-11 “Speicherprogrammierbare Steuerungen - Teil 5: Kommunikation (IEC 61131-5:2000)“; Deutsche Fassung EN 61131-5:2001 Beuth Verlag GmbH, www.beuth.de

390

J Literaturverzeichnis

[DIN EN 61131-7]

DIN EN 61131-7 Norm , 2001-11 „Speicherprogrammierbare Steuerungen - Teil 7: FuzzyControl-Programmierung (IEC 61131-7:2000)“; Deutsche Fassung EN 61131-7:2000 Beuth Verlag GmbH, www.beuth.de

[DIN EN 61131-8 TR]DIN EN 61131-3 Beiblatt 1 Norm , 2005-04 „Speicherprogrammierbare Steuerungen - Leitlinien für die Anwendung und Implementierung von Programmiersprachen für Speicherprogrammierbare Steuerungen“; entspricht DIN EN 61131-8 TR Ed. 2 Beuth Verlag GmbH, www.beuth.de [IEC 61499-1]

DIN EN 61499-1 Norm , 2006-06 „Funktionsbausteine für industrielle Leitsysteme - Teil 1: Architektur (IEC 61499-1:2005);“ Deutsche Fassung EN 61499-1:2005 Beuth Verlag GmbH, www.beuth.de

[IEC 61499-2]

DIN EN 61499-2 Norm , 2006-06 „Funktionsbausteine für industrielle Leitsysteme - Teil 2: Anforderungen an Software-Werkzeuge (IEC 614992:2005);“ Deutsche Fassung EN 61499-2:2005 Beuth Verlag GmbH, www.beuth.de

[IEC 61499-4]

DIN EN 61499-4 Norm , 2007-05 „Funktionsbausteine - Teil 4: Regeln für normgerechte Profile (IEC 61499-4:2005)“; Deutsche Fassung EN 61499-4:2006 Beuth Verlag GmbH, www.beuth.de

[IEC 61499-08]

Normungskomitee der IEC: „TC65: INDUSTRIAL PROCESS MEASUREMENT AND CONTROL SC65B – Devices & process analysis” http://www.holobloc.com/stds/iec/tc65wg6/minutes/fla07_ wg15_minutes.pdf

[IEC IEC 65B WG7] Normungskomitee der IEC: „WG 7: Programmable control systems for discontinuous industrial-processes”, http://www.iec.ch/cgibin/procgi.pl/www/iecwww.p?wwwlang=e&wwwprog=dir wg.p&progdb=db1&ctnum=436

J Literaturverzeichnis

391

[OPC Foundation]

Nutzervereinigung OPC: Openness, Productivity, Collaboration (vormals: OLE for Process Control) http://www.opcfoundation.org

[VDI 3696/2-95]

VDI/VDE-Richtlinien, VDI/VDE 3696 Blatt 2 „Herstellerneutrale Konfigurierung von Prozeßleitsystemen- Standard-Funktionsbausteine“ 10/95. VDI/VDE-Handbuch Regelungstechnik.

[VDI 3696/3-95]

VDI/VDE-Richtlinien, VDI/VDE 3696 Blatt 3, „Herstellerneutrale Konfigurierung von Prozeßleitsystemen- Syntax des Funktionsbaustein-Textes“ 10/95. VDI/VDE-Handbuch Regelungstechnik.

392

J Literaturverzeichnis

PLCopen Kontakte [PLCopen Europe]

Eelco van der Wal Molenstraat 34 4201 CX Gorinchem, The Netherlands Tel: +31-183-660261 Fax: +31-183-664821 Email: [email protected] http://ww.plcopen.org

[PLCopen North America] Bill Lydon 10308 W. Cascade Dr. Franklin, WI 53132 USA Tel: +1 414-427-5853 Email: [email protected] http://www.plcopen-na.org/ [PLCopen Japan]

Shigeo Kawashima Mitsui Sumitomo Bank Ningyo-cho 5-7, Nihonbashi Ohdemma-cho, Chuo-lu Tokyo, 103-0011 Japan Tel: +81-5847-8058 Fax: +81-5847-8180 Email: [email protected] http://www.plcopen-japan.jp

[PLCopen China]

No. 1, JiaoChangKuo DeShengMenWai Beijing, 100011 China Tel: +86-(010) 6202-9216 Fax: +86-(010) 6202-7873 http://www.plcopen.org.cn

K Index

—A— Ablaufkette 176 Ablaufsprache siehe AS Ablaufsteuerung 206 Ableitung von Datentypen 82 ACCESS 251 AE 105, 381 Akkumulator siehe AE Aktion 189, 191, 381  Anweisung 191  boolesch 189, 191 Aktionsblock 189, 191, 381 Aktionskontrollblock 381 Aktionskontrolle 199 Aktionsmerker 200 Aktionsname 193 Aktiv-Attribut 175 Aktivierungsmerker 203 Aktualparameter 36, 60, 217, 381  AWL 112  FBS 144  KOP 159  ST 126 AktuellesErgebnis siehe AE Alternativ-Kettenauswahl 177 Anfangsschritt 183, 207 Anfangswert 381  bei Programmstart 96  für Anwenderdaten 298 Anfangswerte 89 Anlagen-Dokumentation 270 Anlaufverhalten 278 Anweisung 103  AWL 103, 104  ST 119, 120 Anweisungsliste siehe AWL Anweisungsteil 194

Anwendungs-Modell 308 ANY  Allgemeiner Datentyp 90  Datentyp 91 Arithmetische Funktionen 322 AS 174, 382  Netzwerk 175  Struktur 174, 190 Attribut Bestimmungszeichen 98 Attribute 98 Aufrufparameter 257 Aufzählung 382 Aufzählungstyp 85 Ausdruck (ST) 103, 121  Abarbeitung 123 Ausführungssteuerung  FBS 143  KOP 158 Ausgangsparameter  PROG 251 Austauschformat 18 Auswahl-Funktionen 325, 327 AWL 104, 382  Aufruf von FB 114  Aufruf von Funktionen 112 AWL-Beispiele 343 AWL-Syntax 359

—B— Batteriepufferung 382 Baustein 22, 382  bei IEC 61499 307  Bibliothek 289 Bausteinarten 30 Bausteine in verteilten Systemen 288 Begrenzungszeichen 70, 373 Beispiele  AS (Dino-Park) 208

394

K Index

 AWL (Bergbahn) 116  FBS (Stereo-Rekorder) 148  KOP (Bergbahn) 163  ST (Stereo-Rekorder) 134 Belegungsliste 245, 270 Bereichsangabe 382 Bergbahn  Beispiel in AWL 116  Beispiel in KOP 163 Bestimmungszeichen  Attribut 98  in AS 189, 193, 198 Bezeichner 70, 74 Bistabile Elemente (Flip-Flops) 336 Bitschiebe-Funktionen 323 Bitweise Boolesche Funktionen 324

—E— E/A-Peripherie 77, 93, 382 Einfache Kette 177 Eingangsparameter  PROG 251 Einkaufsberater 317 Einzelelement-Variable 95, 382 Einzelschritt 276, 284 Elementare Datentypen 81 EN/ENO 54  FBS 144  KOP 160  Ladder 170 Erweiterung von Funktionen 383 Execution Control Chart (ECC) 310 EXIT 133 Externe Variable 257

—C— CASE 129 CD  Inhalt 315 CONFIGURATION 53, 246 CONSTANT 98, 99, 100 CPU 382

—D— Datenbaustein 30, 285, 382 Datenfluss 305, 309 Datenstruktur 87, 96 Datentyp 79, 81, 382  Ableitung 82, 88, 381  Allgemein 90, 381  Anfangswert 84  ANY 90  Aufzählung 84  Bereichsangabe 84  Datenstruktur 84  Elementar 81, 383  Feldgrenzen 84  zusätzliche Eigenschaften 83 Deklaration 382 Deklarationsblock 382 Diagnose 292 DIN EN 61131-3 14 Dino-Park  Beispiel in AS 208 Direkt dargestellte Variable 93, 94, 257, 382

—F— F_EDGE 98, 100 FB siehe Funktionsbaustein FB-Aufruf  AWL 114  FBS 144  indirekt 383  KOP 159  ST 122, 126 FB-Instanz 22, 64, 383 FBS 137, 383  Aktionsblock 198  Aufruf von FB 144  Aufruf von Funktionen 144 FB-Typ 43, 383 FB-Verschaltung 288, 291  bei IEC 61499 303, 313 Fehlerursachen 353 Feld 86, 383 Feldgrenzen 86 Flanke 383 Flankenerkennung 49, 337  Kontakt 156  Spule 157 FOR 131 Forcing 276, 283, 284 Formalparameter 36, 60, 383  FBS 141, 144  KOP 159  ST 124, 126 FUN siehe Funktion Funktion 31, 50, 383

K Index  als Operator in ST 124  FB-Aufrufe 57  FUN-Aufrufe 57  für Datentypen der Aufzählung 334  für Datentypen der Zeit 333  für Zeichenfolgen 330  Variablenarten 50  zur Typwandlung 320 Funktion (AWL)  Parameter 113 Funktionsaufruf  AWL 112  FBS 144  KOP 160  ST 123, 124 Funktionsbaustein 31, 42  Ableitung 292  Basis-FB bei IEC 61499 312  bei IEC 61499 305  bei IEC 61499 310  benutzerdefiniert bei IEC 61499 313  indirekter Aufruf 66  Instanzbildung 22  Instanziierung 42  Instanzname 92  Kapselung 48  Objektorientierung 48  Seiteneffekte 48  Variablenarten 49  Wiederverwendbarkeit 48  zusammengesetzt bei IEC 61499 312 Funktionsbaustein-Modell 309 Funktionsbausteinsprache siehe FBS Funktionsplan 291 Funktionswert 50  AWL 113  FBS 145  KOP 160  ST 123, 125, 126 Fuzzy Control Language 16

—G— Geräte  bei IEC 61499 305 Geräte-Modell 306 Globale Variable 257 Grafikelement 138  FBS 142  KOP 153

395

Grafikobjekt  FBS 142  KOP 153  KOP und FBS 138

—H— Haltepunkt 276, 284 Hierarchische Adresse 93, 383

—I— IEC 19 IEC 1131-3  Gemeinsame Sprachelemente 69  Kommunikationsmodell 256  Softwaremodell 241  Stärken 297  Strukturierte SPS-Programme 300  Variablenkonzept 80 IEC 61131  Aufbau 14  Geschichte 14  Ziele 12 IEC 61131-3  Anlaufverhalten 278  Fehlerkonzept 293  Grafische Sprachen 103  Textuelle Sprachen 103 IEC 61499 303  Überblick Aufbau 314 IF 127 Implementierungsabh. Parameter 355 Indirekte Adresse  Ladder 172 Initialisierung  Anfangswerte von Variablen 89  bei fehlenden Eingangsvariablen 63  bei Variablenarten 98  FB-Instanz 63 Instanz 42, 383  Datenbaustein 47  Gedächtnis 46, 47  RETAIN 47  Struktur 44 Instanznamen 92

—K— Kaltstart 97, 383 Kette 177 Kettenauswahl 178

396

K Index

Ketten-Schleife 179 Kettensprung 179 Klammeroperator (AWL) 108 Kommentar 272, 383  AS 175  AWL 105  KOP/FBS 138  ST 119 Kommunikation 255 Kommunikations-Bausteine 257 Kommunikationsmanager 277 Kompaktgeräte 9 Konfiguration 245, 383  Beispiel 253  Dokumentation 270  Kommunikation 246 Konfigurations-Editor 303, 314 Konfigurationselemente 242 Konnektor 103  AS 184  KOP/FBS 139 Konnenktor  FBS 142 Kontakt 154 Kontaktplan siehe KOP Kontrollfluss 305, 309 KOP 137, 152, 383  Aktionsblock 197  Aufruf von FB 159  Aufruf von Funktionen 160

—L— Ladder 169 Laufzeiteigenschaften 248  bei IEC 61499 305 Laufzeitprogramm 242, 243, 245, 384 Literal 70, 72

—M— Makro 291 Modifizierer (AWL) 108 Multiauswahl (ST) 128 Multielement-Variable 50, 95, 384

—N— Netzwerk 137  Abarbeitung in FBS 146  Abarbeitung in KOP 146, 161  Ladder 170 Netzwerkaufbau

 FBS 140  KOP 153 Netzwerkgrafik 138 Netzwerkkommentar 138 Netzwerkmarke 137 Neustart 97, 384 NON_RETAIN 98, 100 NON_RETAIN 99 Numerische Funktionen 321

—O— Öffner 155 Online-Änderung 277 Operand  AWL 103, 105  ST 121 Operand (ST) 121 Operator (AWL) 103, 105, 108  ANY_BIT 110  ANY_NUM 111  FB-Eingangsvariable 114  JMP/CAL/RET 112  Sprung/Aufruf 112 Operator (ST) 121, 122  Funktion 124 Operatorgruppen 107 Organisationsbaustein 30

—P— PC 384 PLCopen 17  Benchmark 17  Safety 17  Sicherheit 17  XML 17  Zertifizierung 18 POE 21, 30, 384  Anweisungsteil 23, 40  Ausgangsparameter 47  AWL-Beispiele 343  AWL-Einführungsbeispiel 25  Deklarationsteil 34, 77  Eingangsparameter 47  Formalparameter 37  Grundelemente 32  Merkmale der Schnittstelle 36  Merkmalsübersicht 68  Rekursiver Aufruf 58  Sprachunabhängigkeit 269

K Index  Übersicht 21, 30  Variablenarten 35  Variablen-Zugriff 38  Wiederverwendbarkeit 32, 298 POE-Typen 30 Power Flow 280 Pragmas 76 PROG siehe Programm PROGRAM 53, 248 Programm 31, 53, 384 Programmdokumentation 270 Programmierfehler 298 Programmiergerät 384 Programmiersprachen  Merkmale 41 Programmiersystem 384  Anforderungen 259 Programmorganisationseinheit siehe POE Programmstatus 279, 280 Programmstruktur  AS 174  Dokumentation 270 Programmtest 284  in Ablaufsprache 284 Programmtransfer 277 Projektverwaltung 272  Aufgaben 275

—Q— Q-Ausgang 200 Querübersetzbarkeit 147, 263, 384  Einschränkungen 265  Gütekriterien 268  mit Zusatzinformation 267 Querverweisliste 270, 271

—R— R_EDGE 98, 100 READ_ONLY 98, 100 READ_WRITE 98, 100 Rekursion 384 REPEAT 130 Reservierte Schlüsselworte 71, 373 RESOURCE 247 Ressource 245, 384  bei IEC 61499 305, 306 Ressource-Modell 307 RETAIN 23, 49, 98, 99, 100 RETURN 126

397

Rezeptur 284 Rückdokumentation 260 Rückführung (AS) 179 Rückkopplungsvariable  AS 191, 193  FBS 148  KOP 162 Rückübersetzbarkeit 260, 261, 384

—S— Safety 16 Schließer 155 Schlüsselworte 70 Schritt 175, 182, 384 Schrittbaustein 30, 174 Schrittkette 174 Schrittmerker 183, 193 Schrittname 183 Schrittzeit 183 Seiteneffekte  bei FB 48  bei FUN 50  in KOP 163 Semantik 69, 384 Service-SchnittstellenFunktionsbausteine 307 Sicherheitsgerichtete SPS 16 Simultan-Verzweigung 178 Soft Logic Array 9 Speicher  Ladder 171 Sprachelemente  einfache 69 Sprachverträglichkeit 262 Sprungmarke 105 SPS 385 SPS-Adressen 94 SPS-Konfiguration 241, 299 SPS-Programmiergerät 385 SPS-Programmiersystem 259, 385  Trend 301 SPS-Programmierwerkzeuge 10  Anforderungen 259 SPS-System 12, 14, 385 Spule 154 ST 119, 385  Aufruf von FB 122, 126  Aufruf von Funktionen 123 Standard-Datentypen 351 Standard-FB

398

K Index

 bei IEC 61499 313 Standard-Funktionen 214, 319, 385  Aufrufschnittstelle 221  Beispiele 221  Beschreibung im Anhang 319  Erweitern 220  Überladen 218 Standard-Funktionsbausteine 230, 385  Aufrufschnittstelle 232  Beispiele 232  Beschreibung im Anhang 335 Status  asynchron 281  bei Änderung 281  Datenanalyse 281  synchron 281 Stereo-Rekorder  Beispiel in FBS 148  Beispiel in ST 134 Stromflußanzeige 280 Stromlaufplan 41 Strukturierter Text siehe ST Strukturkomponente 95 Symbolische Variable 93, 94, 385 Syntax 69, 385  AWL 359 Syntaxgraph für AWL 359 Systemkonfigurator 277 System-Modell 305

—T— Task 242, 245, 385  Unterbrechbarkeit 250 TASK 248  Parameter 250 Teilanweisung 121 Test&Inbetriebnahme 276 Token siehe Aktiv-Attribut Transition 175, 182, 184, 385 Transitionsbedingung 175, 182  direkte Angabe 184  Konnektor 184 Transitionsname 184 Typdefinition 77, 82, 385  Anfangswerte 89 Typgerechter Datenzugriff 298 Typüberprüfung 79 Typverträglichkeit 344  in AWL 106  in ST 125

—U— Überladen 60, 218, 232 Überladen von Funktionen 91, 385 Umverdrahtung 245, 271 Unerreichbare Netzwerke 180 Unsichere Netzwerke 180

—V— VAR 98, 100 VAR_ACCESS 98, 100 VAR_CONFIG 98, 254 VAR_EXTERNAL 46, 49, 65, 98, 100 VAR_GLOBAL 98, 100 VAR_IN_OUT 37, 46, 49, 65, 98, 100 VAR_INPUT 37, 46, 65, 98, 100 VAR_OUTPUT 37, 46, 65, 98, 100 VAR_TEMP 46, 98 Variable 92, 385  Attribute 98  Deklaration 22  statt Hardware-Adressen 77, 297 Variablenarten 39, 100 Variablenausgabe 280 Variablendeklaration 92  Attribute 98  Beispiel 23  grafische Darstellung 100  Variablenarten 98, 100 Variablenstatus 279, 280 Verbindung  FBS 142 Verbindungen  FBS 143  KOP 154 Verdrahtungsliste 270 Vergleichs-Funktionen 328 Verteilte Anwendungen 289 Verzweigung (ST) 127

—W— Warmstart 97, 386 Wertebereich 85 WHILE 130 Wiederanlauf 97, 386 Wiederverwendbarkeit 29, 32, 48

—Z— Zähler 338 Zeitgeber (Zeiten) 340 Zugriffspfad 48, 247, 252, 257

K Index Zuordnungsliste 95, 270, 271, 386 Zustandsdiagramm  bei IEC 61499 310 Zuweisung (ST) 124

Zwischensprache 104 Zyklus 386  AS-Ablaufsteuerung 207 Zykluszeit 386

399

“This page left intentionally blank.”

Autorenbiographien

Karl-Heinz John Geboren am 09.07.1955 in Ulm. Verheiratet, 2 Kinder. Studium der Informatik 1975 bis 1981 an der Friedrich-Alexander-Universität Erlangen-Nürnberg mit Schwerpunkt Rechnerarchitektur; Abschluss DiplomInformatiker. Diplomarbeit über Mikroprogrammierung. 1981 bis 1983 wissenschaftlicher Mitarbeiter am Lehrstuhl für Rechnerarchitektur und Verkehrstheorie. Seit 1984 bei der infoteam Software GmbH (www.infoteam.de), Softwarespezialist für Automatisierung und medizinische Gerätetechnik mit Niederlassungen in Bubenreuth / Nürnberg, Stäfa / Schweiz und Beijing / China. Als Mitinhaber und Geschäftsführer Geschäftsbereich „Technik“ u.a. für die Entwicklung von IEC 61131- Programmiersystemen wie OpenPCS verantwortlich. Mitbegründer der PLCopen (www.plcopen.org), Vice-President ASQF (www.asqf.de) (größter deutscher Fachverband Softwarequalität); ASQFFachgruppenleiter Automatisierung (ASQF Automation Days in Nürnberg und St. Gallen).

Michael Tiegelkamp Geboren am 23.12.1959 in Krefeld. Geschieden, 2 Kinder. Studium der Informatik 1982 bis 1988 an der Friedrich-Alexander-Universität Erlangen-Nürnberg mit Schwerpunkten Rechnerarchitektur und Kommunikationssysteme; Abschluss als Diplom-Informatiker. Diplomarbeit über SPS-Architekturen. 1988 bis 1994 bei der infoteam Software GmbH als Projektleiter und Leiter Marketing für SPS-Programmiersysteme verantwortlich. Bei der SIEMENS AG bis 1997 als Projektleiter verantwortlich für Software-Entwicklungen im Bereich

402

Autorenbiographien

der Programmiergeräte-Software für SIMATIC S5/S7, zwischen 1998 und 2002 Gruppenleiter für Produktdefinition von SIMATIC Industrie Software und von 2002 bis 2004 Projektleiter für System-Roadmap & Innovation in der Automatisierungstechnik. 2004 und 2005 Gruppenleiter Produktmanagement in der Niederspannungs-Energieverteilung, 2005 bis 2007 Aufbau des Geschäftssegments Power Management. 2007 Integrationsmanager und Wechsel zur Siemens-Tochter OEZ s.r.o., Tschechien, seit 2007 dort Manager Prozesse und Projekte.

Dieses Buch wurde mit viel Engagement und großer Sorgfalt geschrieben. Sollten Sie dennoch Fehler entdecken, wären wir dankbar für Ihre Hinweise! An dieser Stelle einen herzlichen Dank an alle Leser, welche nach wie vor durch Hinweise und Anmerkungen zur heutigen Qualität dieses Buches beigetragen haben. Auch weitere Anregungen jeder Art sind willkommen. Die Autoren sind jederzeit erreichbar unter:

Anschrift e-mail

Homepage Tel./Fax:

Karl-Heinz John Irrlrinnig 13 91301 Forchheim [email protected] oder (über infoteam): [email protected]

Michael Tiegelkamp Kurpfalzstr. 34 90602 Pyrbaum [email protected] oder (über Siemens): [email protected]

www.fen-net.de/karlheinz.john +49 (9191) 14672 (Tel.)

+49 (173) 3112532 (Tel.)