TIA S7-1500 Objektorientierte programmierung

N

Not-Aus

Level-2
Beiträge
87
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo alle, wie kann ich objektorientiert ala 61131-3 3.edition/Hochniveau-sprachen programmieren?

Ich glaube daran, dass objektorientierung in Themen wartbarkeit und modularität hilft.(?)

Bisher habe ich kleine Funktionen ("Methoden"), die UDT's via InOut bearbeitet, als eine art hausgemachte objektorientierung programmiert,. Ich vermisse Interfaces und "echte" Methoden. Ich wollte das Observer Entwurfsmuster implementieren, aber scheiterte wegen die nicht vorhandene Funktionalität in TIA.

Danke!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OOP ist zwar für viele SPSler ein Reizwort, aber Basisfunktionen wie Kapselung, Methoden und Eigenschaften, hätten schon massive Vorteile.
Nur solange Siemens am bisherigen Steinzeitkonzept festhält, hat man eben nur geringe Möglichkeiten.

Beim ganzen Thema OOP muss man aber eines Betrachten:
Du darfst SPS-Programmierung nicht PC-Programmierung vergleichen.
Und zwar ganz speziell bei der Fehlersuche. Singlestep ein Programm zu debugen geht bei einer SPS zu 99,99% nicht.
Als Instandhalter sucht man einer Anlage erstmal per Querverweis bzw. "Gehezu Verwendungsstelle".
Und das kann heute schon bei voll parametrierten Bausteinen bzw. per Zeigerübergabe von UDTs sehr schwierig sein.
Würde man dann noch Dinge wie z.B. Vererbung einsetzen, dann kann es richtig heftig werden.
Wir schreiben die Programme schließlich nicht für uns, sondern für Kunden und Anwender.
Nicht alles was für uns als Programmierer gut ist, taugt auch für andere.

Gruß
Blockmove
 
tja Reizthema ;)
frueher hat der Instandhalter in EINEM FUP Netzwerk online gesehen, warum der Motor grad nicht freigegeben wird. Darf der heute ueberhaupt noch in das tolle OOP Programm reinschauen? Dafuer möchte er dann aber die aktuellen Verriegelungen ala FUP oder KOP auf dem HMI visualisiert haben... oder er ruft dann halt gleich beim Programmierer an (in der Nacht am Wochenende)
machts das wirklich alles besser? Aber natuerlich sind die Anforderungen in jedem Projekt anders.
Gruss.
 
Hallo alle und danke für ihre Antworten. :)

Ich stimme 100% zu, dass Instandhaltung ist wichtig, und FUP und AWL kann gute Sprachen sein für Verriegelungsbausteine uzw.

Aber wie ist es mit die "firmeninterne" verschlüsselte Bausteine, (kommunikation zwischen verschiedene Programteile, HMI uzw, uzw) Ist OOP geeignet für sowas?

Ich bin offen für andere Vorschläge/Vorgehensweise falls man modularität und wartbarkeit mittels andere Funktionalitäten in TIA erreichen kann! :D

Danke
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ducati schrieb:
tja Reizthema ;)
frueher hat der Instandhalter in EINEM FUP Netzwerk online gesehen, warum der Motor grad nicht freigegeben wird. Darf der heute ueberhaupt noch in das tolle OOP Programm reinschauen? Dafuer möchte er dann aber die aktuellen Verriegelungen ala FUP oder KOP auf dem HMI visualisiert haben... oder er ruft dann halt gleich beim Programmierer an (in der Nacht am Wochenende)
machts das wirklich alles besser? Aber natuerlich sind die Anforderungen in jedem Projekt anders.
Gruss.
Zum Vergrößern anklicken....

*ACK*

Genauso ist bei vielen Anlagen heute die Situation.
Aber das hat noch nicht mal was mit OOP zu tun.
Viele Kollegen bringen das heute schon wunderprächtig mit den Mitteln von S7-Classic fertig.

OOP wäre eigentlich in der Automatisierungstechnik was wunderschönes.
Schließlich haben wir es wirklich mit Objekten zu tun.
Was bislang aber fehlt, sind entsprechende Entwicklungsumgbungen mit den passenden Tools zur Beobachtung und Fehlersuche.
Solange ich mich durch Aufrufpfade, Parameterübergaben, Instanzen, UDTs und sonstwas durchhangeln muss, wird das nix.


Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
zako schrieb:
... im TIA Portal Umfeld kannst Du mit OOP arbeiten (SIMOTION), siehe :
http://w3.siemens.com/mcms/mc-syste...ing-software/oop/Seiten/oop.aspx#Beschreibung
Zum Vergrößern anklicken....

