entwurfs- und programmiersprachen für ... · pdf filedhbw mannheim...

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 werden. 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


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“


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


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


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


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


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


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


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



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


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.



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 aufgerufen 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


nach GRÜN,

wieder auf ROT

Funktionsbausteine

(Unterprogramme)

- AutoAmpel


über GELB nach GRÜN,

wieder GELB bis ROT

- FußgAmpel


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



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


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


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


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


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


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


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

entwurfs- und programmiersprachen für ... · pdf filedhbw mannheim...

Documents