Sie sind auf Seite 1von 7

HTBL u.

VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

Höhere Technische Klasse: 4BHET


Bundes-, Lehr- u. Versuchsanstalt (BULME)
Graz – Gösting Gruppe: 2
Übungstag: 9.10.2020
Elektrotechnisches Laboratorium Bis
16.10.2020
Betreuer: NH
Schriftführer: Antonio Trogrlic Abgabedatum: 23.10.2020

Aufgabe: Füllstandmessung

– AUFGABENSTELLUNG
Eine Pumpe die von einer SPS angesteuert wird. die Pumpstation wiederum beinhaltet einen Sensor,
der den Wasserfüllstand von oben weg misst und als Analog Input für die SPS ausgibt. Des Weiteren
wird ein Regelung für das System benötigt in unserem Fall ein Zwei-Punkt-Regler

Projekt
– einmalig
– im Ergebnis unvorhersehbar
1. Projektmanagement

1.1. Leistungsdreieck
– bestimmt ob das Projekt erfolgreich wird
– man darf nur 2 der 3 Säulen vorgeben, da sonst eine Verwirklichung des Projektes nicht
möglich ist

Bild1:Leistungsdreieck
Danach haben wir darüber gesprochen, wie man ein Projekt angeht und
wie man sich diesen Prozess visualisieren könnte. Dazu verwenden wir das V-Modell

1.2. V-Modell
– nächster Schritt erst erreichbar, wenn der alte Schritt abgeschlossen ist Bild2:V-Diagramm
– besteht aus
o Anforderung (Was?)
o Design (Wie?)
o Implementierung (Umsetzung)
o Integration (Zusammenspiel)
o Systemtest (Abnahme)

Seite 1
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

Zudem wird beim Projekt zwischen Lasten und Pflichtenheft unterschieden


– Lastenheft(nicht vollständig)
o Aufgaben die Auftraggeber schreibt
– Pflichtenheft(vollständig)
o Aufgaben die Arbeitnehmer schreibt

1.2.1. Anforderung
Wie der Name schon vermuten lässt werden hier die Anforderungen des Projektes
niedergeschrieben. Hierbei wird zwischen Lasten und Pflichtenheft unterschieden.
das Lastenheft ist nicht vollständig und beinhaltet nur die Aufgaben des
Auftraggebers. Im Gegensatz dazu ist das Pflichtenheft vollständig und beinhaltert
zudem die Aufgaben, die durch den Arbeitnehmer vorgeschrieben sind.

1.2.2. Design
Im Design wird die Funktion beschrieben und wie diese umzusetzen ist.

1.2.3. Implementierung
Die Implementierung beschreibt die aktive Umsetzung der Hardware bzw. Software,
die im vorherigen Design vorgeben wurde
In der Software wäre hier die Umsetzung in SCL,FUP usw. möglich. Ein Beispiel für
die Hardware wäre der mechanische Zusammenbau des Modells

1.2.4. Integration
Die Integration beschreibt die schrittweise Inbetriebnahme und Zusammenspiel
einzelner Module.

1.2.5. Systemtest
Beim Test wird geschaut ob alle Fälle funktionier und falls nicht ist dies verheerend
da man jeden Schritt zurückgehen muss, um zu schauen wo sich der Fehler genau
versteckt. Dieser Prozess ist mit großen Geldmengen verbunden und sehr
zeitfressend.

2. Design

2.1. Analyse der Anlage


– Frage ob Eingang oder Ausgang → abhängig vom Betrachtungspunkt
– Zudem erlangten wir die Erkenntnis ,dass es egal ist welchen GND wir benutzen, da alle
GND über einen Bus der SPS verbunden sind

2.2. Systemschaltbild
– nun war es an der Aufgabe die Analyse der Anlage i ein visuelles Schaltbild umzuwandeln
– Was gehört in das Schaltbild?
o Komponenten(SPS, Füllstandmodell)
o Unterkomponenten(CPU,AD/DA Rechner, PC,TIA)
o Typ der Schnittstelle (Analog, Digital)

