Upload
duongminh
View
255
Download
10
Embed Size (px)
Citation preview
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Sept. 2017 1. Übersicht
ASA_Progr_Spr.doc 1
Entwurfs- und Programmiersprachen für speicherprogrammierbare Leiteinrichtungen
Diese Unterlage gibt einen Überblick über die wich-tigsten Programmiersprachen und erklärt die in IEC / DIN EN 61131 international genormten Sprachen sowie neue Ansätze in Fertigungs- und Prozess-automation
Inhalt: Seite:
1 Übersicht 1.1 Entwurfsmethoden (-Sprachen) 1 1.2 Programmiersprachen 4 1.3 Beitrag der SW zur Leitanlagenqualität 5 1.4 Beispiele 6 2. Die Norm DIN EN 61131 für SPS 2.1 Gliederung / Inhalt 6 2.2 SW - Modell 7 2.3 Datentypen 9 2.4 Darstellungen (Variablen, Literale, ..) 10 2.5 Variablen - Deklaration 11 2.6 Kommunikations - Modell, - Funkt.Bausteine 13 2.7 Funktionen (incl. Standard - Funktionen) 15 2.8 Funktionsbausteine (incl. Stand. Fkt. baust.) 16 3. Text - Sprachen der DIN EN 61131 3.1 AWL (Anweisungsliste) 17 3.2 Strukturierter Text 18 4. Grafische Sprachen der DIN EN 61131 4.1 Gemeinsame Elemente 19 4.2 FBS (Funktionsbaustein - Sprache) 20 4.3 KOP (Kontaktplan) 20 4.4 AS (Ablauf - Sprache) 21 5. Deklaration der Programmstruktur 24 6. Beispiele 6.1 "Wiegen" (Sprachen-Vergleich) 25 6.2 Funktionsbaustein "Totmannsknopf" 26 6.3 Ablauf "Mixer" 27 6.4 POE - Struktur "Speisepumpe" 28 7. Normen IEC 61499 und IEC 61804 29
1. Übersicht 1.1 Entwurfsmethoden (-Sprachen) (Bild 1.1.1) Umfang und Komplexität von Automatisierungs-aufgaben sind sehr verschieden. Kleine, einfache Aufgaben kann man direkt in einer Programmier-sprache beschreiben. Bei großen, komplexen Aufgaben ist ein vorheriger Entwurf sinnvoll. Bild 1.1.1 gibt einen Überblick. Immer zu empfehlen ist die Erstellung einer Struktur, in der die Gesamtaufgabe in überschaubare Teile aufgeteilt wird und für diese festgelegt wird, ob sie durch Verknüpfungs- oder Ablaufsteuerungen rea-lisiert werden sollen. Das kann graphisch oder durch den „Projektbaum“ (entspricht Windows-Explorer) im Engineering Tool erfolgen. Verknüpfungssteuerungen sind meist ausreichend in formlosen Beschreibungen oder Datensammlun-gen definiert. Soweit irgend möglich werden in der Einzelleitebene Standard-Funktionsbausteine ver-wendet, z.B. bei Motion Control oder bei einzeln an-steuerbaren Aggregaten. Bei zeitlich schwierigen Zusammenhängen ist die Erstellung eines Signal-Zeit-Diagramms zu empfehlen, bevor man die Auf-gabe durch Basisfunktionen und -Funktionsbau-steine löst. Manchmal helfen auch Wahrheitstafeln. Für den Entwurf von Ablaufsteuerungen gab es verschiedene Methoden. Heute aktuell ist Grafcet (GRAphe Fonctionnel de Commande Etape Transi-tion), genormt in DIN EN 60 848. Dadurch sind Weg-Schritt-Diagramm und Funktionsplan für Ablaufsteu-erungen nach DIN 19 226-6 ersetzt. Manchmal ist zusätzlich oder alternativ ein Zustands-Übergangs-Diagramm sinnvoll (im UML-Bereich üblich) Diese Entwurfsdarstellungen können nicht direkt in Funktionen und Funktionsbausteine umgeformt wer- den. Dazu die-
nen spezielle Editoren der Hersteller, heu-te meist kom-patibel zu den Sprachen der DIN IEC 61131. Für Ablaufsteu-erungen wird hier die „Ablauf-Sprache“ AS eingesetzt.
Da Grafcet da-zu nicht kom-patibel ist, wird oft direkt die AS eingesetzt, da auch sie für Verfahrens- und Maschi-nen-Techniker lesbar ist.
Bild 1.1.1: Übersicht: Entwurfs- und Programmiersprachen für Automationssysteme
Programmiersprachen Automatisierungssysteme DHBW Mannheim 1. Übersicht Erich Kleiner, Sept. 2017
2 AS_Syst_Komm.doc
1.1.1 Strukturierung Gesamtaufgaben mittleren und großen Umfangs unterteilt man sinnvollerweise in kleine, überschau-bare Teile (Bild 1.1.2).
In der Prozessautomation entsteht dabei eine hierarchische Struktur, insbesondere dann, wenn die Aktoren einzeln bedienbar sein sollen. In ihr wird die Gesamtaufgabe horizontal in Teilaufgaben unterteilt, und vertikal werden nach dem Subsidiaritätsprinzip so viele Funktionen wie möglich „nach unten“ ge-schoben. Dadurch werden die übergeordneten Teile einfach realisierbar. In der untersten Ebene werden Steuerung und Regelung der Aktoren realisiert, möglichst durch komplexe Standard-Funktionsbausteine, getrennt für Steuerung und Regelung. Diesen brauchen haupt-sächlich nur einzelne Signale und Werte zugeordnet werden. Die meist wenigen individuellen Anpassun-gen werden durch zusätzliche Basis-Funktionen und - Funktionsbausteine realisiert. Daher kann das Pro-gramm dieser Ebene meist aus der Struktur direkt in einer Programmiersprache geschrieben werden. In den höheren Ebenen kommen Ablaufsteuerungen vor, für die ein Entwurfsschritt mit Grafcet oder Zu-standsdiagramm sinnvoll sein kann.
Alleine für die Aufteilung in Steuerungs- und Rege-lungsaufgaben und die Zuordnung von Aktoren ist eine Strukturierung sinnvoll (Bild 1.1.3). Statt der grafischen Darstellung genügt oft eine hier-archische Gliederung im Projektbaum.
In der Fertigungsautomation ergibt sich eine hori-zontale Struktur durch Unterteilung in die beteiligten Maschinen / Einrichtungen (Bild 1.1.4), die meist Ab-laufsteuerungen benötigen. Für diese ist ein Entwurf über Grafcet meist sinnvoll.
1.1.2 Zustands-Übergangs-Diagramm (oder „Zustandsgraph“ im UML-Bereich) Für komplexe Abläufe mit mehreren Programmteilen ist vor Erstellung der Ablaufprogramme (z.B. in "Ab-lauf - Sprache") die Klärung der Aufgabenstellung mittels Zustandsgraph sinnvoll (entspricht etwa dem „Petri- Netz“). Bild 1.1.5 zeigt hierzu als vereinfachtes Beispiel den Start eines Brenners. Die Kreisflächen stellen stabile Zustände dar (z.B. "Stillstand"), die Kreisbögen (oder Strecken) sind die Teilprogramme, und die (wichtigsten) Aktionen sind mit Querstrichen an den Programmen angegeben. In dieser Darstellung kann exakt gezeigt werden, aus welchem Zustand oder Ablauf welcher andere Zustand erreicht werden können soll.
1.1.3 Signal-Zeit-Diagramm Für den Entwurf von Logik mit Zeitgliedern empfiehlt sich ein Signal / Zeit - Diagramm. Bild 1.1.6 zeigt die Anwendung für eine Oszillator - Schaltung. Hier wird log. „1“ durch eine „dicke“ Linie dargestellt. Die Darstellung einer "Verarbeitungs-Zeit" pro Funk-tion / Gatter sowie Pfeile und Kreise zur Darstellung von Abhängigkeiten erhöhen die Anschaulichkeit. Bool’sche Algebra oder Signaltabellen (Bild 1.1.7) werden zur Überprüfung statischer Logik eingesetzt.
Bild 1.1.2: Hierarchische Leitsystem- Struktur
Hallenlüftung Lüftungssteuerung Temperaturregelung
Signal - Tabelle
E1
E2
E3
UND A
E1 E2 E3 A0 0 0 00 0 1 00 1 0 00 1 1 01 0 0 01 0 1 01 1 0 11 1 1 0
Bild 1.1.3: Aufteilung Steuerung - Regelung
Bild 1.1.4: Strukturierung In der Fertigungs- automation
Bild 1.1.5: Zustands-Graph
Bild 1.1.6: Signal-Zeit-Diagramm
Bild 1.1.7: Signal-Tabelle
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Sept. 2013 1. Übersicht
ASA_Progr_Spr.doc 3
1.1.4 Grafcet „GRAphe Fonctionnel de Commande Etape Transi-tion“, genormt in DIN EN 60 848, ist eine Darstellung von Ablaufsteuerungen, die sowohl der Maschinen- oder Verfahrenstechniker als auch der Leittechniker anwenden können soll.
Eine Ablaufsteuerung besteht aus Schritten, die man sich als Speicher (Flip Flop) vorstellen kann. Bild 1.1.8 zeigt die Darstellung in Grafcet und die Wir-kungsweise in Funktionsbausteinsprache. Ist Schritt n-1 gesetzt und die Übergangsbedingung auf den nächsten Schritt n erfüllt (meist die Rück-meldung, dass Befehl n-1 ausgeführt wurde), wird Schritt n gesetzt und n-1 gelöscht. Nun startet n seine Aktion und gibt an n+1 weiter, wenn diese ausgeführt wurde, gemeldet durch Transition n. In einer Schrittkette ist immer nur ein Schritt aktiv. Bild 1.1.9 zeigt verschiedene Ketten und –Kombi-nationen zur Lösung komplexer Aufgaben.
Bild 1.1.10 zeigt die Grafcet-Darstellungs-Regeln, sozusagen die „Syntax“. Ein Ablauf beginnt stets mit einem Initialisierungs-schritt. Danach müssen abwechselnd Transitionen und Schritte folgen.
Eine Transition ist eine Bool’sche Variable. Ist sie „TRUE“ („1“), so wird der nächste Schritt eingeschal-tet. Eine Transition kann aus einer Verknüpfung mehrerer Variablen bestehen, verknüpft mit * für UND und + für ODER, Überstrich für Negation. Ein Schritt hat einen eindeutigen Namen, z.B. S3. Mit vorgestelltem X wird das Signal bezeichnet, dass er aktiv ist, z.B. XS3. Ein Schritt kann eine oder mehrere Aktionen aus-lösen, bezeichnet mit einer Bool’schen Variablen. Ohne besondere Angaben ist sie TRUE (1) solange der Schritt aktiv ist. Sie kann von einer Bedingung abhängig gemacht werden (im Bild: B2 für A2), oder verzögert wirksam werden, z.B. A3 im Bild nach 3s. Dies wird durch Vorstellen einer Zeitangabe (3s) und Trennung vom Schritt-Namen durch / dargestellt. Durch Nachstellen der Zeitangabe kann eine Ausschalt-Verzögerung dargestellt werden. Eine zeitliche Begrenzung der Aktion kann durch eine negierte Bedingung erreicht werden, z.B. im Bild: NOT 5s/XS4, d.h. die Variable A4 ist nur 5s nach Aktivieren von Schritt S4 TRUE. Eine Befehlsspeicherung wird durch eine Zuwei-sung der Form A5:=1 dargestellt, Rücksetzung der Speicherung durch Zuweisung zu „0“, also A5:=0 Dabei ist der Zeitpunkt von speichern / rücksetzen durch einen Pfeil für positive oder negative Flanke anzugeben (aktivieren oder deaktivieren eines Schrittes). Die Speicherung kann auch von einer Bedingung abhängig gemacht werden wie bei S6 im Bild. Eine Wartezeit zwischen zwei Schritten wird durch eine Verzögerung des ersten Schrittsignals als Tran-sition realisiert, siehe S3 – S4 im Bild: 1s/XS3
In hierarchischen Strukturen kann ein Grafcet auch mit speziellen Schritten oder Transitionen beginnen und aufhören, z.B. als „Expansion“ eines Makros.
Programmwiederholung (z.B. zur Herstellung mehrerer Teile) wird durch Rücksprung in den Initialschritt dargestellt. Kommentare können überall ergänzt werden, sie sind durch Anführungszeichen gekennzeichnet.
Bild 1.1.8: Grafcet-Schritt: Darstellung und Wirkungsweise
Bild 1.1.9: Ketten-Arten und Sprünge
Bild 1.1.10: Grafcet-„Syntax“
Programmiersprachen Automatisierungssysteme DHBW Mannheim 1. Übersicht Erich Kleiner, Sept. 2017
4 AS_Syst_Komm.doc
1.2 Programmiersprachen Als in den 60er - Jahren begonnen wurde, Steuer-ungs- und Regelungsaufgaben durch "Prozessrech-ner" zu realisieren, standen zur Programmierung Hochsprachen wie FORTRAN zur Verfügung. In den 70er - Jahren entstanden einfache Hardware - Einrichtungen als "Speicher - programmierte Steu-erungen" (SPS), die Relaissteuerungen und Ver-bindungs - programmierte Elektronik ersetzten. Sie wurden in "Anweisungs - Listen" (AWL) programmiert, die als spezieller Assembler gesehen werden können. Sie sind noch heute üblich, insbe-sondere weil in manchen SPS bestimmte Funktionen nur per AWL verfügbar sind. Für größere Anlagen wurden Prozess - Leitsysteme (PLS) entwickelt. Ihre Wirkungsweise wurde in "Funktionsplänen" für die Verfahrenstechniker lesbar dargestellt, wobei nicht nur Pläne von Abläufen, wie in DIN 40719 beschrieben, so genannt wurden. Programmiert wurden sie zunächst ebenfalls in einer Art AWL. Bald entstanden Engineering Tools, die die Programmierung in Funktionsplan - Form und die Bearbeitung der Gesamt - Planung erlaubten. Bei den SPS wurde ebenfalls die grafische Programmierung im Funktionsplan aber auch im dem Elektriker entgegenkommenden Kontaktplan (KOP) entwickelt, wobei damit nur einzelne "Logik - Pfade" dargestellt wurden. "Programmierer" benutzten Programmiersprachen wie C++. Für die am weitesten verbreitete SPS, die SIMATIC der Fa. Siemens, wurde das SW - Paket "STEP.." entwickelt, für die S5 wurde von Siemens, aber auch von anderen Firmen, STEP5 mit FUP, KOP und AWL verwendet. Heute ist STEP7 aktuell.
Für Ablauf - Steuerungen wurden besondere Dar-stellungen entwickelt, später bei Siemens "Graph" (aktuell: Graph 7) und in der Norm "AS" (Ablauf-Sprache) genannt. In Prozessleitsystemen wurden Ablaufsteuerungen mit speziellen Schritt-Funktions-bausteinen realisiert (siehe Bild 1.1.1 unten Mitte). Funktionspläne waren anfangs echte Grafik, werden heute aber zur direkten Verwendung für die Code-erzeugung durch Interpretation eines Quellcodes von einem Textprogramm dargestellt.
Nach nationalen Normen (z.B. DIN 19239) entstand in den 80er - Jahren die internationale Norm IEC 61131 (heute auch DIN EN 61131) für "Speicher - programmierbare Steuerungen", da es immer dringlicher wurde, verschiedene SPS - Produkte mit dem gleichen Werkzeug und ohne dauerndes Umlernen bearbeiten zu können. Die Norm definiert "SPS" nicht zu eng, so dass sie im Wesentlichen auch für PLS und weitere Entwicklungen gelten kann. Die Festlegung einer einzigen "Supersprache" war weltweit nicht möglich, daher wurden die damals bekannten Sprachen in die Norm aufgenommen: - grafische Sprachen: - FBS: Funktions - Baustein - Sprache, en: FBD: Function Block Diagram), - AS: Ablauf - Sprache (für Abl.-Steuerungen), en: SFC: Sequential Function Chart, - KOP: Kontakt - Plan, en: LD: Ladder Diagram, - Text - Sprachen: - AWL: Anweisungsliste ("Assembler"), en: IL: Instruction List, - ST: Strukturierter Text, en: ST: Structured Text (ähnlich den Hochsprachen). Nur die Text -
Sprachen sind vollständig und eindeutig portier-bar, für die grafi-schen Sprachen erlaubt die Norm zu viele Freiheits-grade. Portierbarkeit ist nur möglich, wenn die grafische Spra-che eines Produk-tes ein portierba-res Text – Äquiva-lent hat. Möglich wurde die genaue Festle-gung der Text - Sprachen durch die Definition eines CPU - Modells, das aber nun nicht
Bild 1.2.1: Übersicht der Programmiersprachen für SPS / PLS
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Sept. 2017 1. Übersicht
ASA_Progr_Spr.doc 5
den vorhandenen Produkten entsprach. Für die SIMATIC wurde als "STEP7" ein SW - Paket entwickelt, das zur Norm "hinführt", ihr aber noch nicht ganz entspricht (z.B. AWL). Um die heutige S7 auch in der Prozessleittechnik einsetzen zu können wurden - die Projekt - Abwicklung ergänzt, und - der FUP, der in der SPS bisher ohne Zwisch-enschaltung von "Merkern" nur einen Logik - Pfad („Netzwerk“) darstellen konnte, zum "Continuous" Function Chart“ erweitert, wie er bei PLS schon lange üblich ist. Hier legt der Anwender den Ort der Funktionen / Funktionsbausteine fest. Inzwischen beherrschen auch andere Editoren den CFC, z.B. CoDeSys oder KWsoft. In der Norm 61 131 fehlt er.
Kleinere Hersteller haben sich inzwischen ganz auf die Norm eingestellt und lassen ihre Produkte "zerti-fizieren", um Norm - Kompatibilität nachzuweisen.
"Soft - SPS" (auf PCs laufend) benutzen ebenfalls die Norm - Sprachen, teilweise aber auch die STEP5 - Sprachen, sowie C, C++ und andere.
Die Norm 61 131 unterstützt die Strukturierung einer Automatisierungsaufgabe durch ihre SW - Struktur, in der z.B. eine Antriebssteuerung durch einen Funktionsbaustein (oder ein Programm) realisiert werden kann. Das erlaubt die "top-down" bzw. "bottom-up" Methode beim Engineering (Bild 2.1):
Die Gesamt-Aufgabe wird zergliedert (top-down) bis in bereits vorhan-dene oder leicht realisier-bare Funktions-Bausteine od. Programme, und von unten beginnend zu-sammengesetzt. (bottom-up).
PLS - Systeme verwenden zunehmend die Spra-chen der Norm, sind aber noch selten voll kompatibel. Hier ist eigentlich nur die Funktionsbaustein-Sprache „state of the art". Ausserdem bieten sie: - Hilfsmittel für die Gesamtplanung (z.B. eine Daten-
bank für alle Komponenten, die später im Betrieb für das Asset Management nutzbar ist, und
- Möglichkeiten für die Feld - Planung einschließlich automatischer Erstellung von Anschlussplänen.
Der Funktionsplan nach DIN 40719 wurde durch GRAPHCET mit anderer, mächtigerer Syntax ersetzt, nicht kompatibel zur AS. Erst jetzt (2017) werden erste Editoren zur Erzeugung eines lauffähigen Codes entwickelt.
Die Struktur einer Steuerung wurde schon als Blockbild. In heutigen Engineeringtools übernehmen Projekt-Bäume diese Aufgabe.
1.3 Beitrag der SW zur Leitanlagenqualität.
Die Eigenschaften der verwendeten Sprache und die Vorgehensweise beim Realisieren haben Ein-fluss auf Qualität und Handhabbarkeit des program-mierten Produkts. Nachfolgend sind die wichtigsten Punkte für Automatisierungssysteme aufgeführt.
Die wichtigste Forderung an eine erstellte SW ist es, dass die Aufgabenstellung vollständig erfüllt wird und wirtschaftlich erstellt werden kann.
Das beginnt mit der Vereinbarung der genauen Auf-gabenstellung. Hier helfen eine klare Strukturierung, ggfs. ein Zustandsgraph oder / und ein Entwurf in Grafcet. Aber auch die Ablauf- und die Funktions-bausteinsprache der der DIN 61 131 können Verfahrens- und Maschinentechniker meist eher lesen als ein Programmlisting oder gar eine AWL.
In Grafcet kann man auch dadurch struktu-rieren, dass man zuerst eine Grobplanung mit „Makroschritten“ macht (M3 in Bild 1.3.1), in denen verwirrende Details weggelassen werden. Diese werden erst später Stück für Stück geklärt („Expansion“).
Durch Zergliederung komplexer Aufgaben erhält man überschaubare Teilaufgaben bis hin zu vor-handenen Standardfunktionen (top-down in Bild 1.2.2). Hier sollte „Wiederholtechnik“ angestrebt werden: Häufige Verwendung erprobter Funktionen erspart immer wieder neuen Engineeringaufwand und die Gefahr von Fehlfunktionen. Die DIN 61 131 unterstützt das durch ihre Ausrichtung auf „Funk-tionsbausteine“, deren innere Funktionen „gekap-selt“ und „verborgen“ sind.
Eine „kalte“ Erprobung (ohne Prozess) erspart Betriebskosten und evtl. sogar kostspielige Schä-den. Dazu bieten viele Editoren heute einen Simu-lationsbetrieb vor dem Hinunterladen des Pro-gramms auf den Controller an. Echt wäre eine solche Erprobung aber nur mit einem Anlagen-modell, das sich jedoch bei den meist nur einmal auftretenden Anwendungen kaum lohnt. Hier gibt es Entwicklungen zu leicht parametrierbaren Prozess-modellen für sich ähnliche Aufgaben.
Zur Laufzeit eines Programms erwartet man bei Prozessstörungen Hilfe beim Erkennen des Prozesszustands. Unmengen von Einzelmeldun-gen sind da nicht hilfreich. Hier sind Ablaufsteue-rungen vorteilhaft, weil ihren Schritten eindeutig Prozesszustände zugeordnet werden können. Die Ablaufsprache der DIN 61 131 unterstützt die gezielte Meldung durch „Anzeigevariable“ im Aktionsblock.
To
p –
Do
wn
-E
ntw
urf
(fun
ktiona
le Z
erle
gun
g)
To
p –
Do
wn
-E
ntw
urf
(fun
ktiona
le Z
erle
gun
g)
zerlegen
in:
zerlegen
in:
Gesamtaufgabe
- Gesamte Funktionalität,
- Schnittstellen nach außen
Gesamtaufgabe
- Gesamte Funktionalität,
- Schnittstellen nach außen
Standard-
Funktionen,
Funktionsbaust.
Standard-
Funktionen,
Funktionsbaust.
zerlegen
in:
Teilaufgabe
(z.B. Programm)
- Funktionalität
- Schnittstellen
Teilaufgabe
(z.B. Programm)
- Funktionalität
- Schnittstellen
Teilaufgabe
(z.B. Programm)
- Funktionalität
- Schnittstellen
Teilaufgabe
(z.B. Programm)
- Funktionalität
- Schnittstellen
Funktionale
Einheit
entält AS, FBs
Funktionale
Einheit
entält AS, FBs
Funktionale
Einheit
entält AS, FBs
Funktionale
Einheit
entält AS, FBs
Funktionale
Einheit
entält AS, FBs
Funktionale
Einheit
entält AS, FBs
Standard-
Funktionen,
Funktionsbaust.
Standard-
Funktionen,
Funktionsbaust. Bo
tto
m-
up
Zu
ord
nun
g z
u P
OE
s
Bo
tto
m-
up
Zu
ord
nun
g z
u P
OE
s
Bild 1.2.2: Zergliederung
Bild 1.3.1: Grafcet- Grob- Planung mit Makro-Schritten
Programmiersprachen Automatisierungssysteme DHBW Mannheim 1. Übersicht Erich Kleiner, Sept. 2017
6 AS_Syst_Komm.doc
1.4 Anwendungsbeispiele Zur Vertiefung nachfolgend einige Beispiele. Soweit zeitlich möglich werden sie in der Vorlesung bear-beitet.
1.4.1: Wasserpumpen Zwei redundante Versorgungspumpen mit je einem Absperrschieber vor und hinter Pumpe, normaler-weise nur eine in Betrieb. Alle Antriebe 400 V 3~, Motorstarter, einzeln von Hand steuerbar. Feste An-fahrreihenfolge: Schieber ZU, Pumpe EIN, Schieber AUF. Aktuell betriebene Pumpe vorwählbar, bei ihrer Störung Umschaltung auf andere Pumpe. Entwurf: Hierarchische Gliederung in Strukturbild mit „Kästchen“ für Steuerungsteile unter Verwen-dung von Standard-Funktionsbausteinen für die Antriebe. Frage: Welche Steuerungsart für welche Aufgabe? Programmierung in welcher Sprache? 1.4.2: Molkerei-Tanks Eine Molkerei benutzt drei Tanks für die Zwischen-lagerung angelieferter Produkte, siehe Bild: Der Inhalt von Tankwagen wird über eine Ansaug-leitung und eine Pumpe über eine Sammelleitung in die Tanks gefüllt. Vor und nach jedem Füllvorgang für einen Tank müssen Leitung und Pumpe gespült werden. Dies erfordert einen Ablauf: Tankventil zu, spülen in umgekehrter Richtung, Ablauf des Spül-Wassers durch Belüftung der Rohre. Entwurf: Zustandsgraph mit allen Zuständen und erlaubten Übergängen, Strukturbild mit Steuerungs-teilen und Angabe der jeweiligen Steuerungsart. Die Einzelantriebe brauchen keine Standard-Funktionsbausteine (zur Einzelbedienung). 1.4.3: Bohrvorgang In einer Fertigungsstraße wird ein Werkstück zu einer Bohrvorrichtung transportiert, gebohrt, und dann zum Fräsen weitertransportiert, usw. Zum Bohren holt es ein Zylinder vom Band und spannt es, der Bohrmaschinenmotor wird einge-schaltet und der Vorschub bis zum unteren An-schlag bewegt, dann zur Ruhelage zurückgezogen und der Motor abgeschaltet. Nun wird der Spanner zurückgezogen und der Auswerfer schiebt das Werkstück auf das Band zurück. Fertig: wenn er wieder in Ruhelage ist (siehe Bild nächste Spalte).
Entwurf: Grobablauf mit Grafcet-Makroschritten, Feinablauf mit Grafcet- Expansion. Frage: Programmierung in welcher Sprache?
2. Die Norm DIN EN (IEC) 61131 2.1 Inhalt, Gliederung
Für "Speicher - programmierbare Steuerungen" wurde unter Mitwirkung nationaler Normungsgremi-en bei IEC eine Norm geschaffen, die inzwischen deutsche und Europa - Norm ist unter "DIN EN 61131 "Speicherprogrammierbare Steuerungen". Nach derzeitigem Stand (Juli. 2013) enthält sie in der deutschen Fassung folgende Teile:
Teil 1: Allgemeine Informationen (1994)
und Entwurf DIN IEC 61131 (2001-04): Geltungsbereich, Definitionen, Eigenschaften Beiblatt 1: Leitfaden für Anwender (1996)
(zur gesamten Norm, bei IEC: Teil 4) Teil 2: Betriebsmittelanforderungen u. Prüfungen (2001) mit europ. Änderung /A11 (1995)
und Berichtigungen (1998) 2. Ausgabe als E DIN IEC 65B/350/CD (1999)
Teil 3: Programmiersprachen (2003) Modelle, Elemente, Sprachen, Beispiele Beiblatt 1: Leitfaden zur Anwendung und Implementierung von Sprachen (2005) Teil 5: Kommunikation (2001)
Begriffe, Modelle, Systemkommunikation, Komm. - Funktionsbausteine, Parameter Teil 6: Funktionale Sicherheit Teil 7: Fuzzy-Control-Programmierung (2001)
Teil 9: Schnittstellen für die Kommunikation mit kleinen Sensoren Nachfolgend werden die Festlegungen dieser Norm zu Sprachen erläutert, wie sie in Teil 3 und dem dazugehörigen Beiblatt 1 angegeben sind.
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 7
2.2 Software - Modell Der Norm (IEC) DIN EN 61131 liegt ein SW - Modell zu Grunde, das die Sprachelemente und ihre mög-liche Gliederung festlegt (Bild 2.2.1). Bild 2.2.1: SW - Modell der Norm Die grundlegenden Sprachelemente eines SPS-Programmsystems nach DIN EN 61131-3 sind: zu konfigurierende Elemente: Konfigurationen,
Ressourcen, Tasks, globale Variable und Zu-griffspfade, sowie
zu programmierende Elemente: Programme, Funktionsbausteine und Funktionen - auch
Programm-Organisations-Einheiten (POE) genannt.
2.2.1 Konfigurationselemente:
Das oberste Konfigurationselement bildet die Konfiguration. Sie besitzt drei unterschiedliche Aspekte:
sie repräsentiert ein Gerät, bestehend aus Sub-systemen, Spannungsversorgung etc.,
sie repräsentiert ladbare Information, bestehend aus ausführbarem Code, Initialisierungswerten etc. und
sie besitzt Ausführungskontrollattribute, die es er-lauben, die SPS insgesamt zu starten und zu stoppen.
Eine SPS (oder Konfiguration) besteht aus unterschiedlichen Subsystemen, anderen Modulen und Interfaces, genannt: Ressource. Diese besitzt zwei unterschiedliche
Aspekte:
sie repräsentiert ladbare Information, bestehend aus ausführbarem Code, Initialisierungswerten etc. und
sie besitzt Ausführungskontrollattribute, die es erlauben, ein SPS - Subsystem zu starten und zu stoppen.
Falls eine Konfiguration nur eine Ressource besitzt, so kann auf die Angabe der Ressource verzichtet werden.
Eine Task ist in der Norm als ein Ressourcen - Kon-trollelement definiert, das in der Lage ist, die Aus-führung von Programm-Organisations-Einheiten an-zustoßen. Die somit einer Task zugeordneten Pro-gramme, Funktionsbausteine und Funktionen werd-en entweder zyklisch (d.h. periodisch nach bestimm-ten Zeitintervallen) oder event-gesteuert (d.h. mit der Flanke einer spezifizierten Bool'schen Variablen) ablauffähig. Falls zu einem Zeitpunkt mehr als eine Task ablauffähig sein sollte, so entscheidet eine vom Programmierer konfigurierbare Taskpriorität, welche Task nun tatsächlich aktiv wird. Beim Task-wechsel kann preemptive scheduling (bevorrechtigt) oder non-preemptive scheduling (nicht bevorrecht-igt) angewandt werden. Beim non-preemptive sche-duling kann eine ablauffähige Task höherer Priorität eine momentan aktive Task nicht sofort unterbrech-en, sondern muß gegebenenfalls warten, bis das Ende der einer Task mit niederer Priorität zugeord-neten Programm-Organisations-Einheit erreicht ist. Falls dann mehr als eine Task mit gleicher Priorität ablauffähig sein sollten, so wird die Task mit der längsten Wartezeit ausgeführt. Beim preemptive-scheduling kann eine ablauffähige Task eine aktive andere mit niedrigerer Priorität sofort unterbrechen und somit selbst aktiv werden. Konfigurationen und Ressourcen können über ein spezielles Operator - Interface, eine Programmier- und Testkonsole oder das der SPS - Anlage eigene Betriebssystem gestartet oder gestoppt werden. Beim Start einer Konfiguration werden implizit auch alle ihr zugehörigen Ressourcen gestartet. Der Start einer Ressource versetzt alle in ihr enthaltenen Tasks in den Zustand “ablauffähig”.
Globale Variable können sowohl Ressourcen- als auch Konfigurations - weit deklariert werden. 2.2.2: Programmelemente Die eigentlichen (programmierten) Anwendungs-funktionen sind in den Programm - Organisations-Einheiten (Programme, Funktionen und Funktions-bausteine) untergebracht. Diese Programm-Organi-sations-Einheiten können entweder als Standard-Bausteine vom Hersteller mitgeliefert oder vom Anwender definiert werden. Dabei können auch bereits existente Bausteine zur Definition neuer mit verwendet werden. Eine rekursive Verwendung ist allerdings ausgeschlossen.
Eine Funktion liefert nach Ausführung genau ein Er-gebnis mit dem Funktionstyp. Sie besitzt keine inter-ne Zustandsinformation. Zwei beliebige Aufrufe ein-er Funktion mit jeweils gleichen Eingangsparame-tern liefern stets das gleiche Ergebnis. Eine Funktion kann von jeder anderen Programm - Organisations -Einheit aufgerufen werden. Typische Standardfunk-tionen sind beispielsweise sin und cos oder UND. Der Anwender kann (aus Standard - Funktionen) auch eigene Funktionen bilden, z.B. "2 von 4".
Funktion
Funktions
baust.
Programm
Konfiguration
Ressource 2
Task Task
Prgr. Progr. Progr.FB
V V V V
Zugriffspfade
V
FB
F
F
RESOURCE STATION_1 RESOURCE STATION_2
Ressource 1
SLOW_1 FAST_1
V Globale
direkt deklarierte Variablen %V
FB
F
Programmiersprachen Automatisierungssysteme DHBW Mannheim 2. Norm DIN EN 61131 Erich Kleiner, Dezember 2002
8 AS_Syst_Komm.doc
Funktionsbausteine liefern bei Ausführung ein oder mehrere Ergebnis - Werte und speichern "interne" Daten, die sie im nächsten Rechen - Zyklus wieder benutzen (z.B. ein Integrator). Zur Verwendung von Funktionsbausteinen wird zunächst ein “Funktions-bausteintyp” ausgewählt, und dann für eine spezielle Aufgabe ("Instanz") angewendet, "instanziiert" (Bild 2.2.2.1). So können beliebig viele Funktionsbausteine eines bestimmten Funktionsbausteintyps erzeugt werden. Diese “Funktionsbausteininstanzen” (Kopien) besitz-en jeweils die gleiche Logik, aber eigene interne Datenbereiche. Von einem Aufruf zum nächsten rettet eine Funktionsbausteininstanz den ihr eigenen lokalen Datenbereich. Im Gegensatz zu Funktionen, die keine internen Daten besitzen und nicht instanziiert werden, liefern zwei Aufrufe desselben Funktionsbausteins mit jeweils gleichen Eingangs-daten (selbst wenn sie dieselbe Instanz aufrufen) im Allgemeinfall unterschiedliche Ergebnisse Bild 2.2.2.1: Funktionsbaustein als "Instanz" Funktionsbausteine bilden das wichtigste Struktu-rierungselement für ein Norm - konformes Pro-grammsystem. Typische Basis - Standardfunktions-bausteine sind beispielsweise Flipflops, Zähl- und Zeitbausteine. Beispiel für einen komplexen Funk-tionsbaustein ist eine Antriebssteuerung. Funktionsbausteine (-Typen) können auch durch den Anwender erzeugt werden. Außer zur wieder-holten Anwendung kann ein solcher "selbst er-zeugter" Funktionsbaustein auch einfach zur Unter-gliederung eines Programms verwendet werden. Diese Eigenschaften von Funktionsbausteinen sind von der objektorientierten Programmierung (OOP) abgeleitet Der Funktionsbaustein-Typ ist einer Klasse ähnlich, die die Datenstruktur und die Be-rechtigungsmethode im Rumpf des Funktions-bausteins definiert. Die einzelnen Objekte werden durch die privaten Datenbereiche der einzelnen Funktionsbaustein - Instanzen repräsentiert Diese Daten können von außerhalb des Funktions-baustein-Rumpfes nur in einer kontrollierten Weise modifiziert werden. Dies unterstützt die Prinzipien des Software - Engineering der Kapselung und des Verbergens von Informationen, ein Schlüsselele-
ment der OOP. Ein weiteres Gebiet von Interesse für die Verwen-dung von Funktionsbausteinen ist der kontrollierte Zugriff auf ein gemeinsam genutztes Gerät. Hier er-hält eine einzelne Funktionsbaustein - Instanz die exklusive Kontrolle über das besagte Gerät und arbeitet wie eine "Semaphore", wobei auf das Gerät
nur zugegriffen werden kann, wenn die entsprechen-de Funktionsbaustein - Instanz aufgerufen wird. Der Vorteil beim Anwenden von Funktionsbaustein-Instanzen ist, dass die Funktionalität, die mit einer definierten Datenstruktur verbunden ist, nur einmal deklariert werden muß und dass sie dann in mehreren Instanzen innerhalb eines SPS - Programms unabhängig angewendet werden kann. Dieser "Prototyp" ist im Funktionsbaustein - Typ festgehalten und kann so oft wie nötig durch dekla-rieren von Instanzen dieses Typs wiederverwendet werden. So kann der Anwender sicher sein, dass es in keiner der Funktionsbaustein - Instanzen Fehler gibt, solange es keine Fehler im zugehörigen Funk-tionsbaustein - Typ gibt. Funktionsbaustein - Instanzen können auch hilfreich beim Testen und Fehlersuchen sein, da man zum Beobachten und zur On-line-Änderung leicht auf den ganzen Satz der aktuellen Zustandsdaten der Instanz zugreifen kann. Die Instanzen der Funktionsbausteine sind eine Besonderheit der vorliegenden Norm; für die es in den prozeduralen Programmiersprachen wie Pascal oder C keine Entsprechung gibt. Die Instanzenbildung von Funktionsbausteinen ist für ältere / kleinere programmierbare Steuerungen eine Erweiterung der Fähigkeiten. In vielen aktuellen Realisierungen steht nur eine feste Anzahl von Instanzen für jeden Funktionsbaustein - Typ zur Verfügung, und es können keine zusätzlichen In-stanzen erzeugt werden. Vom Anwender definierte Funktionsbausteine, die in einer unbegrenzten Anzahl instanziiert werden können, sind ebenfalls eine wichtige Erweiterung für viele bestehende Gerätefamilien. Programme sind Funktionsbausteinen sehr ähnlich. Sie weisen nur folgende Unterschiede auf:
die Schlüsselwörter für die Deklaration sind unterschiedlich,
Programme müssen in einer Ressourcen - Umgebung eingerichtet werden. Daraus folgt, dass Programme von keiner Programm - Orga-nisations - Einheit aufgerufen werden können. Funktionsbausteine werden dagegen innerhalb von Programmen oder anderen Funktionsbau-
steinen aufgerufen,
direkt adressierte Variable (direkte Angabe von Ein/Ausgangskanälen) dürfen nur auf Programm - Ebene verwendet werden.
Außerdem untergliedern die Elemente der AS (Ablauf - Sprache) ein Programm oder einen Funktionsbaustein. Wenn aber irgend ein Teil einer POE (hier: nur Programm oder Funktionsbaustein) durch AS - Elemente gegliedert ist, so muss die ganze POE so gegliedert werden.
SR
S1 Q1
R
%IX1
%IX2
FF75
Formaler Name
(Deklaration,
Typ)
Aktueller Name
(Aufruf, „Instanz“)
Eingangssignale Ausgangssignal(e)
%QX3
= Parameter für Funkt.baustein - Aufruf
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 9
2.3 Datentypen
Die Norm erkennt eine Reihe von elementaren (vor - definierten) Datentypen an. Zusätzlich sind allgemeine (generische) Datentypen definiert. 2.3.1 Elementare Datentypen: Tabelle 2.3.1
2.3.2 Allgemeine (generische) Datentypen
Für "überladene" (Datentyp - unabhängige) Funk-tionen / Funktionsbausteine können allgemeine (oder "generische") Datentypen eingesetzt sein. Ihre Typen zeigt Tabelle 2.3.2 in einer Hierarchie. Diese Datentypen dürfen nicht für durch den Anwender erzeugte Funktionen / Funktionsbau-steine angewandt werden. 2.3.3 Abgeleitete Datentypen Aus den elementaren Datentypen kann der Anwender zusätzliche Datentypen ableiten. Tabelle 2.3.3 zeigt die Möglichkeiten dazu an Beispielen: 1 Ein neuer Typ - Name ("R") wird dem Typ REAL
zugeordnet. 2 Für den Typ ANALOG_SIGNAL_TYPE gibt es
nur die Werte "SINGLE_ENDED" und "DIFFERENTIAL"
3 Für den Typ ANALOG_DATA sind nur Werte
zwischen -4095 und 4095 erlaubt. 4 Der Typ ANAOG_16_INPUT_DATA ist ein Feld
(Array) mit 16 Werten, jeder vom Typ ANALOG_DATA (siehe 3.).
5 Der Typ STAMPED_REAL ist eine "Struktur",
d.h. eine Kombination verschiedener Typen, hier REAL und DATE_AND_TIME
(z.B. zum Speichern von Daten für eine Melde-folge)
Ein Verfahren zur Festlegung zusätzlicher durch den Hersteller oder Anwender "abgeleitete" Datentypen ist ebenfalls definiert. Tabelle 2.3.2 Tabelle 2.3.3
ANY
ANY_NUM
ANY_REAL
LREAL
REAL
ANY_INT
LINT, DINT, INT, SINT
ULINT, UDINT, UINT, USINT
ANY_BIT
LWORD, DWORD, WORD, BYTE, BOOL
STRING
ANY_DATE
DATE_AND_TIME
DATE
TIME_OF_DAY
TIME
1 Direkte Ableitung von elementaren Typen, z.B.:
TYPE R : REAL ; END_TYPE
2 Datentypen für Aufzählungen, z.B.:
TYPE ANALOG_SIGNAL_TYPE : (SINGLE_ENDED,
DIFFERENTIAL) ; END_TYPE
3 Datentypen für Bereich, z.B.:
TYPE ANALOG_DATA : INT (-4095..4095) ; END_TYPE
4 Datentypen für Feld, z.B.:
TYPE ANALOG_16_INPUT_DATA : ARRAY [1..16]
OF ANALOG_DATA ; END_TYPE
5 Datentypen für Strukturen, z.B. Real-Wert mit Zeitstempel:
TYPE STAMPED_REAL
STRUCT
VALUE : REAL;
STAMP : DATE_AND_TIME;
END_STRUCT
END_TYPE
Schlüsselwort Datentyp Wertbereich Default
BOOL Boolean 0 / 1 0
SINT Short integer ( 8 bit) -128 .. 127 0
INT Integer (16 bit) -32 768 ... 32 767 0
DINT Double integer (32 bit) -231 .. 231 -1 0
LINT Long integer (64 bit) -263 .. 263 -1 0
USINT Unsigned short integer ( 8 bit 0 .. 127 0
UINT Unsigned integer (16 bit) 0 .. 32 767 0
UDINT Unsigned long integer (32 bit) 0 .. 231 -1 0
ULINT Unsigned long integer (64 bit) 0 .. 263 -1 0
REAL Real numbers (16 bit, Gleitkomma) +10+38 (1 zu 223 ~ 7 Dez.Stell.) 0.0
LREAL Long reals (32 bit, Gleitkomma) +10 +308(1zu 252 ~16 Dez.Stell.) 0.0
TIME Duration Produkt - abhängig T#0s
DATE Date (only) Produkt - abhängig D#0001-01-01
TIME_OF_DAY (TD) Time of day (only) Produkt - abhängig TOD#00:00:00
DATE_AND_TIME (DT) Date and time of day Produkt - abhängig DT#0001-01-01-00:00:00
STRING Variable-length single-byte character string 8 bit ‘ ‘ (leerer String)
WSTRING Variable-length double-byte character string 16 bit ‘ ‘ (leerer String)
BYTE Bit string of length 8 8 bit, kein numer. Wert 0
WORD Bit string of length 16 16 bit, kein numer. Wert 0
DWORD Bit string of length 32 32 bit, kein numer. Wert 0
LWORD Bit string of length 64 64 bit, kein numer. Wert 0
Programmiersprachen Automatisierungssysteme DHBW Mannheim 2. Norm DIN EN 61131 Erich Kleiner, Dezember 2002
10 AS_Syst_Komm.doc
2.4 Darstellungen 2.4.1 Variablen Variablen sind solche Daten - Elemente, die mit Eingängen, Aus-gängen oder Speich-erplätzen verbunden sind und deren aktu-ellen Wert enthalten. Bild 2.4.1 zeigt die in der Norm gegebenen Möglichkeiten. In den POEs wird meist die symbolische Darstellung mit mne-motechnisch gewählt-en Bezeichnern ver-wendet. Für Ein / Aus-gänge müssen dann in Konfiguration oder Ressource Geräte - Kanäle zugeordnet werden, für "Merker" erfolgt dies meist automatisch. Nur in Programmen können mit dem Kennzeichen % auch direkt "Orte" zugewiesen werden, also Ein / Ausgangskanäle so-wie - wenn im Produkt vorgesehen - der Speicher-platz für Merker. 2.4.2 "Externe" Daten Darunter werden Angaben verstanden, die in das Pro-gramm geschrieben, aber während dessen Ablauf von diesem nicht geändert werd-en, z.B. Kommentare. Bild 2.4.2 zeigt die wich-tigsten Festlegungen mit Beispielen.
Die Angabe für Ein/Ausgabegeräte - Kanäle ist vom Produkt abhängig, und kann z.B. Bus-Nr., Baugruppenträger, Gerät, Kanal bedeuten, jeweils durch einen Punkt getrennt.
Bild 2.4.1: Variablen - Darstellungen
Variablen Daten die mit Eingängen / Ausgängen / Speicherplatz verbunden sind
Einzelelement - Variable: stellt ein einzelnes Datenelement dar (elementarer oder abgeleiteter Datentyp)
symbolische Darstellung: durch „Bezeichner“: mind. 6 Groß / Kleinbuchstaben, Ziffern, Unterstrich, z.B.:
Taste_1 (Beginn: Buchstabe oder Unterstrich, Taste = TASTE,
Keine Leerzeichen im Bezeichner erlaubt!)
direkte Darstellung: Direkte Angabe eines Eingangs / Ausgangskanals oder Speicherplatz („Merker“):
Kennzeichnung „direkte Darstellung“
Speicherort: I = Eingang, Q = Ausgang, M = Merker
Signalart: X (oder kein Zeichen) = Einzelbit, B = Byte (8 Bit),
W = Wort (16 Bit), D = Doppelwort (32 Bit), L = Langwort (64 Bit)
Zählziffer (ggf. gegliedert: 1.2 = 1. Eingabegerät, 2. Kanal,
Produkt - ahängig)
% I X 1.2
Zuordnung von symbolischer Variablen zu „Ort“ mit „at“: Taste_1 at %IX1.3
Multielement - Variable
Feld (en: Array): Sammlung von Datenelementen des gleichen Datentyps, z.B.:
VAR speeds : REAL[0..3] := (0.0, 1.0, 3.0, 9.0); END_VAR
Name, Typ, Element- Wertzuweisungen
Nummern
Struktur (en: Structure): Deklaration eines Typs, der vorher als Datentyp festgelegt wurde
Eigenschaft/ Bedeutung: Beispiele:
Numerische Literale: ganzzahlig -12 0 123_456 +986
reell -12.0 0.0 0.456
reell mit Exponenten -1.34 E-12 (= 1.34 * 10-12)
Basis 2 2#1111_1111 (= 255 dezimal)
Basis 8 8#377 (= 255 dezimal)
Basis 16 16#FF (= 255 dezimal)
Bool‘sche Null / Eins 0 1 (entspr. FALSE TRUE)
Bool‘sches FALSE / TRUE FALSE TRUE (entspr. 0 1)
Zeichenfolge: leere Zeichenfolge ‘‘
mit 1 Zeichen: A ‘A‘
mit 1 Leerzeichen ‘ ‘
Zeit - Dauer: 25 Std. u. 12 Minuten T#25h12m / t#25h12m / T25h_12m
Tag / Sekunde / Millsek.: d / s / ms
Datum / Tageszeit: Datum (2. 11. 2002) D#2001-11-02 oder DATE#....
Time of day (15:36:55.12) TOD#15:36:55.12
Date and Time DT#2001-11-02-15:36:55.12
oder DATE_AND_TIME#....
Kommentar: (* Text *)
Bild 2.4.2: Darstellung externer Daten
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 11
2.5 Variablen - Deklaration Am Beginn der Dekla-ration einer Programm - Organisationseinheit Pro-gramm, Funktionsbau-stein oder Funktion ist mindestens ein Dekla-rationsteil nötig, um die durch die POE benutzen Variablen zu deklarieren. Bei der Anwendung einer "vorhandenen" Einheit (Standard - Funktion / - Funktionsbaustein oder anderswo deklariert) brauchen nur die Parameter zugeordnet zu werden. Die Variablen - Deklaration weist den Variablen Typen und ggf. den physikali-schen oder logischen Speicherplatz zu. Dies erfolgt mit Schlüsselworten (Bild 2.5.1) in textlicher (Bild 2.5.2) oder grafischer Form (Bild 2.5.3). Wenn eine Variable bei Kaltstart ihrer POE (nicht bei normalem wiederholten Durchlauf) einen anderen Wert annehmen soll als den Default - Wert (Tabelle 2.3.1), so kann sie mit dem anderen Wert initialisiert werden. "RETAIN" hinter VAR bedeutet, dass bei einem Warmstart der Wert übernommen wird, den die Variable beim Stoppen hatte. Über die Variablendeklaration können auch Werte für Konstanten (z.B. PI) festgelegt werden: Funktionsbaustein - Typ und Parameter können initialisiert werden, z.B. für den Regler "TempReg" vom Typ "PI" die Werte für Proportional - Verstärkung und Integrationszeit: Tabelle 2.5.1 zeigt Beispiele für Typ - Zuweisung
VAR CONSTANT PI : REAL := 3.141592 VAR TempReg PIR := (PropBand := 2.5; INTEGRAL := T#5s); END_VAR
Zu beschreibende POE (Programm - Organisations - Einheit)
nur innerhalb POE verwendet
von aussen, in POE nicht änderbar
in POE erzeugt, nach aussen
von / nach aussen, von POE änderbar
global definiert, in POE änderbar
temporär: neu in jedem Durchgang
zusätzlich hinter VAR..: nicht veränderbar
zusätzlich: für neuen Warmstart speichern
Ende einer Deklarationsart
VAR
VAR_INPUT
VAR_OUTPUT
VAR_IN_OUT
VAR_EXTERNAL
VAR_TEMP
..CONSTANT
..RETAIN
END_VAR
Schlüsselworte
zur Variablen-
Deklaration
VAR_GLOBAL
Konfiguration 2
Zugriffe auf andere Konf.
Konfiguration 1
VAR_ACCESS
VAR_INPUT TASTE1, TASTE2 : BOOL; END_VAR
VAR_OUTPUT STOP : BOOL : = 1; END_VAR
Namen, durch Komma getrennt
Zuordnung
Datentyp
Schlüsselworte
Abschluss einer Deklaration
Zur Initialisierung mit einem von
„default“ abweichenden Anfangswert
Bild 2.5.1: Variablendeklaration
Bild 2.5.2: textliche Variablendeklaration
MIX
BOOL --- TASTE1 STOP --- BOOL :=1
BOOL --- TASTE2
Bild 2.5.3: grafische Variablendeklaration (für Funkt.baustein MIX)
Nr. Deklaration von: Beispiele Erläuterungen
1 direkt dargestellte VAR nicht gepufferte AT %IW6.2 : WORD ; 16-Bit - Folge von Eingang 6.2* (* Nr. Produkt - abhängig) Variablen AT %MW6 : INT; 16-Bit - Integer, Anfangswert = 0, im 6.* „Wort-Speicher“ END_VAR 2 direkt dargestellte VAR RETAIN 16-Bit - folge an Ausgang 5 * gepufferte AT %QW5 : WORD ; bei Warmstart Übernahme des Wertes vom Stopp-Zeitpunkt, Variablen END_VAR bei Kaltstart Initialisierung mit 16-Bit-Folge Wert 0 3 Speicherorte für VAR_GLOBAL symbolische GW_6 AT %IX27 : BOOL ; weist Boole‘scher Variablen „GW_6“ Eingang 27 * zu. Variablen MIX_ON AT %QX14 : BOOL ; weist Boole‘scher Variablen „MIX_ON Ausgang 14 * zu. END_VAR 4 Speicherort für VAR Feld INARY AT %IW6 : deklariert ein Feld von 10 ganzen Zahlen, zugeteilt einem zu- ARRAY [0..9] OF INT ; sammenhängenden Speicherort ab Word - Eing. 6 * END_VAR 5 automatische Speicher- VAR zuteilung für CONDITION : BOOL ; weist der Boole‘schen Variablen CONDITION 1 Bit zu symbolische Variablen AWORD, BWORD : INT; weist den Variablen AWORD und BWORD je 1 Wort zu END_VAR
Programmiersprachen Automatisierungssysteme DHBW Mannheim 2. Norm DIN EN 61131 Erich Kleiner, Dezember 2002
12 AS_Syst_Komm.doc
(Fortsetzung: Beispiele für Typ - Zuweisung) Oft ist es sinnvoll, Variablen beim Start einer POE mit einem bestimmten Wert zu initialisieren. Tabelle 2.6.2: Anfangswert - Zuweisung
6 3 - dimensionales Feld VAR weist der Variablen THREE THREE : ARRAY [1..5, 1..10, 1..2] OF INT ein 3 - dimensionales Feld von END_VAR 100 ganzen Zahlen zu 7 strukturierte VAR weist der Variablen MELD_1 Variable MELD_1 : STAMPED_REAL ; die Struktur STAMPED_REAL zu END_VAR (siehe Typ-Deklaration, Tab. 2.3.3 Fall 5)
Nr. Initialisierung von: Beispiele Erläuterungen
1 direkt dargestellte, VAR AT %X5.1 : BOOL := 1 ; weist Binär - Eingang 5.1 den Anfangs-Wert log. 1 zu nicht gepufferte AT %MW6 : INT := 8 ; initialisiert Wort 6 („Merker 6“) mit der ganzen Zahl 8 Variablen END_VAR 2 direkt dargestellte, VAR RETAIN Beim Kaltstart werden die 8 höchstwertigen Bits der gepufferte AT %QW5 : WORD := 16#FF00 1-Bit - Folge des Ausgangsworts 5 mit 1 initialisiert, und variablen END_VAR die 8 niedrigstwertigen Bits mit 0 3 Speicherort und VAR weist das Ausgangswort 28 der ganzzahligen Variablen Anfangswert für VALVE_POS AT %QW28 : INT := 100 VALVE_POS zu mit einem Anfangswert von 100 symbolische Var. END_VAR 4 Speicherort und VAR OUTARRAY AT %QW6 : weist der Variablen OUTRRAY ab Ausgangswort 6 Anfangswert für ARRAY [0..9] OF INT := 10(1) ; ein Feld von 10 ganzen Zahlen zu, Anfangswert jew. 1 Feld (gleiche Werte) END_VAR 5 Anfangswert für VAR weist 8 Speicherbits Anfangswerte zu: Feld (verschiedene BITS : ARRAY [0..7] OF BOOL := 1,0,0,0,0,1,0,1 BITS [0] := 1, BITS [1] := 0, . . . Werte) END_VAR 6 Symbolische VAR MYBIT : BOOL := 1 ; weist der Variablen MYBIT 1 Bit zu, Anfangswert 1, Variablen OKAY : STRING(10) := ‚OK‘ weist der Variablen OKAY Speich.platz für 10 Zeichen zu, END_VAR nach Initialisierung sind 2 Zeichen belegt mit OK 7 Struktur VAR MELD_1.VALUE := 0 , setzt Anfangswert für VALUE auf 0, MELD_1.STAMP := DT#0001-01-01-00:00; setzt Anfangswert für Datum/Zeit auf 000-.. END_VAR (siehe Typ-Deklaration, Tab. 2.3.3 Fall 5
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 13
2.6 Kommunikations - Modell, Verbindungen SPS - Geräte können gemäß Norm (Teil 5) als Server / Client über ein Kommunikationssystem Daten austauschen. Andere Einrichtungen an die-sem Kommunikationssystem können ebenfalls als Clients Anforderungen an einen SPS Server stellen. Die Kommunikation erfolgt über Kommunikations-kanäle, die durch Funktionsbaustein CONNECT de-finiert werden, und wird durch "Kommunikations - Funktionsbausteine "verdeckt" abgewickelt. Ihre Ein- / Ausgänge werden wie die anderer Funktions - Bausteine verwendet. Für die Adressierung müssen die Programme einer Konfiguration eindeutige Namen haben. Innerhalb des "Kommunikationsmodells" sind in der Norm bestimmte Kommunikationswege und -Verbin-dungen festgelegt: Bild 2.6.2 zeigt Verbindungen zwischen Aus- und Eingängen von Funktionen / Funktionsbausteinen innerhalb eines Funktionsbausteins oder Pro-gramms. Ist eine Verbindung in einem Term einer textlichen Darstellung (siehe Beispiel rechts) oder einem "Strang" einer grafischen Darstellung enthalten (Bild 2.6.2 Fall a), so ist es nicht nötig, eine Variable zu definieren (einen "Merker" zu setzen). Geht eine Verbindung darüber hinaus, so ist eine Variable zu definieren (Bild 2.6.2 Fall b), wenn nicht ein "Continuous Function Block Diagram" verwendet wird, der größere zusammenhängende Logikschalt-ungen ohne Variablen ("Merker") erlaubt. Diese Deklaration der symbolischen Variablen b bewirkt eine automatische Speicherzuteilung. Verbindungen zu Ein / Ausgängen (sowie zu vorge-gebenen Speicherplätzen) können - direkt dargestellt werden (Bild 2.6.3 c) oder - zunächst symbolische deklariert und dann einem
Ort zugeordnet werden (Bild 2.6.3 d). Diese Zuordnung erfolgt in VAR_GLOBAL auf
Konfigurationsebene. Für Verbindungen zwischen Programmen einer Konfiguration (Bild 2.6.4, Fall e) ist eine globale Variable ("VAR_GLOBAL") auf Ebene der Konfi-guration zu deklarieren, und außerdem in jedem beteiligten Programm eine "VAR_EXTERNAL" (siehe Bild 2.5.1). Die Datentypen müssen dabei natürlich gleich sein. Die intensive Anwendung von globalen Variablen widerspricht den Grundsätzen der "Kapselung" und des "Verbergens" von Details zu Gunsten besserer Übersicht. Ausserdem können Zuverlässigkeit, In-standhaltbarkeit und Wiederverwendbarkeit der SW stark eingeschränkt werden. Insbesondere sollte vermieden werden, globale Variablen von mehr als einer Programmstelle aus zu schreiben.
Globale Variable nur einsetzen für: - Zugriffspfade für offene Kommunikation, - Werte von Interesse für mehrere POEs. Wenn die Konsistenz der Daten wichtig ist sollten globale Variablen nie zwischen asynchron laufenden Programmen eingesetzt werden, hier nimmt man besser USEND / URCV (siehe nächste Seite).
X = E3 AND(E1 OR E2)
Bild 2.6.2: interne Verbindungen
Programm,
Funktionsbaustein
a
Programm 1
b
VAR b: BOOL; END_VAR
b
>1& X
E1E2E3
Bild 2.6.4: Verbindungen zwischen Programmen
Bild 2.6.1: Kommunikationsmodell der Norm (erweiterte Darstellung)
Bild 2.6.3: Direkte Darstellung / Zuordnung
Konfiguration 1
Programm 1
FB_X
Ausg.1e
VAR_GLOBAL
e : BOOL ;
END_VAR
Programm 2
FB_Y
Eing. 1e
FB1
VAR_EXTERNAL
e: BOOL; END_VAR
VAR_EXTERNAL
e: BOOL; END_VAR
FB3
Übergeordnete
Steuerung
Kommunikations - System
Client
Anderes
System
SPS 1 SPS 2
ServerClient Client
Prozess
KFB KFB
Kommunikations-
Funkt.-Bausteine
Komm.-Kanal
Konfiguration 1
Programm 1
FB_X Eing.1
Eing.2
(c)
Programm 2
FB_Y
Ausg.1
VAR_INPUT
at %IX1.3 : BOOL ;
d : BOOL ; END_VARFB3
1 2 3 4 Kanal
Eing.Gerät 1
1 2 3 4
Gerät 2 ...
FB1
VAR_GLOBAL at %IX1.4 : BOOL ;
d at %IX1.4 :BOOL ; END_VAR
d%IX1.3
%QW5.4
1 2 3 4
VAR_OUTPUT
at %QW5.4
END_VAR
Ausgabegerät .. 5
Programmiersprachen Automatisierungssysteme DHBW Mannheim 2. Norm DIN EN 61131 Erich Kleiner, Dezember 2002
14 AS_Syst_Komm.doc
Zwischen "Geräten" (Stationen), die an einem Kom-munikationssystem angeschlossen sind, d.h. zwischen Konfigurationen oder Ressourcen, sind zwei Verbindungs - Deklarationen möglich: Fall f in Bild 2.6.5 zeigt eine Verbindung mit Hilfe von Kommunikations - Funktionsbausteinen "USEND" und "URCV". Mit FB "CONNECT" wird die Kommunikation mit einem bestimmten Partner vereinbart, wenn an EN_C eine 1 anliegt. An ID stellt CONNECT eine Kennung für einen zustande ge-kommenen "Kommunikationskanal" den eigentlichen Kommunikationsbausteinen wie USEND und URCV zur Verfügung, die nun den Datenaustausch "ver-deckt" (für den Anwender nicht sichtbar) abwickeln. Die Eingänge von USEND und die Ausgänge von URCV können in Programmen wie die Ein- / Ausgänge anderer Funktionsbausteine behandelt werden. Die Datentypen an SD_i / RD_i müssen natürlich gleich sein. Unter Bild 2.6.5 sind die Bedeutungen der Anschlüsse der im Bild gezeigten Kommunikations-bausteine erläutert. Fall g in Bild 2.6.6 zeigt eine Verbindung über einen "Zugriffspfad". Dabei können direkt deklarierte Variablen oder durch die spezielle Deklaration VAR_ACCESS für einen "Zugriff" zur Verfügung ge-stellte Variablen von speziellen Komm.-Bausteinen gelesen / beschrieben werden. Im Bild wird die im Programm P1 deklarierte Variable g in der Konfiguration als Variable CSX zum Lesen frei gegeben durch die ACCESS - Deklaration. In Programm P3 liest ein Kommunikations - Bau-stein "TO_FB2" vom Typ READ für seinen 1. "Datenpfad" die an VAR_1 angegebene Variable CSX in P1, wobei der Kommunikationskanal mit Hilfe eines (nicht gezeigten) Komm. Funkt. Bau-steins CONNECT aufgebaut wird. Am 1. Datenaus-gang RD_1 steht der Wert von CSX zur Verfügung. Auf diese Weise kann auch direkt auf Variablen in per Feldbus angeschlossenen "intelligenten" Ab-zweigen / Stellantrieben zugegriffen werden. Unter dem Bild sind die READ - Anschlüsse erklärt.
Bild 2.6.5: Verbindungen über Komm.-Funkt.-Bausteine
Konfig. 1
FB_X USEND
ID
R_ID
SD1
. . .
SD i
Konfig. 2
FB_X
Eing.
URCV
ID
R_ID
RD1
. . .
RD i
P1 P3
FB1 SEND1 RCV1 FB2
f
Ausg.
CONNECT
EN_C ..
ID PARTNER
CONNECT
EN_C ..
PARTNER ID
X1 X1
CONNECT: Verbindungsmanagement
PARTNER: Produktspez. Parameter zum Verb.-Aufbau EN_C: Eingang zur Anforderung eines Verb.Aufb. ID: Kennung des "Kommunikations - Kanals, für an Komm. beteiligte Komm-FB wie USEND USEND: (Ungesteuert) Daten senden
ID: Kennung Komm.-Kanal von CONNECT R_ID: Identifikation des zugehörigen Komm. Funktions- Bausteins "am anderen Ende" SDi erweiterbare Daten - Eingänge i = 1 .. URCV: (Ungesteuert Daten empfangen
wie USEND, jedoch: RDi erweiterbare Daten - Ausgänge i = 1 ..
Bild 2.6.6: Verbindung über Zugriffspfad
READ: Daten Lesen
ID: Kennung Komm.-Kanal von CONNECT VAR_i: Variablen - Name (oder Adresse) für Signal i RD_i: Wert von Signal i, gelesen über ACCESS / READ, von Variable gemäß VAR_i (i = 1 ..)
Konfiguration 1
Programm 1
FB_X
Ausg.1
Ausg.2
Konfiguration 2
Programm 3
FB_X
Eing.d
VAR_ACCESS
CSX: P1.g : REAL READ_ONLY;
P1 P3
FB1 FB2
TO_FB2
READRD_i Eing.
VAR_1
. . .
VARi
‘CSX‘
g
ID
Kanal-ID von
CONNECT
CSX (= g)
VAR_OUTPUT
g : BOOL;
END_VAR
Name: Zweck: Erläuterung:
CONNECT Verbindungs - liefert lokale Identifikation eines Kommunikationskanals mit entferntem Gerät management (Kanal wird durch die anderen KFB per Parameter ID / R_ID verwendet) (Auf / Abbau, Nutzung) STATUS Gerätestatus periodische Abfrage des Status (Funktionsfähigkeit) eines entfernten Geräts USTATUS „Ungesteuerte“ (nur auf Anforderung gem. Programm) Status - Abfrage READ Daten lesen fragt bei Aufruf eine / mehrere Variable(n) eines entfernten Gerätes ab WRITE Parameter schreiben schreibt Wert(e) in Variable(n) eines entfernten Gerätes USEND / BSEND progr.* Daten senden sendet Wert / String an ..RCV mit gleichem Namen in entferntem Gerät URCV / BRCV progr. Daten empf. empfängt Wert / String von ..SEND mit gleichem Namen in entf. Gerät (* bei Aufruf durch Programm) SEND synchronisiert steuern sendet an RCV (wie USEND), aber erwartet und empfängt Antwort von RCV RCV synchr. Steuern mit Verr. empf. von SEND (wie URCV) verriegelbar, startet Vorgang, meldet Ergebnis ALARM / NOTIFY programmiertes Melden sendet Wert(e) an entf. Gerät, erwartet Bestätigung (NOTIFY: keine Best.)
Tabelle 2.6 zeigt alle in der Norm festgelegten Kommunikationsbausteine.
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 15
2.7 Funktionen 2.7.1: Standardfunktionen Unter "Funktion" wird in der Norm eine Rechenvor-schrift verstanden, die nur aus den aktuellen Werten der Eingänge ein aktuelles Ergebnis berechnet. Die in Tab. 2.7.1.1 - 2.7.1.3 aufgelisteten Funktionen werden als Standard - Ausstattung einer Norm-gemäßen SPS betrachtet. Die Programm - Dokumentation für textliche und grafische Darstellung ist in der Norm so festgelegt, dass sie durch ein Textprogramm erfolgen kann. Daher sind in Spalte "Symbol" nur bei einigen Funk-tionen solche Symbole angegeben, die in einem Textprogramm vorhanden sind und wahlweise eingesetzt werden können. Alle Funktionen können durch ihren Namen identifiziert werden. In den Tabellen sind in den Symbolen mancher Funktionen, z.B. beim Datentyp - Umsetzer, als Typ - Name die Zeichen * / ** angegeben. Hier sind die jeweiligen Namen, beim Umsetzer z.B. die Datentyp - Bezeichnungen INT / REAL / BCD einzusetzen. Manchmal ist es sinnvoll, Funktionen nur unter be-stimmten Bedingungen zu berechnen (Bild 2.7.1). In der "Kontaktplan - Sprache" (KOP) ist das vor-geschrieben, in der Funktionsbaustein - Sprache (FBS) muss das nach Norm möglich sein. Ist diese Funktionalität in einer Funktion enthalten, so wird diese nur berechnet, wenn Eingang EN (ENable) log. 1 hat.
Ausgang ENO meldet mit log. 1, ob die Berechnung fehlerfrei stattfindet, denn sie kann z.B. durch Bereichsüberschreitung einer Variablen gestört sein.
Name Symb. Datentyp Bezeichnung Formel
Datentyp - Umsetzer
*_TO_**
*/**: INT, REAL, BCD
Numerische Funktionen
ABS ANY_NUM Absolutwert
SQRT ANY_REAL Quadratwurzel
LN ANY_REAL Nat. Logar.
LOG ANY_REAL 10er Logar.
EXP ANY_REAL Nat. Exponent.
SIN ANY_REAL Sinus in rad
COS ANY_REAL Cosinus in rad
TAN ANY_REAL Tangens in rad
ASIN ANY_REAL Arc.Sin.
ACOS ANY_REAL Arc.Cos.
Arithmetische Funktionen
- Eingangsanzahl erweiterbar:
ADD + ANY_NUM Addierer OUT := IN1+IN2+..
MUL * ANY_NUM Multiplizierer OUT := IN1 * IN2*..
- Eingangsanzahl fest:
SUB - ANY_NUM Subtrahierer OUT := IN1 - IN2
DIV / ANY_NUM Dividierer OUT := IN1 / IN2
MOD ANY_NUM Rest einer Divis.
EXPT ** ANY_NUM Exponent
MOVE := ANY_NUM Zuordnung
Tabelle 2.7.1: Standard - Funktionen (1)
Name Datentyp Bezeichnung Symbol
Bool‘sche Funktionen
AND ANY_BIT UND
OR ANY_BIT ODER
XOR ANY_BIT Exclusiv-ODER
NOT ANY_BIT Negation
Auswahlfunktionen
SEL ANY Umschalter
(OUT:=IN0 IF G = 0,
:= IN1 IF G = 1)
MAX ANY_EL. Maximalwert
MIN ANY_EL. Minimalwert
LIMIT ANY_EL. Begrenzer
(OUT := >MN < MX)
MUX ANY Multiplexer
(schaltet den Wert an Ausg.,
der Eing. Nr. „K“ zugeordnet)
SEL
BOOL -- G -- ANY
ANY -- IN0
ANY -- IN1
...
ANY_EL.-- -- ANY_EL.
ANY_EL.--
..(erweiterbar)
LIMIT
ANY_EL -- MN -- ANY_EL.
ANY_EL.-- IN
ANY_EL.-- MX
MUX
ANY_INT-- K --ANY
ANY-- (0)
ANY-- (1)
(erweiterbar)
Name Symb. Bezeichn. Formel
Vergleicher
GT > grösser (IN1 > IN2) & (IN2 > IN3) ..
GE >= grösser/gleich (IN1 >= IN2) & (IN2 >= IN3)..
EQ = Gleich (IN1 = IN2) & (IN2=IN3)..
LE <= kleiner/gleich (IN1 <= IN2) & (IN2 <= IN3)..
LT < kleiner (IN1 < IN2) & (IN2 < IN3)..
NE <> ungleich IN1 <> IN2 (nicht erweiterbar)
Bit - Verschiebungs - Funktionen Beispiel:
SHL *** OUT := IN um N bit nach links
IN
N
String - Funktionen Beispiel:
LEN Str.-Länge A := LEN(‘ASTRING‘)
Funktionen für Zeit / Datums - Datentypen
ANY_ELEM.-- ** -- BOOL
ANY_ELEM.--
(erweiterbar)
Tabelle 2.7.2: Standardfunktionen (2) Tabelle 2.7.3: Standardfunktionen (3)
Bild 2.7.1: Enable - Wirkungsweise
EN ORFehler
z.B. Bereichs -
Überschreitung
AND ENO
nur wenn EN = 1
FunktionsberechnungEingang Ausgang
“OK“
„kann“ verwendet werden
Programmiersprachen Automatisierungssysteme DHBW Mannheim 2. Norm DIN EN 61131 Erich Kleiner, März 2014
16 AS_Syst_Komm.doc
2.7.2: Anwender - definierte Funktionen
Der Anwender kann sich mit Hilfe der Stan-dardfunktionen weitere Funktionen de-klarieren und beliebig einsetzen (Bild 2.7.2). Die Verwendung solcher Funktionen ist im Sinne einer strukturierten Programmierung und erhöht die Übersichtlichkeit der Dokumentation. 2.8 Funktionsbausteine 2.8.1 Standard - Funktionsbausteine Funktionsbausteine sind laut Norm Programm - Organisationseinheiten, die einen oder mehrere Werte liefern, die ein-schließlich intern nötiger Variablen für den nächs-ten Zyklus erhalten bleib-en. Bild 2.8.1 zeigt diejenig-en Funktionsbausteine, die als "Standard" in einer Norm - gemäßen SPS vorhanden sein sollen. Weitere kann der Anwender definieren. "Analoge" Funktionen wie z.B. "Integrator" sind in der Norm nicht als Standard definiert. Im Bild sind die Namen und teils die Eingänge variabel (*), da sie die Wirkungsweise angeben. 2.8.2 Anwender - deklarierte Funktionsbausteine
In der hier beschriebenen „SPS- Norm“ gibt es zwei Bedeutungen für „Funktionsbausteine“: - Komplexe Funktionsbausteine, einsetzbar wie Standard- Funktionsbausteine Beispiel: Grenzsignalbildung mit Logik, die in einem Projekt oft benötigt wird. Es ist einfacher, einen speziellen Funktionsbau-
stein zu erstellen, als jedes Mal diese Logik zu programmieren, siehe Bild 2.8.2 - Unterprogramme für mehrfach nötigte Abläufe, aufgerufen als „Funktionsbausteine“ Beispiel: Ampelsteuerung, bei der „waagerecht“ und senkrecht Auto- und Fußgängerampeln zu steuern sind. Wenn die Abläufe für „AutoAmpel“ und „Fußg.- Ampel“ als Unterprogramme erstellt und vom Hauptprogramm wie Funktionsbausteine aufge- rufen werden, hat man minimalen Programmier- aufwand. Außerdem brauchen Ablaufänderungen nur einmal programmiert werden.
Bild 2.7.2: Anwender - Definition von Funktionen
IA1IA2IO
Anwender - definierte Funktion „AND_OR“
Deklaration
im Funkt.-Plan:
Standardfunktionen / Operatoren
LD IA1
AND IA2...
in der Anweisungsliste:AND
OR OUT
AnwendungAND_OR
IA1IA2IO
OUT OR
AND_OR (IA1 := ......)
Bild 2.8.1: Standard - Funktionsbausteine
Wirkungsweise (Detail- Funktionsplan)
GTIN
H2
H1
L1
L2
GT
LT
LT
AND
AND
OH2
OH1
OL1
OL2
Wirkungsweise (Detail- Funktionsplan)
GTIN
H2
H1
L1
L2
GT
LT
LT
AND
AND
OH2
OH1
OL1
OL2
Symbol:
LIMMON
IN
H2 OH2
H1 OH1
L1 OL1
L2 OL2
Symbol:
LIMMON
IN
H2 OH2
H1 OH1
L1 OL1
L2 OL2
Bild 2.8.2: komplexe Funktionsbausteine
Funktionsbausteine
(Unterprogramme)
- AutoAmpel
Ausgangssituatoin: ROT
über GELB nach GRÜN,
wieder GELB bis ROT
- FußgAmpel
Ausgangssituatoin: ROT
nach GRÜN,
wieder auf ROT
Funktionsbausteine
(Unterprogramme)
- AutoAmpel
Ausgangssituatoin: ROT
über GELB nach GRÜN,
wieder GELB bis ROT
- FußgAmpel
Ausgangssituatoin: ROT
nach GRÜN,
wieder auf ROT
Programm- Struktur:
Hauptprogramm
(Logik, Zeiten)
Auto waagerecht
AutoAmpel
Auto senkerecht
AutoAmpel
Fußg. waagerecht
FußgAmpelFußg senkrecht
FußgAmpel
Programm- Struktur:
Hauptprogramm
(Logik, Zeiten)
Auto waagerecht
AutoAmpel
Auto senkerecht
AutoAmpel
Fußg. waagerecht
FußgAmpelFußg senkrecht
FußgAmpel Bild 2.8.3: Unterprogramme als Funktionsbausteine
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 2. Norm DIN EN 61131
ASA_Progr_Spr.doc 17
3. Text - Sprachen der DIN EN 61131 Die Norm enthält verschiedene Sprachen (Bild 1.1) - textliche: AWL, ST, sowie - grafische: FBS, AS, KOP 3.1 Sprache AWL ( Anweisungsliste) Die Anweisungsliste ist praktisch eine Assembler - Sprache. Es muss jeder Bearbeitungsschritt ange-geben werden. Bild 3.1.1 zeigt den formalen Aufbau: - Marke (Label): Text, dem ein : folgt ("kann" sein), - Operator gemäß Tabelle 3.1, ggf. mit Modifikation, - ein (oder mehrere durch , getrennte) Operand(en), - Kommentar in (*..*) ("kann" sein). Jede Anweisung benötigt eine neue Zeile. Bild 3.1.2 zeigt ein Bei-spiel und die genormten Operatoren (z.B. AND) mit erlaubten Modifika-tionen, z.B. N zu ANDN. So wie die Standard - Funktionen, z.B. AND, als Operatoren geschrie-ben werden, kann man auch Anwender - defi-nierte Funktionen ver-wenden. Dabei wird das aktuelle Ergebnis (aus den vorhergegangenen Zeilen) automatisch als Wert für den ersten Eingang der Funktion verwendet (siehe Bild 3.1.3 unten). Funktionsbausteine kön-nen verschieden aufge-rufen werden, Bild 3.1.3 zeigt das an einem Beispiel. Hier müssen zunächst der Typ "CTU" der An-wendung "C10" zugeord-net werden, sowie die im Programm benutzten Va-riablen A, B, ELAPSED und OUT deklariert werden (im Bild oben rechts). Beim Aufruf selbst müs-sen Variablen aus dem Programm den Ein / Ausgängen des Funk-tionsbausteins zugeord-net werden, was auf ver-schiedene Art erfolgen kann.
Form:
Beispiel:
(Label:) Operator Operand Kommentar
START: LD %IX1 (* Taste *)
ANDN %MX5 (* nicht gesperrt *)
ST %QX2 (* Lüfter EIN *)
„lade“ (nehme) X1 als aktuellen Wert,
verknüpfe: X1 AND NOT X5
„speichere“ Ergebnis in X2
Operat. Modif. Bedeutung
LD N aktueller Wert = Operand
ST N aktuellen Wert in Operanden speichern
S setze Operand = 1 wenn aktueller Wert log. „1“ ist
R setze Operand = o wenn aktueller Wert log. „1“ ist
AND N, ( log. UND
OR N, ( log. ODER
XOR N, ( log. Exclusiv - ODER
NOT log. Negation (bitweise bool‘sche Negation)
ADD ( Addition
SUB ( Subtraktion
MUL ( Multiplikation z.B.: MUL B Ergebnis = akt. Wert * B
DIV ( Division
MOD ( Modulo - Division
GT ( Vergleich: > (ergibt 1 wenn grösser)
GE ( Vergleich: >= (grösser oder gleich)
EQ ( Vergleich: = (gleich)
NE ( Vergleich: < > (ungleich)
LE ( Vergleich: <= (kleiner oder gleich)
LT ( Vergleich: < (kleiner)
JMP C, N Springe zu Label ..
CAL C, N Rufe Funktionsblock auf, Name im Operand
RET C, N gehe zurück von aufgerufener Funktion / FB / Programm
) berechne die eingeklammerte Funktion, Zeile ohne Operand!
Operatoren: Geschachtelt: AND(
LD %IX1
OR %IX2
)
N: Negation, ( Klammer auf, C: nur durchführen, wenn aktueller Wert log. „1“
AND( %IX1
OR %IX2
)
oder:
Bild 3.1.2: Operatoren
Bild 3.1.1: Formaler Aufbau der AWL
Funktionsblock „CTU“
(Vorwärtszähler)
CTU
BOOL -->CU Q -- BOOL
BOOL -- R
INT -- PV CV -- INT
IF R THEN CV := 0;
ELSIF CU AND (CV < Pvmax)
THEN CV := CV + 1;
END_IF
Q := (CV >= PV);
VAR
C10 : CTU;
A, B : INT;
ELAPSED : TIME
OUT : BOOL
END_VAR
CAL C10(%IX10, FALSE, A, OUT)
CAL C10(
CU := %IX10,
Q => OUT)
LD A
ST C10.PV
LD %IX10
ST C10.CU
CAL C10
LD A
PV C10
LD %IX10
CU C10
LIMIT(
IN := B
MN := 1
MX := 5
)
ST A
Funktionsblock - Aufruf
1a) mit nicht - formaler Argumenten - Liste:
1b) mit formaler Argumenten - Liste:
2) mit laden / speichern von Argumenten:
(FB-Name . Anschluß)
3) mit Benutzung der Eingangs-Operatoren:
Funktions - Aufruf
1) mit formaler Argumenten - Liste:
2) mit nicht formaler Liste:
zugrunde liegende Deklaration:
(anzuwendender FB Typ CTU
wird mit Namen C10 deklariert)
LIMIT
ANY* -- MN -- ANY*
ANY* -- IN
ANY* -- MX
(ANY*: elementare Variable,
z.B. REAL, INT)
A:=MIN(MAX(IN,MN), MX)
LD 1
LIMIT B, 5
ST A
Funktion „LIMIT“ (Begrenzung)
Abgrenzungs / Zuordn.Zeichen
z.B. für formale Listen:
:= Eingangs - Zuweisung
=> Ausgangs - Zuweisung
; Statement - Ende
# Anfangswert - Voreinstellung
für Datum / Zeit
Bild 3.1.3: Funktionsbaustein- und Funktionsaufruf in der AWL
Marke Operator Operand Kommentar
Allgemein: A: F V (* A *)
FM V1, V2
Beispiel: Start: LD %IX1.1 (* Taste 1 *)
A/N-Zeichen Funktion, Variable A/N-Zeichen
-Eingang
Semantik: Ergebnis := Ergebnis Operator (Operand)
z.B.: Ergebnis := Ergebnis AND %IX1
„modifiziert“: Ergebnis := Ergebnis ANDN %IX1
geschachtelt: Ergebnis := Ergebnis AND( %IX1
OR %IX2
)
Programmiersprachen Automatisierungssysteme DHBW Mannheim 3. Norm DIN EN 61131, Textsprachen Erich Kleiner, Dezember 2002
18 AS_Syst_Komm.doc
Die in der AWL als Operatoren (Bild 3.1.3) verwendbaren Eingänge von Standard - Funktionsbausteinen (Bild 2.8.1) sind in Tabelle 3.1 in der Reihenfolge ange-geben, die in der AWL unterstellt ist. 3.2 Sprache ST (Strukturierter Text)
Die ST - Sprache entspricht Programmier - Hoch-sprachen, sie besteht aus Ausdrücken. Ein Ausdruck ist ein Konstrukt, das bei Anwendung einen Wert liefert, der einem elementaren oder abgeleiteten Datentyp entspricht. Er besteht aus Operatoren und Operanden. Ein Operand muss ein Literal (2.4.2), eine Variable (2.4.1), ein Funktionsaufruf (2.7) oder ein weiterer Ausdruck sein. Die Operatoren sind in Tabelle 3.2.1 zusammen-gefasst. Die Auswertung eines Ausdrucks besteht aus dem Anwenden der Operatoren auf die Operanden, in der Reihenfolge, die durch die Rangfolge der Operatoren definiert ist, die in Ta-belle 3.2.1 gezeigt ist. Der Operator mit der höchsten Rangfolge in einem Ausdruck wird zuerst angewendet, gefolgt vom Operator der nächstnie-deren Rangfolge, usw. Operatoren mit gleichem Rang werden angewandt, wie sie im Ausdruck von links nach rechst beschrieben sind. Die Anweisungen der Sprache ST sind in Tabelle 3.2.2 zusammengefasst. Jede Anweisung muss mit einem Semikolon abgeschlossen werden.
Bezeichn. Name Eingänge Bezeichn. Name Eing.
Speicher S SR S1, R Pulsgeb. TP IN, PT
R RS S, R1 Einsch.Verz. TON IN, PT
Trigger 0->1 R_TRIG CLK Aussch.Verz. TOF IN, PT
1->0 F_TRIG CLK
Zähler vorw. CTU CU, R, PV
rückw. CTD CD, LD, PV
vorw/rückw. CTUD CU, CD, R, LD, PV
Bild 3.1.3: Funktionsbausteineingänge als Operatoren
Nr. Operation Symbol Rangfolge
1 Klammerung ( Ausdruck ) höchste
2 Funktions -
Auswertung Funktion (Arg.1, Arg.2, ..)
Beispiel: LN(A), MAX(X, Y)
3 Potenzierung **
4 Negation -
5 Komplement NOT
6 Multiplikation *
7 Division /
8 Modulo MOD
9 Addition +
10 Subtraktion -
11 Vergleich <, >, >=, >=
12 Gleichheit =
13 Ungleichheit < >
14 Boole‘sches UND &
15 Boole‘sches UND AND
16 Boole‘sches Ecl. ODER XOR
17 Boole‘sches ODER OR niederste
Tabelle 3.2.1: Operatoren der Sprache ST
Anweisungstyp Beispiel
Zuweisung A := B ; CV := CV + 1; C := SIN(X)
Funktionsbaustein- TON1(IN := %IX5, PT := T#300ms) ;
Aufruf, Ausg.Zuw. A := TON1.Q
RETURN RETURN
IF / THEN D := B*B - 4*A*C
ELSIF, ELSE IF D < 0.0 THEN NROOTS := 0;
ELSIF D = 0.0 THEN
NROOTS := 1
X1 := - B / (2.0 * A) ;
ELSE
...
END_IF
CASE TW := BCD_TO_INT(THUMBWHEEL)
CASE TW OF
1,3 : DISPLAY := OVEN_TEMP ;
2 : DISPLAY := MOTOR_SPEED ;
ELSE DISPLAY := 0
END_CASE
FOR FOR I := 1 TO 100 BY 2 DO
IF ..
END_IF
END_FOR
WHILE WHILE J <= 100 ... DO
J := J + 2 ;
END_WHILE
Wiederholung REPEAT ..
END_REPEAT
Ausgang EXIT EXIT ;
Tabelle 3.2.2: Anweisungen der Sprache ST
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Sept. 2017 3. Norm DIN EN 61131, Textsprachen
ASA_Progr_Spr.doc 19
4 Grafische Sprachen der DIN EN 61131 4.1 Gemeinsame Elemente
Die "Grafik" in den grafischen Sprachen wird nicht durch Zeichenprogramme erzeugt sondern ist eine Interpretation von einem zu Grunde liegenden speziellen Code. Die Darstellungs - Elemente wie z.B. Linie können durch normale Textzeichen oder (erweiterte) Sonder-zeichen realisiert werden. In den grafischen Sprachen wird der Signalfluss durch Linien dargestellt. Bild 4.1.1 zeigt die verschiedenen Möglich-keiten mit Text- und Sonderzeichen. Abbruchstellen können mit "Konnektoren" gekennzeichnet werden. Dadurch erfolgt nicht eine Speicherung oder Datenelement - Zuordnung. Für Sprünge sind Pfeile festgelegt.
Der Signalfluss (FBS) / Stromfluss (KOP) / Aktionsfluss (AS) wird, wie in Bild 4.1.2 gezeigt, von links nach rechts bzw. oben nach unten dargestellt.
Eine (beschränkte) Menge von grafisch miteinander verknüpften Elementen wird Netzwerk genannt (Bild 4.1.3). Es muss sich durch eine verschachtelte AWL darstellen lassen. Manche Editoren erlauben Abzweige zu „Unter-Netzwerken“.
Der Geltungsbereich eines Netzwerks darf sich nur auf die POE (Programm - Organisations - Einheit) beziehen, in der sich das Netzwerk befindet. Die Reihenfolge, in der Netzwerke und ihre Elemente ausgewertet werden, ist nicht notwendigerweise dieselbe Reihenfolge, in der sie mit Marken versehen oder dargestellt werden. Genauso ist es nicht notwendig, dass alle Netzwerke ausgewertet sein müssen, bevor die Auswertung eines bestimmten Netzwerkes wiederholt werden kann. Es gilt für die Netzwerke einer POE: - Kein Element eines Netzwerkes darf ausgewertet
werden, bevor die Zustände aller seiner Eingänge ausgewertet wurden.
- Die Auswertung eines Netzwerk - Elements darf nicht abgeschlossen werden, bevor die Zustände aller seiner Ausgänge ausgewertet wurde.
- Die Auswertung eines Netzwerks ist nicht abgeschlossen, bevor die Ausgänge aller seiner Elemente ausgewertet wurden, auch wenn das Netzwerk ein Element zur Ausführungssteuerung enthält.
Größere Freiheit erlaubt der „Continuous Function Chart“ (CFC), nicht in der Norm aber „Quasi-Norm“. (Bild 4.1.4). Eingänge, Funktionen / Funktionsblöcke und Ausgänge sind frei positionierbar, alle Zwischenergebnisse werden bis zum nächsten Aufruf gespeichert. Die Bearbeitungsreihenfolge muss aber festgelegt werden um Verzögerungen bei
falscher Reihenfolge zu vermeiden. Bild 4.1.5 zeigt, dass hier „Rekursionen“ möglich sind: Rückführungen von Ausgängen auf Eingänge
Linienelemente: Linien Verbindung Kreuzung Ecke Block mit Verbindungen| | +---+
Normale Text-Zeichen: ---- --+-- -|- +-- -| |
| | | -| |
Sonderzeichen
(mit Anw.-definierten):
nicht in der Norm fetgelegt!
„Konnektoren“: (dürfen nicht Speicherung bewirken(Linien - Abbruch) --->MELDG> oder Datenelement - Zuordnung sein!
Sprung: ---START>> (auf „Netzwerk - Marken)
Rücksprung: --<RETURN>
Bild 4.1.1: Elemente der grafischen Sprachen
Bild 4.1.2: Signalfluss
Bild 4.1.3: Netzwerke
Bild 4.1.4: Continuous Function Chart (CFC)
Bild 4.1.5: Rekursion
Programmiersprachen Automatisierungssysteme DHBW Mannheim 4. Norm DIN EN 61131, grafische Sprachen Erich Kleiner, Juli 2013
20 AS_Syst_Komm.doc
4.2 Sprache FBS (Funktions-Baustein-Sprache)
In der FBS werden Prozessor - Operationen (Funktionen und Funktionsbausteine) als Rechtecke dargestellt, die durch Wirkungs-linien ("Signale") miteinander ver-bunden sind. Die Seitenlängen sind nicht festge-legt. Links sind Eingänge, rechts Ausgänge darge-stellt, deren Be-deutung wenn nö-tig durch abge-kürzte Bezeich-nungen dargestellt ist. Bild 4.3.1 zeigt die wichtigsten Regeln, Bild 4.2.2 ein Beispiel. Als Symbole stehen die in Kap. 2 dargestellten Standard - Funktionen / Funktionsbausteine sowie Anwender - deklarierte zur Verfügung. 4.3 Sprache KOP (Kontaktplan) Um solchen SPS - Anwendern, die von der Relais - Technik kommen, das Lesen von SPS - Plänen zu erleichtern, wur-de der KOP mit in die Norm aufgenom-men. Bild 4.3.1 zeigt den Weg vom Wirk-schaltplan über den in "Strompfade" auf-gelösten Stromlauf-plan zum Kontakt-plan, der die "Strom-pfade" waagerecht zwischen den zwei "Stromschienen" L und N zeigt. In Bild 4.3.2 sind die KOP - Symbole auf-gelistet. Darüber ist die jeweilige Variab-le anzugeben. Sie erlauben nur ein-fache Verknüpfun-gen. Für komplexe Funktionen müssen Symbole der FBS dazu genommen werden.
Das Dokument, in dem die Funktionen / Funktions-bausteine dargestellt werden, wird meist „Funk-tionsplan“ (FUP) genannt, das galt ursprünglich nur für Ablaufpläne (siehe S. 1). Da in der DIN EN 61131 kein anderer Begriff für den Plan festgelegt ist, wird er in der Praxis weiter so genannt. In kleineren SPS können nicht alle "Tricks" durch FBS dargestellt werden, so dass dann zusätzlich ST oder AWL nötig sind. Allgemein ist die FBS aber die günstigste Dar-stellung für alle, die verfahrenstechnisch denken.
Name von Funktion /
Funktionsblock)
AND
RS
S Q1
R1
Signalflussrichtung:
von Ausgang
an Eingänge
Eingänge Ausgang
(ohne Namen wenn gleichartig)
Bei verschiedenartigen Ein/Ausgängen:
Eingangs / Ausgangsnamen (Abkürz.)
Bild 4.2.1: FBS, Regeln
Jede CPU - Aktivität benötigt „Kästchen“,
„wired OR“ des Kontaktplans verboten!
ORA
B
C(D) A
B
C
AND D
Bild 4.2.2: FBS - Beispiel
K2.1
(Störung)
K1.1
(Taste EIN)
K1 K2
K3
K3
L
N
K1 K2 K3
„Wirkschaltplan“ „Stromlaufplan“
Taste
EIN
Stö
rung
Taste
EIN
Stö
rung
Taste EIN
Pumpe Pumpe
Störung
( )
Pumpe
Taste EIN
( )
„Kontaktplan“ KOP
- Symbole:
Störung
Pumpe EIN
L
N
KOP (Für SPS: waagerecht)
„Pfad“
Bild 4.3.1: Weg zum KOP
Bild 4.3.2: Symbole des KOP
Nr. Symbol Bedeutung
1 --| |-- Schließer
2 --|/|-- Öffner
3 --|P|-- Pos. Übergang (0->1 - Trigger)
4 --|N|-- Neg. Übergang (1->0 - Trigger)
5 --( )-- „Spule“ (Ergebnis)
6 --(/)-- „negative Spule“ (Negation)
7 --(S)-- SETZE - Spule (speichern)
8 --(R)-- RÜCKSETZ - Spule (rücksetzen)
auch statt Nr.5: |M|, 7: |SM|, 8: |SR| für „gepuffert“
Anwend.beispiele: UND: --| |--| |--( )
ODER: --| |--+----( )
|
--| |--+
Wachtaste
Wachtaste
Eingänge Verknüpfung Ausgänge
(Variable) (Variable)
Text oder Text oder
Text und Kenzeichen Kenzeichen u. Text
Ggf. zusätzlich: HW - Angaben zu Ein- / Ausgängen
bzw.Adressen, vornehmlich in PLS
Trigger1
R_TRIG
CLCK Q
Trigger2
F_TRIG
CLCK Q
OR
T#10s
Timer1
TOF
IN Q
PT ET
WarnungNOT
1
Warnung
Timer2
TOF
IN Q
PT ETT#5s
Stop
Ne
tzw
erk
1N
etz
we
rk 2
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Juli 2013 4. Norm DIN EN 61131, grafische Sprachen
ASA_Progr_Spr.doc 21
4.4 AS (Ablauf - Sprache) Die AS dient zur Gliede-rung von POEs und Dar-stellung von Ablaufsteu-erungen mit Schritten. Ein Schritt repräsentiert einen bestimmten Zu-stand des Ablaufpro-gramms. Er kann über einen Aktionsblock in den Prozess eingreifen und schaltet zum nächs-ten Schritt weiter, wenn eine „Transition“ (Über-gangsbedingung) erfüllt ist. Bild 4.4.1 zeigt die wich-tigsten Festlegungen zur Ablaufsprache. Links ist die Verwendung des Blockes "Schritt" mit Schritt-Namen (beliebig) und abgeleiteten Signa-len dargestellt. Rechts ist der "Aktions-block" gezeigt, ein gra-fisches Element zur Verknüpfung einer boole' schen Variablen (normal-erweise "Schritt aktiv" durch die Verbindung zum Schritt) mit einer Aktion. Das kann das Setzen einer Boolschen Variablen sein wie „VA_AUF“ im Bild oder der Aufruf einer Logik, dargestellt in einer der Sprachen der Norm. Je nach Editor ist sie direkt im Aktionsblock oder über den Aktions-Namen verbunden getrennt dar-gestellt. Die Ausführung der Aktion kann über einen Buchstaben oben links im Block gesteuert werden, wenn die Firm-ware einen Funktions-baustein ACTION_CON-TROL enthält. Eine Instanz (Anwendung) dieses Funktionsbau-steins muss automatisch mit jedem Aktionsblock verbunden sein, die Deklaration ist für den Anwen-der nicht sichtbar. Bild 4.4.2 zeigt links die Elemente der AS, wie sie in der Dokumentation erscheinen, und rechts die Wirkungsweise der Aktionsarten, auch der Kombi-nationen. AS - Elemente sind nicht selbst POEs, untergliedern aber ein Programm oder einen Funktionsbaustein.
Zur Laufzeit wird geprüft, welcher Schritt aktiv ist, und nur dessen Aktion gerechnet. Das spart Rechenzeit. Daher wird die AS nicht nur für einfache Abläufe eingesetzt. Dabei kennt die Norm zwei Varianten: mit und ohne „abschließendem Durchlauf“. Dabei wird nach Rücksetzen eines Schrittes seine Aktion noch einmal ausgeführt (ist nur teils implementiert). Wird in einer POE die Untergliederung mit AS - Ele-menten verwendet, so muss die ganze POE so gegliedert sein.
Bild 4.4.1: Elemente der Ablaufsprache
Bild 4.4.2: Aktionssteuerung mit FB ACTION_CONTROL
Programmiersprachen Automatisierungssysteme DHBW Mannheim 4. Norm DIN EN 61131, grafische Sprachen Erich Kleiner, Juli 2013
22 AS_Syst_Komm.doc
Ob ein Schritt aktiv ist zeigt der "Schritt - Merker" (implizite Variable) <Schritt-Name>.X mit log. 1 an, z.B. in Bild 4.4.1 für Schritt 8. Die Weiterschaltung zum nächsten Schritt wird durch eine "gerichtete" Verbindung (nach unten) angegeben. Durch diese muss eine waagerechte Linie gehen, die der Ausgang der Transition ist, angegeben als: - Ausdruck in ST (rechts von der vertikalen Verb.), - grafisches Netzwerk durch FBS oder KOP, direkt
links dargestellt oder per Konnektor verbunden, - Text - Konstrukt mit den Schlüsselworten TRANSITION .. END_TRANSITION Bild 4.4.3 zeigt Verzweigung und Zusammenführung bei Kettenaus-wahl, links in AS - Sprache, rechts als Logik zur Erklärung der Wirkungs-weise. Die Auswahl bei der Ver-zweigung erfolgt durch Transitions-symbole unter der Verzweigungslinie für alle möglichen Abläufe. Durch Angabe eines * an der Verzweigungsstelle wird festgelegt, dass die Abarbeitung von links nach rechts erfolgt, d.h. sind e und f wahr, so gibt Schritt 3 an Schritt 4 weiter. Durch Angabe von Nummern an den Abzweigen kann eine andere Reihenfolge festgelegt werden. Zur Weiterschaltung auf Schritt 8 müssen Schritt 5 EIN und j wahr oder Schritt 7 EIN und k wahr sein. Durch Doppellinien werden "Simultanketten" darge-stellt, d.h. unabhängig voneinander parallel ablaufende Ketten (Bild 4.4.4). Start von Schritten 4 und 6 erfolgt, wenn Schritt 3 EIN und die Transition g erfüllt ist. Bild 4.4.5 zeigt einen Kettensprung, einen Sonderfall der Auswahl, bei dem ein oder mehrere Zweige keine Schritte enthalten. Die Weiterschaltung von Schritt 3 nach Schritt 6 erfolgt nur, wenn Schritt 3 EIN, e nicht wahr und f wahr ist. Bild 4.4.6 zeigt eine Ketten - Schleife, einen weiteren Sonderfall der Auswahl, in dem ein oder mehrere Zweige zu einem Vorgängerschritt zurückführen. Ein Sprung von Schritt 5 nach Schritt 4 erfolgt nur, wenn Schritt 5 EIN, j nicht wahr und k wahr ist. Zur Sicherstellung des gewünschten Ablaufs muss der Anwender notfalls durch negierte Bedingungen dafür sorgen, dass immer nur der gewünschte Weg durch eine erfüllte Transition "frei" ist.
Die implizite Variable <Schritt-Name>.T gibt die Zeit an, wie lange ein Schritt schon aktiv ist. Benutzt man diese in einem Ausdruck wie z.B. <Name>.T > t1“ als Transition, so ergibt das eine Wartezeit von t1 bevor auf den nächsten Schritt weitergeschaltet wird. Die Zeit wird bei der Deklaration von t1 angegeben: t1:TIME :=5s; Je nach Editor gibt es weitere implizite Variable (automatisch erstellte) z.B. zur Zeitüberwachung eines Schrittes oder zur Rücksetzung aller Schritte und deren Aktionen bei z.B. „NOT AUS“.
R S
&
fe
R SR S
R S R S
j k
R S
&
&
&
>1
>1
STEP 4 STEP 6
e f
STEP 3
STEP 5 STEP 7
j k
STEP 8
=
alternativ!
STEP 4 STEP 6
g
h
STEP 3
STEP 5 STEP 7
STEP 8
=
St.5, 7 h
Step 8
&
Bild 4.4.3: Kettenauswahl Bild 4.4.4: Simultanketten
STEP 3
STEP 4
STEP 5
STEP 6
e f
j
STEP 3
STEP 4
STEP 5
STEP 6
e
j k
Bild 4.4.5: Sprung Bild 4.4.6: Schleife
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Juli 2013 4. Norm DIN EN 61131, grafische Sprachen
ASA_Progr_Spr.doc 23
Das folgende Beispiel von der Steuerung eines Brenners z.B. an einem Heizungskessel verdeut-licht die Anwendung der Ablaufsprache. Bild 4.4.7 zeigt die Komponenten des Brenners. Wenn ein Befehl „EIN“ vorliegt soll das Gebläse eingeschaltet werden (läuft, solange Befehl aktiv) und damit der Feuerraum 10s belüftet werden. Dies soll durch die Meldung „VORBELÜFTUNG“ angezeigt werden. Danach soll das Ölventil (Magnetventil: offen wenn aktiviert) für max. 5s geöffnet und der Zündtrafo eingeschaltet werden.
Meldet der „Flammwächter“ (Sensor) dass die Flam-me brennt, so soll das Ventil offen bleiben und die Meldung „BETRIEB“ gegeben werden. Erlischt die Flamme oder kommt der Befehl „AUS“, so soll das Ventil schließen und das Gebläse abgeschaltet werden, und die Steuerung in den Initialisier-ungsschritt zurückkehren. Wird die Flamme nicht entzündet, so soll nach 5s das Ölventil geschlossen und die Meldung „STÖRUNG“ ausgegeben werden. Nach „QUITTIEREN“ Gebläse aus und Steuerung zurück.
Bild 4.4.8 zeigt den Anfang der textlichen Variablendeklaration.
Bild 4.4.9 zeigt das Ablaufpro-gramm mit Schritten (dem Element der Ablaufsprache) grafisch dargestellt mit Sym-bolen der Funktionsbaustein-sprache (FBS). Die Transiti-onen sind in Strukturiertem Text (ST) dargestellt.
Wartezeiten sind verschieden realisiert: in Schritt 2 mit einer eigenen verzögerten Variablen „Belueftet“, und vor Schritt 6 mithilfe der impliziten Variablen SCHR3.T.
In manchen Editoren (z.B. CoDeSys) wird die Rückkehr zum Initialschritt nicht komplett gezeichnet sondern nur durch einen Pfeil (nach rechts) am Ende eines Programms dargestellt.
Bild 4.4.10 zeigt den Anfang des Programms mit Elementen des Strukturierten Textes (ST). Ob das übersichtlicher ist sei dahingestellt. Hier zeigt sich, dass die Norm begrifflich nicht eindeutig ist: „AS“ wird als Ablauf-Sprache bezeichnet, ist aber wohl als Gliederungsprinzip einer POU (Program Organisation Unit) gedacht und kann mit Sprach-elementen der FBS oder des ST dargestellt werden.
Bild 4.4.7: Komponenteneines Brenners
Bild 4.4.8: Textliche Variablen-Deklaration
Bild 4.4.9: AS-Programm in FBS, Transitionen inST
Bild 4.4.10: Programm in ST
Programmiersprachen Automatisierungssysteme DHBW Mannheim 5. Norm DIN EN 61131, Deklaration Programmstruktur Erich Kleiner, Dezember 2002
24 AS_Syst_Komm.doc
5. Deklaration der Programmstruktur Die in Kap. 2.2 (Bild 2.2.1) dargestellte SW - Struktur muss am Anfang des An-wenderprogramms deklariert werden. Dazu können im Prinzip alle in der Norm festgelegten Sprachen be-nutzt werden. Bild 5.1 zeigt ein Beispiel als Skizze (nur zur Erläuterung). Die Konfiguration CELL_1 enthält die Ressourcen STATION_1 u. STATION_2. Beide Stationen enthalten Tasks zur Steuerung be-stimmter Programme und Funktionsbausteine. Bild 5.2 zeigt eine Task allgemein mit ihren Eingängen. Im Beispiel werden die Programme vom "Typ" F, G und H verwendet, und zwar als P1 und P2 in STATION_1, sowie als P1 und P4 in STATION_2. In den Programmen kom-men Funktionsbausteine der Typen A, B, C und D vor, jeweils als FB1 und FB2 in P2 und P4. Bild 5.3 zeigt vereinfacht die Deklaration der Funktions-bausteine und Programme (ohne Variablendeklaration und ohne "Körper" (Pro-gramm). Bild 5.4 zeigt schließlich die Deklaration des Beispiels in ST - Sprache, wobei die Nummern am linken Rand die einzelnen Teile klassi-fizieren. Heutige Editoren ersparen dem Anwender meist eine solche Deklaration durch einen geführten Dialog.
Konfiguration CELL_1
RESSOURCE STATION_1
TASK
SLOW_1
TASK
FAST_1
PROGRAMM F PROGRAMM G
A
SLOW_1
B
SLOW_1
FB1 FB2
P1 P2
RESSOURCE STATION_2
PROGRAMM F
P1
SLOW_1 PER_2
PROGRAMM H
C
PER_2
D
SLOW_1
FB1 FB2
P4
TASK
PER_2
INT_2
TASK
FAST_1
Bild 5.1: Konfigurations - Beispiel
TASK
BOOL -- SINGLE
TIME -- INTERVAL
UINT -- PRIORITY
Bild 5.2: Task
FUNCTION_BLOCK A
VAR ... END_VAR
(* FB Body *)
END_FUNCTION_BLOCK
FUNCTION_BLOCK B
VAR ... END_VAR
(* FB Body *)
END_FUNCTION_BLOCK
FUNCTION_BLOCK C
VAR ... END_VAR
(* FB Body *)
END_FUNCTION_BLOCK
FUNCTION_BLOCK D
VAR ... END_VAR
(* FB Body *)
END_FUNCTION_BLOCK
PROGRAM F
VAR .. END_VAR
(* Program Body *)
END_PROGRAM
PROGRAM G
VAR .. END_VAR
FB1(..) ; out := ..
FB2(..) ; ...
END_PROGRAM
PROGRAM H
VAR .. END_VAR
FB1(..) ; ..
FB2(..) ; ...
END_PROGRAM
Bild 5.3: Deklaration der Programme und Funktionsbausteine
1 CONFIGURATION CELL_1
2 VAR_GLOBAL ... END_VAR
3 RESSOURCE STATION_1 ON PROCESSOR_TYPE_1
4 VAR_GLOBAL .. END_VAR
5a TASK SLOW_1(INTERVAL := t#20ms, PRIORITY := 2) ;
5b TASK FAST_1 (INTERVAL := t#10ms, PRIORITY := 1) ;
6a PROGRAM P1 WITH SLOW_1 :
...
PROGRAM P2 : G(
6b FB1 WITH SLOW_1, FB2 WITH FAST_1)
3 END_RESSOURCE
3 RESSOURCE STATION_2 ON PROCESSOR_TYPE_2
4 VAR_GLOBAL .. END_VAR
5a TASK PER_2(INTERVAL := t#50ms, PRIORITY := 2) ;
5b TASK INT_2 (SINGLE := z2, PRIORITY := 1) ;
6a PROGRAM P1 WITH PER_2 :
...
6a PROGRAM P4 WITH INT_2 :
6b FB1 WITH PER_2 ;
3 END_RESSOURCE
10a VAR_ACCESS
10b ...
10a END_VAR
1 END_CONFIGURATION
Bild 5.4: Deklaration einer Konfiguration in ST Sprache
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 6. Anwendungsbeispiele
ASA_Progr_Spr.doc 25
6 Anwendungsbeispiele 6.1: "Wiegen" (Sprachen - Vergleich)
Zum Vergleich zeigt Bild 6.1 Variablen - Deklaration und Programmbeschreibung in den verschiedenen, in der Norm enthaltenen Möglichkeiten, an einem Beispiel.
Als Beispiel dient eine Funktion "WEIGH" zur Ermitt-lung des Nettogewichts aus Brutto - Gewicht (gross_weigh) in BCD und Tara (tare_weigh) als INT, gestartet wird die Berechnung mit „1“ an “weigh_comd“.
Deklaration textlich:
FUNCTION WEIGH : WORD (* BCD - codiert)
VAR_INPUT (* “EN“ input used to indicate “ready“ *)
weigh_comd : BOOL;
gross_weight : WORD; (* BCD - codiert *)
tare_weight : INT;
END_VAR
(* Function Body *)
END_FUNCTION
Deklaration grafisch:
WEIGH
BOOL -- EN ENO -- BOOL
BOOL -- weigh_comd -- WORD
WORD-- gross_weight
INT ------ tare_weight
Programmbeschreibung als Anweisungsliste Programmbeschreibung als Funktionsplan
LD weigh_comd
JMPC WEIGH_NOW (* weighing*)
ST ENO (*no weighing*)
RET
WEIGH_NOW LD gross_weight
BCD_TO_INT
SUB tare_weight
INT_TO BCD
ST WEIGH
weigh_comd
gross-weight
tare_weight
BCD_
TO_INT
EN ENOSUB
EN ENO
INT_
TO_BCD
EN ENO
ENO
( )
WEIGH
IF weigh_comd THEN
WEIGH := INT_TO_BCD
(BCD_TO_INT(gross_weight) - tare_weight);
END_IF
Programmbeschreibung als Strukturierter Text Programmbeschreibung als Kontaktplan
weigh_comd
gross-weight
tare_weight
BCD_
TO_INT
EN ENOSUB
EN ENO
INT_
TO_BCD
EN ENO
ENO
WEIGH
Programmiersprachen Automatisierungssysteme DHBW Mannheim 6. Anwendungsbeispiele Erich Kleiner, Dezember 2002
26 AS_Syst_Komm.doc
6.2 Funktionsbaustein "Totmannsknopf" Gegeben:
Der Lokführer einer Diesel - Lok muss alle 50 s den „Totmanns - Knopf“ drücken. Erfolgt dies nicht, so ertönt 14s lang ein Warnton. Wird auch dann der Knopf nicht gedrückt, so wird die Lok abgebremst und der Warnton verstummt.
Aufgabe: Deklaration (textlich) und Programmbeschreibung
als FBS, ST und AWL, erstellen als Funktionsblock.
Tipp: Erstellen Sie sich ein Signal - Zeit - Diagramm
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, Dezember 2002 6. Anwendungsbeispiele
ASA_Progr_Spr.doc 27
6.3 Mixer (Ablauf) Gegeben:
Mit einem „Ablaufplan“ ist das Mischen zweier Flüssigkeiten auf ein Startsignal ST zu steuern: 1. Aus A in C füllen durch VA: Gewicht a,
2. Aus B in C füllen durch VB: Gewicht b, 3. Durch VC in Mixer füllen bis Gewicht = 0 4. 60 s lang mit MR mixen, 5. Mixer nach unten kippen, 10 s warten, dabei bleibt MR ein. 6. Mixer wieder nach oben kippen, MR ausschalten. Deklaration: FUNCTION_BLOCK MIX VAR_INPUT ST : BOOL ; (* Start - Befehl *) SO : BOOL ; (* Endschalter OBEN *) SU : BOOL ; (* Endschalter UNTEN *) WG : WORD ;(* aktuelles Gewicht *) WA : INT ;(* gewünschtes Gewicht von A *) WB : INT ; (* gewünschtes Gewicht von B *) END_VAR VAR_OUTPUT VA , (* Ventil VA: 0 - zu, 1 - offen *) VB , (* Ventil VB: 0 - zu, 1 - offen *) VC , (* Ventil VC: 0 - zu, 1 - offen *) MR, (* Mixer - Motor, 0 - aus, 1 - ein *) MDO, (* Kipp-Motor, dreht mit 1 nach oben *) MDU, (* Kipp - Motor, dreht mit 1 nach unt. *) END_VAR VAR WZ1, WZ2: BOOL ; (* Wartezeit Ende *) END_VAR Aufgabe: Erstellen Sie einen grafischen Ablaufplan mit
Elementen der Ablaufsprache, der Funktionsbaustein ACTION_CONTROL ist
implementiert.
A
VA
B
VB
VC
C
WA WB
Wiege - Einheit
WG
MR
Endschalter
„UNTEN“
Endschalter
„OBEN“
MDO
MDU
MD
Mixer,
kippbar
SO
SU
Programmiersprachen Automatisierungssysteme DHBW Mannheim 6. Anwendungsbeispiele Erich Kleiner, Aug. 2009
28 AS_Syst_Komm.doc
6.4 Speisepumpe (POE - Struktur) Gegeben:
Speisepumpe SSP - über Tasten und Automatik schaltbar, - EIN nur erlaubt, wenn AV zu und OELDR - Schutz-AUS wenn TANKNIV < MIN (10%) Hilfsölpumpe HPP - über Tasten und Automatik schaltbar Absperrventil AV - über Tasten und Automatik zu öffnen / zu
schließen, - darf nur geschlossen werden, wenn SPP aus ist Tank - Niveaumessung TANKNIV - analoge Messung, liefert 0 .. 100 % (für 0 .. 3 bar) Schutz-AUS - Signal (binär) durch Funktion
erzeugt Öldruck - Messung OELDR - binäre Messung, liefert „1“ für „Druck vorhanden“ Automatik zum Anfahren / Abfahren mit EIN - und AUS - Programm, berücksichtigen: EIN - Programm: 1. AV zu und HPP ein 2. SPP ein 3. AV auf Aufgabe: a) Erstellung des Blockschaltbildes einer sinnvoll
gegliederten Struktur der oben genannten Aufgabe oberhalb der nebenstehenden Skizze. Stellen Sie Antriebs- u. Gruppensteuerung als „Kästchen“ dar, ohne Logik, aber mit beschrifteten Pfeilen für Eingangssignale und Befehle, Hand- Betätigungen als Tasten.
b) Erstellung der Funktionspläne von Hilfsöl-pumpe, Speisepumpe und Absperrventil. Benutzen Sie komplexe Funktionsbausteine mit Eingängen AE/AA für Automatik-Befehle, FE/FA für Freigaben, SE/SA für Schutzeingriffe.. Stellen Sie nur die Antriebs- spezifischen Verknüpfungen (wie „EIN- Freigabe durch „AV ZU“ UND „Öldruck vorh“) mit Logik- Funktionen dar.
Tastenbedienung nicht darstellen.
MM M
SPPAV
HPP
Tank
TA
NK
NIV
OE
LD
R
DHBW Mannheim Automatisierungssysteme Programmiersprachen Erich Kleiner, November 2007 7. IEC 61499 und 61804
ASA_Progr_Spr.doc 29
7. Normen IEC 61499 / IEC 61804 7.1 Übersicht
Sowohl in der Fertigungs- als auch in der Prozessautomatisierung wird der Automatisierungsgrad immer höher und die zu automatisierenden Anla-gen werden größer. Gleichzeitig müssen zum Bestehen am inter-nationalen Markt Erstellungszeiten verkürzt und Engineeringkosten ge-senkt werden (Bild 7.1.1) Diese Aufgaben lassen sich nicht durch Detail – Programmierung aller Funktionalitäten per Basis –Funk-tionen und –Funktionsbausteinen der IEC 61131 lösen. Bild 7.2 zeigt die verschiedenen Lösungsansätze für die verschiedenen Anwendungsbe-reiche. In der Motion Control hat sich die Verwendung von Makros für die ver-schiedenen Antriebsarten etabliert. Diese werden vom Hersteller eines Leitsystems bereitigestellt und vom Anwender nur „parametriert“, d.h. auf die speziellen Bedürfnisse des jeweil-igen Antriebs angepaßt, z.B. Startzeitpunkt, Geschwindigkeit und „Rampe“ einer Achsenbewegung. Das erfolgt meist in grafischer Form durch Angabe dieser Informationen an den „Eingängen“ der Darstellung einer sol-chen „Drive“ – Steuerung. Für allgemeine Steuerungs- und Regelungsaufgaben der Fertigungs-automatisierung kann sich der Anwender schon gemäß der IEC 61131 komplexe Funktionsbausteine aus Basisfunktionen und –Funktionsbausteinen erstellen, die eine Wiederverwendung einmal erstellter und möglichst erprobter Lösungen erlauben. Die möglichst wenigen anwen-dungsspezifischen Besonderheiten werden durch zusätzliche Logik mit Basisfunktionen und Basis -Funktionsbausteinen realisiert. Problematisch bleibt dabei aber die Koordination in einem größerem Verbund. Genau hier setzt die neue Norm IEC 61499 an mit der Idee hoch komplexer Funktionsbausteine, die einen übergeordneten Teil zur Steuerung des Einsatzzeitpunktes („Ereignisse“) und einen ausführenden Teil mit der jeweils nötigen Logik („Daten“) enthalten. Dieses Konzept eignet sich besonders für dezentral angeordnete Verarbeitungs-kapazität, kann aber auch in zentraler Anordnung genutzt werden. Die IEC 61499 liegt vor seit Juni 2000.
In der Prozessautomatisierung ist die Verwendung proprietär (produktspezifisch) standardisierter kom-plexer Funktionsbausteine in Funktionsplan – Darstellung schon lange üblich. Das betraf aber bisher hauptsächlich nur den Kern der eigentlichen Steuerung und Regelung. Messwertaufbereitung und Signalausgabe wurden in anderer Form festgelegt und waren daher im Funktionsplan un-sichtbar. Spezielle Funktionalitäten, die nicht mit den proprietären Blöcken realisierbar waren, wurden mit Basiselementen erstellt. Die neue Norm IEC 61804 definiert nun allgemein standardisierte komplexe Funktionsbausteine der Messwertaufbereitung, Verarbeitung und Signalaus-gabe für die Prozessautomatisierung. Die IEC 61804 ist in der Ausgabe von 2000 gültig und soll 2006 ggf. überarbeitet werden.
Basis - Funktionen,
- Funktionsbausteine
+ Makros
Fertigungsautomatisierung Prozessautomatisierung
&
Tool
IEC 61131
- Strukturierter Text
- Funktionsplan, Ablaufplan
- Kontaktplan
- Anweisungsliste
Anw.: Parametrierung
der Makro-Eingänge
erstellt vom
Anwender
>1 SR
S
Motion Control Steuerung / Regelung allg.
Verar-
beitung
Messw.-
Aufbereitg.
Standardfunktionsbl.
gemäß IEC 61804
61131 - „kompatibel“
Entw.: Höhere
Programmierspr.
>1 SR
S
(S)
Ereignisse
DatenIEC 61499
PLS - Sicht
Objekt - Sicht
Anlagen - Sicht
Drive MRS-Kreis
(UML
in Anfängen)
erstellt vom
Hersteller (proprietär)
(oder Anwender)
Verschaltung komplexer
Funktionsblöcke,
Verteilte SW
Basis-F. MRS-Kreis
Ab
str
akti
on
Bild 7.1.2: Lösungsansätze in verschiedenen Anwendungsbeeichen
Bild 7.1.1: Anforderungen und Maßnahmen
Anforderungen an das heutige Anlagen - Engineering:
technisch:- steigender Automatisierungsgrad (vertikale Ausdehnung)
- größere zu automatisierende Anlagen (horizontale Ausdehnung)
d.h. mehr Einzelaufgaben sind koordiniert zu automatisieren
Maßnahmen:
- Konzepte zur Vernetzung
der Funktionsblöcke
ökonomisch:
- kürzere Erstellungszeiten
- höhere Sicherheit / Verfügbarkeit
- geringere Erstellungskosten
- Definition komplexer
Funktionsblöcke
- Wiederholtechnik
(weniger Engineeringaufwand)
- geringere Wartungskosten
- erprobte Funktionsblöcke
(weniger system. Fehler)
Programmiersprachen Automatisierungssysteme DHBW Mannheim 7. IEC 61499 und 61804 Erich Kleiner, Januar 2006
30 AS_Syst_Komm.doc
7.2: IEC 61499 Bild 7.2.1 zeigt das „Innenleben“ eines Funktionsblocks nach IEC 61499. Der Kopf enthält eine „Zustandsmaschine“. Sie erhält von außen z.B. den Startbefehl, steuert den darunter dargestellten Logikteil und meldet den aktuellen Zustand weiter. Eine solche Zustandsmaschine kann z.B. nach den Regeln der OMAC (Open Modular Architecture Controls) dargestellt werden, die als Standards von amerikanischen Ver-packungsfirmen entwickelt wurden. Die Logik wird durch IEC 61131 dargestellt. Bild 7.2.2 zeigt ein vereinfachtes Anwendungsbeispiel aus einer „Assembly Line“ für die Montage von Mobiltelefonen. Dargestellt ist nur die Steuerung des Ablaufs, nicht die einzelnen Detailfunktio-nalitäten, die wiederum durch Funktions-bausteine realisiert werden. Die Anwendung der IEC 61499 bringt:
Reduktion von Engineeringkosten
durch integrierte Tools,
Einfaches Modell für verteilte und zentrale Strukturen,
Einfache Applikations – Portierbarkeit,
gekapselte, einfach wiederverwendbare, komponentenbasierte SW,
Vermeidung von Spezial-SW zur Verbindung von Modulen, besser für:
- Wartung, Betriebssicherheit, - Migration des IEC 61131 – Codes 7.3 Norm IEC 61804 In dieser Norm werden für die Prozessauto-matisierung Funktionalitäten der Messwert-aufbereitung, Verarbeitung, Signalausgabe und Kommunikation (Bedienen und Beo-bachten sowie Engineering), die bisher produktspezifisch gelöst waren, als stan-dardisierte Funktionsbausteine festgelegt. Das soll bringen:
Einfachere Planung,
Kombinierbarkeit verschiedener Produkte,
einfachere Wartung durch gleichartige Wirkungsweise.
Bild 7.3.1 zeigt das Prinzip. - Ressource Blocks beschreiben die HW, - Application Function Blocks enthalten
parametrierbar die Aufgaben der Messwertaufbereitung, die bisher entweder unsichtbar waren oder durch Basis-FB realisiert werden mussten, bzw.
Steuerungs- bzw. Regelungsaufgaben, - Mapping Function Blocks organisieren
Verbindungen und Datenspeicherung für die Kommunikation.
Ereignisse
Daten
OMAC –
Zustandsmaschine
IEC 61131 –
Funktionsbausteine
IEC 61499 –
Funktions-
baustein
ANDOR
R
SKomplexe,
wiederverwendbare
Teilfunktionen,
geschrieben in IEC 61131
Off
Power ON/OFF
Stopped Starting
Prep. Start
Standby
Producing
Materials readyMaterials
RunOut
Stopping
Stop
vereinfachtes Beispiel:
(Open Modular Architecture Controls,
Standards amerikanischer Verpackungsfirmen)
Bild 7.2.1: „Innenleben“ der IEC 61499 - Funktionsblöcke
Pick
Place
Verteilung
Zustände,
Zykl. Signale
In 1
In 2
Out 1
Out 2
Pick & Place 1
Stack 1
Posi-
tioning
Glue-
ing
Fix-
ing
Glue 1
Posi-
tioning
Glue-
ing
Fix-
ing
Glue 2
In 1
In 2
Out 1
Out 2
Stack 2
Pick
Place
Pick & Place 2
Bild 7.2.2: Vereinfachter Auszug aus einer Assembly Line
Literatur – Hinweise: [1] IEC / EN / DIN 61131 und Beiblatt [2] „Softwarekonzepte für zentrale und dezentrale Steuerungs-architekturen“, Josef Papenfort (Beckhoff Automation), atp 1/06 [3] IEC 61499 „Functional Blocks for industrial-process measurement and control systems” [4] IEC 61804 „Function Blocks for Process control
Bild 7.3.1: Prinzip der IEC 61804 - Funktionsblöcke
P=
#=
ƒ
Application FB
- Analog IN / OUT
- Discrete IN / OUT
- ON/OFF Actuat.
Technology Blocks- Temperature
- Pressure Block
- Mod. Actuation
OR
ƒ
S
- Control FB
- Calculation FB
Mapping FB to
Communication
P=
#=
#=
Mapping FB to
System Management
Controller
Device Resource
Block
Communication