OOP - Debugging- / Inbetriebnahmestrategie

Zuviel Werbung?
-> Hier kostenlos registrieren
mgl schrieb:
Bei Siemens landen normal alle Bausteine und Variablen in einem Globalen DB, was bedeutet, dass man von überall auf alles zugreifen kann.
Zum Vergrößern anklicken....
:unsure:
Kannst du das mal genauer erklären? Ich habe so etwas meine Zweifel an der Aussage.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MFreiberger schrieb:
Kann Jemand mal Begriffsdefinitionen zu
  • Vererbung
  • Interfaces
  • Propertys
  • Kapselung
  • Enumeration
  • Klassen
Zum Vergrößern anklicken....

Enumeration:
Gehört eigentlich nicht zum Klassen-Konzept aber da danach gefragt wurde.

Prinzipiell definiert dabei einen Datentyp der nur bestimmte Werte annehmen kann:

Beispiel Meldeklassen
C-ähnlich: 
TYPE E_MessageClass :
(
    AlarmImmediateStop := 0,
    AlarmCycleEnd,
    AlarmNoStop,
    Warning,
    Information
);
END_TYPE

Ich kann jetzt mit diesem Datentyp eine Variable definieren und dann die Konstante zuweisen:
C-ähnlich: 
VAR
    eAlarm : E_MessageClass;
END_VAR

----------------------------------------------

eAlarm := E_MessageClass.Warning;

IF eAlarm = E_MessageClass.Information
THEN

    // Setze Meldung ab

END_IF;



Klasse:
Eine Klasse ist ganz allgemein eine Gruppe von Eigenschaften (Properties) und Funktionen (Methoden). Ich werde das Anhand eines Zylinder-Bausteins erklären.

Methoden:
Methoden sind Funktionen einer Klasse. Zylinder-Beispiel "Fahre in Grundstellung"

Properties:
Beispiel: Eine Zylinder-Klasse, hat die Eigenschaft "Position In Grundstellung", "Position In Arbeitsstellung","Einstellwerte" usw.

Properties werden in Get- und Set- Methoden / Funktionen aufgeteilt um interne Variablen zu lesen / schreiben.

Kapselung:
Auf Variablen kann nicht direkt und Methoden und Funktionen können je nach Definition von Außen zugegriffen werden.

Bei Siemens kannst du zum Beispiel: fbZylinder.StatischeVariable1 := True setzen. Das geht bei OOP so nicht direkt. Der Zugriff erfolgt über Properties

Bei OOP kannst du auf Variablen über Properties zugreifen z.B. fbZylinder.Property1 := TRUE (Set-Methode), und lesend über die Get-Methode zugreifen.

Vererbung:
Bei der Vererbung kann ich alle nicht PRIVATE "gekapselten" Methoden und Eigenschaften von einer anderen Klasse erben.

Beispiel Zylinder: Die Zylinderklasse erbt die Funktionen und Eigenschaften von einer Basis-Aktor-Klasse mit Funktionen wie Schaltzyklenzähler.

Interface:
Das ist quasi eine Schnittstellendefinition. Diese zwingt den Programmierer die in der Definition angegebenen Methoden und Properties zu programmieren. Das hilft halt vor allem bei der Programmierung von Großen Projekten in einer Gruppe. Und zur Strukturierung.

Beispiel Zylinder-Baustein:
- Ich habe die Definition der Methoden "FahreInGrundstellung", "FahreInArbeitsstellung" und der Properties "InGrundstellung" und "InArbeitsstellung", dann müssen diese Eigenschaften und Methoden auch programmiert werden. Der Kollege der parallel den Handbetrieb programmiert, kann dann seinen FB schon mit der Schnittstelle fertig programmieren und testen obwohl der Zylinderbaustein vielleicht noch nicht fertig ist.




Ich hoffe das reicht ganz grob als Defnition
 
Zuletzt bearbeitet:
Moin mgl,

vielen Dank!