Seite 2
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

Bild3:Systemschaltbild

2.3. Datenflussplan
– Er gibt uns an was mit welchen Variablen in welchem Baustein passiert. Ganze
Datenverarbeitung kann nachvollzieht werden.
– Zudem besteht der Datenflussplan aus Modulen, welche enorme Vorteile bieten wie zB.
o Zuschaltung von Software→wird in der Konfiguration gemacht (BSP Samsung)
– Variablen
o Variablennamen sollten sehr informativ sein
▪ AI_Fuellstand_IST_per_int
▪ AI=Analog Input, IST=Ist oder Soll-Wert, per=peripher, int=Integer
o globale Variablen keine Präfixe
o Präfixe nur Lokal in Modulen i, o, s=Input, Output, Static
o keine Sonderzeichen/Leerzeichen
o Underline ist akzeptabel

– OB
o OB30->Echtzeit-bestimmter Takt→muss einmal aufgerufen werden zur
bestimmter Zeit
o OB1→ nicht Echtzeit→variable Taktzeit→sobald fertig wird wieder geschaut
o OB30 hat Vorrang gegenüber OB1

– Echtzeit
o Daten stammen vom selben Zeitpunkt (Regelungstechnik, Saftey)
o Linux→Echtzeit, Windows→nicht Echtzeit
o beste Echtzeit→Analog: zu jedem Zeitpunkt ein Wert
o harte Echtzeitbedingung(kein Zeitüberschreitung)
o weiche Echtzeit (falls Zeit überschritten wird hat es kleine gravierenden Folgen,
PC-TIA)

Seite 3
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

Bild4:Datenflussplan

2.4. INPUT-AV
Anschließend haben wir das Modul INPUT-AV als Kennlinie dargestellt. Dabei ist wichtig zu
wissen was die Eingangsgröße(x-Achse) und was die Ausgangskenngröße ( y-Achse) ist. Als
Eingang dient uns in diesem Fall ein Sensor (Integer) der von 57-27630 geht. Da dieser von oben
weg misst, erhalten wir den INT Wert 57 bei vollem und 27630 bei leerem Füllstandswert . Dies
erklärt die negative Steigung der Kennlinie. als Ausgang dient uns ein real Wert von 0-1. Mit den
2 gegebenen Punkten P1 [57;1] P2 [27630;0] lässt sich die Kennlinie rekonstruieren. Dazu kann
man mit y=k*x+d, die Steigung ausrechnen und damit wiederum die gesamte Funktion. dazu
haben wir einfach die Gleichungssysteme subtrahiert, um das d wegzukriegen

Bild5:Input-AV

Seite 4
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

2.5. OUTPUT-AV
Diesmal mussten wir wieder eine Kennlinie zeichnen, jedoch war in diesem Fall der Eingang ein
Real von 0-1 und der Ausgang ein Integer von 0-27648. Danach setzten wir wieder für die Punkte
P1[0;0] P2[1;27648] ein und konstruierten die Kennlinie und errechneten uns unsere Formel für
y=k*x+d

Bild6:Output-AV

3. Implementierung

3.1. Kommunikation
Als erstes haben wir darüber gesprochen welche Kommunikation wir verwenden werden und
kamen zum Entschluss, dass eine Echtzeit-Kommunikation die einzige richtige Lösung für das
System ist.
Dafür verwenden wir in diesem Fall→Profinet
– ist auf ISOnet aufgesetzt
– für jeden Teilnehmer ist eine bestimmte Zeit reserviert

Eine andere Möglichkeit wäre auch ISOnet welches jedoch nicht echtzeitfähig ist.

ISOnet
– mehre Teilnehmer
– nur einer kann sprechen, anderen warten

Des Weiteren erkannten wir, dass wir überall in unserem Systemschaltbild Echtzeit brauchen,
jedoch nicht überall eine harte Echtzeit benötigt wird, sondern auch eine weiche teilweise
implementiert werden kann.