Na toll ... mal wieder typisch Siemens :p
Simotion hat CFC und nun auch OOP und der Rest bekommt die Brotkrümmel.

Man braucht sich wirklich nicht wundern warum Firmen wie Beckhoff so ein Wachstum haben :ROFLMAO:
 
Aber so richtig OOP hab ich in der freien Wildbahn bei Beckhoff auch noch nicht erlebt, obwohl es ja immerhin geht.

PS Ich glaube nicht, dass OOP in der Anlage wirklich was bringt. Bei Bibliotheken mag das anders sein, wenn die dann ordentlich gepflegt werden.
 
Braucht man OOP wirklich?
Wenn ich mir Software anschaue, die mit OOP entwickelt wurden, und wie oft da Updates notwendig sind.:rolleyes:
Die Software für eine Maschine / Anlge wird entwickelt und dann soll, nein die muss dann 10 jahre und länger fehlerfrei funktionieren.
Wenn bei OOP ein Fehler sich zeigt, wer macht wie den Update?
Das kann KEINEM Kunden zugemutet werden.
Und die Aussage Beckhoff und Co haben so viel tatsätzlichen Zuwachs, habe ich noch nicht gesehen.
Selbst für kleine Zulieferbänder wollen die Kunden Big$ unddazu das Programm auf Datenträger(zum Glück ist das mit Ausdruck inzwischen vom Tisch ;) )


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
bike schrieb:
Braucht man OOP wirklich?
Zum Vergrößern anklicken....

Natürlich nicht :p
Aber nehmen wir mal als Beispiel die Diskussion Global-DB vs. Instanz-Zugriff.
Setzt man OOP vernünftig um, dann hat man von beiden Möglichkeiten die Vorteile.
Die Basis von OOP ist eben, dass Daten und Code eines Objekt zusammengehören
Alleine das würde heute schon manches übersichtlicher machen.

Weitergehende Dinge wie Vererbung oder Überladen sehe ich auch kritisch.
Die Konzepte sind sicherlich interessant, jedoch steht und fällt das Ganze mit den Möglichkeiten zur Fehlersuche.

Gruß
Blockmove
 
Interessante Diskussion! :)

Also, Vererbung und Überladen = Nein. Das kann ich auch zustimmen wegen Fehlersuche.
Aber Interfaces und Datenkapselung mit Methoden sind meiner Meinung nach interessante Themen. Auch die Möglichkeit ein Referenz zu andere Objekte zu speichern (kann auch statisch sein wegen fehlersuche).

Ich wollte eigentlich das Observer Entwurfsmuster benutzen, um die Kommunikation zu andere Programteile mittels Notify() methoden gewährleisten. Wie kann ich das mittels prozedurale/TIA portal programmierung lösen? Globale daten?

Danke! :D
 
Not-Aus schrieb:
Interessante Diskussion! :)

Ich wollte eigentlich das Observer Entwurfsmuster benutzen, um die Kommunikation zu andere Programteile mittels Notify() methoden gewährleisten. Wie kann ich das mittels prozedurale/TIA portal programmierung lösen? Globale daten?

Danke! :D
Zum Vergrößern anklicken....
Welche Informationen sollen denn zwischen den Programmteilen ausgetauscht werden?
Vielleicht reicht es ja wenn du mit Auftragsfächern arbeitest.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
miasma schrieb:
Welche Informationen sollen denn zwischen den Programmteilen ausgetauscht werden?
Vielleicht reicht es ja wenn du mit Auftragsfächern arbeitest.
Zum Vergrößern anklicken....

Ich möchte Erreignisse in Subsystem A das Subsystem B mitteilen ohne starke koppelung. Oder auch Information von Subsystem zum "Supersystem". Jede Subsystem soll für eine Aufgabe verantwortlich sein.

Ist es auch möglich Ereignisse das HMI zuzuführen ohne starke koppelung (kann HMI wechseln ohne grosse umprogrammieren?). Ich denke klare, einfache Schnittstellen, aber es ist im Praxis nicht so einfach (für mich).

Bitte mehr über Auftragsfächern schreiben! :D

Gruss
 
Lustiger Ansatz ... Vererbung ist kritisch ... aber Interfaces wären etwas ...
Wenn ich OOP machen möchte dann wäre Vererbung mein allererster Ansatz.
Interfaces machen m.E. nur dann wirklich Sinn, wenn ich auch mit Reflektionen arbeiten kann - aber macht so etwas in der SPS-Welt überhaupt Sinn ?