mgl schrieb:
Enumeration:
Zum Vergrößern anklicken....
wäre in meiner Gedankenwelt dann wie ein selbst erstellter Datentyp (UDT).


mgl schrieb:
Klasse:
Eine Klasse ist ganz allgemein eine Gruppe von Eigenschaften (Properties) und Funktionen (Methoden). Ich werde das Anhand eines Zylinder-Bausteins erklären.

Methoden:
Methoden sind Funktionen einer Klasse. Zylinder-Beispiel "Fahre in Grundstellung"

Properties:
Beispiel: Eine Zylinder-Klasse, hat die Eigenschaft "Position In Grundstellung", "Position In Arbeitsstellung","Einstellwerte" usw.

Properties werden in Get- und Set- Methoden / Funktionen aufgeteilt um interne Variablen zu lesen / schreiben.

Kapselung:
Auf Variablen kann nicht direkt und Methoden und Funktionen können je nach Definition von Außen zugegriffen werden.

Bei Siemens kannst du zum Beispiel: fbZylinder.StatischeVariable1 := True setzen. Das geht bei OOP so nicht direkt. Der Zugriff erfolgt über Properties

Bei OOP kannst du auf Variablen über Properties zugreifen z.B. fbZylinder.Property1 := TRUE (Set-Methode), und lesend über die Get-Methode zugreifen.

Vererbung:
Bei der Vererbung kann ich alle nicht PRIVATE "gekapselten" Methoden und Eigenschaften von einer anderen Klasse erben.

Beispiel Zylinder: Die Zylinderklasse erbt die Funktionen und Eigenschaften von einer Basis-Aktor-Klasse mit Funktionen wie Schaltzyklenzähler.



Ich hoffe das reicht ganz grob als Defnition
Zum Vergrößern anklicken....
Ja, das hilft mir!


Meine Analogie zur SIEMENS-Welt:
Ich verstehe das so, dass ich einen FB als (Basis-)Klasse habe. Mit OOP kann ich auf Teile der Programmierung (Funktionen), die darin enthalten sind mit Methoden zugreifen. Das kann ich in TIA erstmal nicht (Ausnahme: Programmierung von Methoden für die OPC UA-Kommunikation). Zudem gibt es keine explizite Bausteinschnittstelle, sondern ich greife per Properties auf Variablen zu. Dann die Kapselung: Ein FB bei TIA ist dafür natürlich offener. Entweder explizit (Bausteinschnittstelle) oder implizit (über den Instanz-DB (mag ich aber nicht)). Bei OOP kann ich nicht direkt lesen/schreiben, was die Übersichtlichkeit verringert, aber die Programmierung vereinfacht. Werden bei Vererbung Änderungen in der Basisklasse dann auch immer direkt in den vererbten Klassen mit gemacht? Sonst wäre das ja, als ob ich einfach einen FB kopiere.

VG
MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DeltaMikeAir schrieb:
Ja gut, aber folgende Aussage:

passt halt irgendwie nicht. Dann dürfte es auf der Steuerung nur einen DB geben für "alle Bausteine"
Zum Vergrößern anklicken....
Ich denke, die Aussage war nicht, dass alles in einem einzigen DB zusammengefasst wird, sondern dass alle DBs, die Daten enthalten, am Ende global definiert sind.
 
Das weiss ich schon.Für mich macht aber OOP nur Sinn wenn man es mit sehr vielen Objekten und Objekteigenschaften/Funktionen zu tun hat.
Gibt es wenige Objekte,Funktionen,Eigenschaften sehe ich jetzt da keinen Vorteil.Um einen Zylinder und dessen Funktionen zu programmieren, würde ich jetzt kein OOP verwenden.Vererbung lasse ich jetzt mal weg.
Weiss nicht wie schwer das zu Pflegen ist.
 
@MFreiberger :
Die OOP, wie hier beschrieben, ist in der Siemens-Welt (jedenfalls zur Zeit noch) nicht wirklich umsetzbar. Von daher fällt es mir auch schwer da Beispiele für die von dir angefragten Schlagworte zu finden. Aber hier mal ein Ansatz :