3.2. SPS
An der SPS sind bei 24V GND(egal wo), AI.0 und AQ.0 Kabel angeschlossen, die mit dem
Füllstandsmodell verbunden sind

Wir verwenden für unser Modell eine Saftey-SPS (SPS-F) welche viel komplexer und auch teurer
als die herkömmliche SPS ist. Dabei steht das F für Fail Safe. Zunächst haben wir unsere SPS
online ausgelesen indem wir auf nicht-spezifizierte SPS gegangen , haben die nötigen
Einstellungen (Profinet/Industrial Ethernet PN/IE) ,Intel(R) (Schnittstelle nach außen) getätigt und
dann auf Suche. Danach noch die dazu gehörigen IN/OUTPUT-Karten. Dazu kommt, dass die

Seite 5
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

richtige Firmware auf der SPS sein muss(2.6). zudem haben wir die Simulierbarkeit aktivieren
müssen Projekt-Eigenschaften

3.2.1. SPS-Totsünden
1. gleiche IP-Adresse zweimal vergeben bzw. eine neue zuweisen
2. Kommunikationskurzschluss (LAN)
3. Passwort vergeben (SPS zum Wegschmeißen)

3.3. PLC-Variablen
Dazu sind wir in die geräte-Konfiguration und dort auf die dementsprechende Karte und haben die
Variablen direkt dort festgelegt. Dies erspart uns das manuelle Eintragen in der standart-Variablen
Tabelle. Auch muss die F-Aktivierung ausbleiben und ist unter PLC→Eigenschaften→Saftey zu
finden. Zudem in den Saftey Einstellungen→Vollzugriff erlauben

3.4. Global-DB
Alle Variablen, die wie schon vorher im Datenflussplan aufgeschrieben wurden, werden hier nun
hineingeschrieben

3.5. Transfer-to-DB
Dafür haben wir einen FC(kein Gedächtnis) verwendet. Move dient uns für die Umsetzung. Dabei
wird der Datenpunkt AI_Füllstand_ist_per_int→auf Füllstand_ist_per_int geschrieben

Hier haben wir auch darüber diskutiert was in den Namen des Netzwerks kommt.
Was es tut oder was es tun soll
Die Antwort: Was es tun soll, da was es tut ja in der Funktion gegeben ist, die im Netzwerk liegt
Dadurch wird die Suche nach Fehlern erheblich vereinfacht.
Hier gilt auch der Leitsatz: zuerst dokumentieren-> dann programmieren

3.6. Input-AV
FB wird verwendet(hat Gedächtnis/Speicher) Dies Modul haben wir im Gegensatz zum Letzen in
SCl programmiert. Hierfür benötigen wir unsre lokalen Variablen, die mit Präfixen ausgestattet,
sind.
i Input
o Output
s Static
c Constant
t Temporär
Variablen:
i_Füllstand_ist_per_int
o-Füllstand_ist_norm_real
t_Füllstnd-ist_per_real

Programm

//Zuerst Datentyp Konvertierung

#t_Füllstnd-ist_per_real := INT_TO_REAL(#i_Füllstand_ist_per_int);

//Normierung von 0…27630 auf 0...1

#o-Füllstand_ist_norm_real:= -0.000036* #t_Füllstnd-ist_per_real+1.002;

Seite 6
HTBL u. VA Graz-Gösting
Ibererstrasse 15-21
A-8051 Graz
Elektrotechnisches
Tel.: 0316-6081-0
www.bulme.at Laboratorium

3.7. Output-AV
Im Gegensatz zum Input-AV tun wir hier zuerst skalieren und dann konvertieren.

Variablen
i_Stellglied_akt_norm_real
o_Stellglied_akt_per_int
t_Stellglied_akt_per_real

Programm

//Datentyp konvertieren von real nach int

#t_Stellglied_akt_per_real:=27648*# i_Stellglied_akt_norm_real;

//Skalierung

Den Rest des Moduls habe ich leider nicht rechtzeitig geschafft.

DATUM, UNTERSCHRIFT

.............................. .............................
Datum Unterschrift

Seite 7

Das könnte Ihnen auch gefallen