Ich würde aber auch sagen, dass sowohl Siemens wie auch Beckhoff von einer vernünftigen Umsetzung desselben noch meilenweit entfernt sind (-> wobei ich durchaus zugeben würde, dass TwinCat und CodeSys da schon ein gutes Stück weiter sind als Herr S.).

Gruß
Larry
 
Larry Laffer schrieb:
Ich würde aber auch sagen, dass sowohl Siemens wie auch Beckhoff von einer vernünftigen Umsetzung desselben noch meilenweit entfernt sind (-> wobei ich durchaus zugeben würde, dass TwinCat und CodeSys da schon ein gutes Stück weiter sind als Herr S.).
Zum Vergrößern anklicken....

... da erzählt auch wieder jeder was anders. Hast Du Dich wirklich mit beiden Systemen so intensiv auseinandergesetzt, dass Du solche Aussagen bzgl. der OOP- Umsetzung machen kannst?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry Laffer schrieb:
Lustiger Ansatz ... Vererbung ist kritisch ... aber Interfaces wären etwas ...
Wenn ich OOP machen möchte dann wäre Vererbung mein allererster Ansatz.
Interfaces machen m.E. nur dann wirklich Sinn, wenn ich auch mit Reflektionen arbeiten kann - aber macht so etwas in der SPS-Welt überhaupt Sinn ?

Ich würde aber auch sagen, dass sowohl Siemens wie auch Beckhoff von einer vernünftigen Umsetzung desselben noch meilenweit entfernt sind (-> wobei ich durchaus zugeben würde, dass TwinCat und CodeSys da schon ein gutes Stück weiter sind als Herr S.).

Gruß
Larry
Zum Vergrößern anklicken....

Der Code muss nachvollziehbar bleiben. Daher sehe ich Vererbung bei SPS-Programmen kritisch.
In SPS-Programmen muss sich auch bzw. besonders ein Instandhalter zurecht finden können.
Vererbung ist natürlich ganz besonders für "reale Objekte" (Zylinder, Achsen, Transportbänder) geeignet.
Also genau da, wo oft Fehlersuche notwendig sein kann. Wird der Code hier schwer nachvollziehbar, kann es unnötig kompliziert werden. Nicht alles was für Programmierer nützlich ist, taugt auch für andere :p

Gruß
Blockmove
 
zako schrieb:
... da erzählt auch wieder jeder was anders. Hast Du Dich wirklich mit beiden Systemen so intensiv auseinandergesetzt, dass Du solche Aussagen bzgl. der OOP- Umsetzung machen kannst?
Zum Vergrößern anklicken....

Gegenfrage :
Hast du dich schon mal mit einem System (z.B. .Net-Programmierung unter Visual Studio) auseinandergesetzt, das das kann und verglichen ?

Immerhin kann Beckhoff schon mal Inherits (also Vererbung), wenn ich mir hinsichtlich der im Hintergrund wirklich erfolgenden Umsetzung nicht so ganz sicher bin. Ich meine auch, dass die Interfaces können (wenn ich auch nicht so genau weis wofür).
Bei Siemens ist da komplett Fehlanzeige.
Natürlich kann man (auch schon in der Welt von S7-Classic) Objekt-Orientiert programmieren - nämlich so, wie es schon verdeutlicht wurde : Dinge, die zusammen gehören, auch zusammengehörig umsetzen. Das ist m.E. aber erst der Anfang ...

@Dieter:
Wenn ich mir die Programm-Derivate von vielen SPS-Programmierern so ansehe dann verstehe ich deine Bedenken vollkommen und gebe dir da Recht. Die meißten SPS-Programme, die ich so sehe, werden ja von den jeweiligen Programmieren schon ein paar Tage nach dem Erstellen nicht mehr wirklich verstanden - und dann noch OOP ... vollkommen richtig.
Trotzdem bleibe ich dabei : richtig und strukturiert und mit dem nötigen Weitblick umgesetzt kann da etwas richtig Tolles entstehen ... oder eben auch genau das nicht - alles ist immer ein 2-schneidiges Schwert ...

Gruß
Larry
 
Ist doch sowieso eine weitgehend sinnfreie Nebeldiskussion.
Fakt ist, die 12/1500er betreffend gibt es derzeit nix in der Richtung.

Da braucht man jetzt dann auch nicht über fiktive Vor/Nachteile beim Anwenden/Debugging diskutieren.
 
Zurück
Oben