Methoden : am Beispiel des Zylinders könnten das z.B. sein "Vorfahren" und "Zurückfahren". Anzusprechen in der OOP-Welt wäre das dann über "call FB_Zylinder.vorfahren". Das kann Siemens (natürlich) nicht - was Siemens aber können würde wäre, dass du die in einem FB_Handling die Funktionen "Hole Teil" oder "Bringe Teil" über Binär-Inputs aktivierst.

Properties : sind erstmal ganz stumpf die Schnittstelle eines FB. In der OOP-Welt könnte aber über eine Property auch eine eingelagerte Funktion eines Bausteins angestossen werden, die die z.B. ein Rechenergebnis bringt. Das kann jetzt eine OUT-Variable auch - nur hier wäre das Ergebnis so zusagen In Time ...

Enumeration : ist so nicht richtig, wie du es für dich verstanden hast. Eine ENum-Variable ist z.B. ein INT aber nur mit bestimmten Inhalten. Siemens kann das meines Wissens nicht - in der Beckhoff- / CodeSys-Welt aber würde dir beim debuggen dann der zugewiesene Text und nicht der Wert der Variable angezeigt werden.

Interface : wurde von @mgl erklärt - das macht für mich aber in der SPS-Welt nicht wirklich Sinn - zumindestens wüßte ich jetzt gerade nicht wofür ...

Vererbung : das kann Siemens auch nicht wirklich - Beckhoff / CodeSys schon. Mir fällt dafür jetzt gerade kein SPS-Beispiel ein - im Grunde aber gibst du deinem neuen FB schon die Grundfunktionen des Basis-FB's mit, die du dann modifizieren oder erweitern kannst.
 
Larry Laffer schrieb:
@MFreiberger :
Die OOP, wie hier beschrieben, ist in der Siemens-Welt (jedenfalls zur Zeit noch) nicht wirklich umsetzbar. Von daher fällt es mir auch schwer da Beispiele für die von dir angefragten Schlagworte zu finden. Aber hier mal ein Ansatz :

Methoden : am Beispiel des Zylinders könnten das z.B. sein "Vorfahren" und "Zurückfahren". Anzusprechen in der OOP-Welt wäre das dann über "call FB_Zylinder.vorfahren". Das kann Siemens (natürlich) nicht - was Siemens aber können würde wäre, dass du die in einem FB_Handling die Funktionen "Hole Teil" oder "Bringe Teil" über Binär-Inputs aktivierst.

Properties : sind erstmal ganz stumpf die Schnittstelle eines FB. In der OOP-Welt könnte aber über eine Property auch eine eingelagerte Funktion eines Bausteins angestossen werden, die die z.B. ein Rechenergebnis bringt. Das kann jetzt eine OUT-Variable auch - nur hier wäre das Ergebnis so zusagen In Time ...

Enumeration : ist so nicht richtig, wie du es für dich verstanden hast. Eine ENum-Variable ist z.B. ein INT aber nur mit bestimmten Inhalten. Siemens kann das meines Wissens nicht - in der Beckhoff- / CodeSys-Welt aber würde dir beim debuggen dann der zugewiesene Text und nicht der Wert der Variable angezeigt werden.

Interface : wurde von @mgl erklärt - das macht für mich aber in der SPS-Welt nicht wirklich Sinn - zumindestens wüßte ich jetzt gerade nicht wofür ...

Vererbung : das kann Siemens auch nicht wirklich - Beckhoff / CodeSys schon. Mir fällt dafür jetzt gerade kein SPS-Beispiel ein - im Grunde aber gibst du deinem neuen FB schon die Grundfunktionen des Basis-FB's mit, die du dann modifizieren oder erweitern kannst.
Zum Vergrößern anklicken....
Moin Larry,

vielen Dank für Deine Erläuterungen. Als Quintessenz nehme ich mit, dass vieles mit SIEMENS nicht oder noch nicht geht. Andererseits ist die OOP nur bedingt auf einer SPS sinnvoll (nach aktuellem Stand).

VG
MFreiberger
 
Eine Klasse ist eine allgemeine Beschreibung eines Objektes mit Funktionen und Eigenschaften.
Erst die Definition eines Objektes erstellt eine Instanz aus der Klasse.So war das früher unter C++.
Und hier ist der entscheidende Punkt.Habe ich viele solcher Objekte spielt die OOP die funktionale Programmierung aus.
Vor allem wenn diese Objekte miteinander kommunizieren.Gleiches gilt vice versa.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OOP ist doch auch eine Frage der Perspektive.

Hier wurden einige essentielle Eigenschaften von OOP aufgelistet. Allerdings nach den Maßstäben von Hochsprachen.
In der diesbezüglich eingeschränkten SIEMENS-SPS-Welt kann man mit objektorientierter Arbeitsweise aber trotzdem die Programmiereffizienz deutlich steigern. Vor allem in Verbindung mit Bildbausteinen für die Visualisierung.
Die Systemfunktion Program_Alarm für das Meldungswesen muss eigentlich auch erwähnt werden. Die Alt-ehrwürdigen Bitmeldungen am HMI werden ihre Daseinsberechtigungen haben, effizienter zum Programmieren ist aber das PLC-Meldesystem - denn das eignet sich hervorragend für OOP
 
Ob ein Bildbaustein als OOP zu betiteln ist, weiss ich nicht.
Ist ja im Grunde genommen ein Template mit verschiedenen Datensätzen.Das Gegenstück wäre in der SPS ein FB.
 
Nein ... eigentlich ist ein Bildbaustein schon ein gutes Beispiel für OOP. Du hast in ihm u.U. mehrere Objekte, und aber "nur" eine zusammenfassende Schnittstelle - also ähnlich einem UserControl aus der :Net-Welt. Das passt also schon ...

Aber grundsätzlich macht es schon Sinn in der SPS-Welt Objekt-orientiert zu programmieren - es ist halt ein Frage, wie man es anstellt. Solche Objekte können ja z.B. Teil-Bausteine sein. Ein IEC-Timer wäre danach schon so ein Objekt. Aber genauso könnte man auch einen FB-Handling (z.B.) erstellen, den man universell einsetzen kann ... Dergleichen Beispiele gäbe es schon viele wenn man will ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sehe ich etwas anderst.Erst wenn sich hinter einem Objekt viele Eigenschaften und Funktionen verbergen lohnt sich dieser Aufwand.
Als Bsp. das Autorennen.Dort fahren unzählige gleiche Objekte gegeneinander mit vielen Eigenschaften und Funktionen.
Darum heisst es ja objektorintiert.Diese Objekte sollen, wie in der realen Welt ein komplexes Gebilde mit vielen Ausprägungen nachbilden.
 
meiner Meinung nach eben eine Frage der Perspektive. Wenn der Begriff OOP für`s Siemens-SPS-programmieren nicht gefällt, müsste man halt eine neue Bezeichnung definieren. Aber bis es soweit ist, sehe ich weiterhin viele Parallelen dieser in der Realität sehr unterschiedlichen Plattformen
 

Similar threads

M
OOP und Zugriff auf Methoden und Eigenschaften einer Instanz des Klassenobjekts innerhalb anderer POUs
Antworten
6
Aufrufe
2K
DerOnkel
D
Grimsey
TIA Gelöst: ProfiNet-Namen nach Neustart weg
2
Antworten
31
Aufrufe
2K
Grimsey
Grimsey
H
Siemens Active Line Modul Fehler 6200 und 30031
Antworten
8
Aufrufe
3K
Houns89
H
J
TIA keine TCP Verbindung herstellbar TIA V17 CPU 1513
Antworten
16
Aufrufe
2K
Rabi
R
Botimperator
Schmale Thyristorsteller als Ersatz für Eurotherm 7300S
Antworten
9
Aufrufe
4K
Botimperator
Botimperator
Zurück
Oben