UML zur Beschreibung von SPS Software

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätten dann aber mal wirklich eine Aussage zu den "riesigen Vorteilen", dann könnte ich ja mal darüber nachdenken.
Was geht wirklich besser, was man nicht jetzt schon mit FB's erledigen kann?

Bei S7 oder TIA nix. Mit der Kombination aus FBs, Instanz- und Global-DB kannst quasi objektorientiert arbeiten. Es tun auch viele SPSler schon seit Jahren ohne dass sie sich bewusst sind, dass das OP sein könnte.
Diese Diskussion um OOP in der Automatisierung haben wir schon vor 15Jahren geführt beim Umstieg von S5->S7.
Für uns "altmodische, ewig Gestrige" ist es halt ein Zylinder mit einem 5/2-Wege-Ventil und 2 Ini's.
Für einen OOPler ist es Objekt vom Typ Zylinder mit den Methoden Einfahren und Ausfahren und den Eigenschaften eingefahren, in Bewegung, ausgefahren.

Gruß
Dieter

 

[IBFS]

Das gleiche gilt übrigens (generell) für Dokumentation: Keiner macht sie gerne, keiner kalkuliert die Zeit dafür ein und spätestens bei der IBN wird die Aktualisierung etwaiger Doku wieder geschludert. Auch hier gibt es viel Optimierungspotential.

Das gleiche gilt übrigens (generell) für Dokumentation:

- keiner sieht den Extraaufwand und daher will keiner die zusätzliche Mannwoche bezahlen.

- egal wie gut diese ist, keiner ließt sie vorher, während oder nach der Übergabe.

Neulich habe ich auf die Frage nach einer speziellen Funktion in der Anwortmail einfach die passende Seitennummer zurückgemailt ;-)

Ansonsten Herr "Majestic_1987" Allgemeinplätze wohin man schaut ;-)

Frank

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für uns "altmodische, ewig Gestrige" ist es halt ein Zylinder mit einem 5/2-Wege-Ventil und 2 Ini's.
Für einen OOPler ist es Objekt vom Typ Zylinder mit den Methoden Einfahren und Ausfahren und den Eigenschaften eingefahren, in Bewegung, ausgefahren.

Es reden die am abstraktesten, die in der Realität am entferntesten von der Materie sind.
Das ist nachvollziehbar, aber sollte nicht dazu führen das die, die am weitesten weg sind am lautesten rufen sollten.

Frank

 

[Blockmove]

Es reden die am abstraktesten, die in der Realität am entferntesten von der Materie sind.
Das ist nachvollziehbar, aber sollte nicht dazu führen das die, die am weitesten weg sind am lautesten rufen sollten.

Schöner Spruch

Als ich mit der SPS-Programmierung anfing, gab es Weg-Zeit-Diagramme. Richtig schön mit Aktoren, Sensoren und Wirklinien.
Dann kamen die Flowcharts
Später dann Nassi-Shneidermann-Diagramme
Dann hieß die Weiterschaltbedingung auf einmal Transition und die Befehlsausgabe war die Aktion und aus "=" wurde "N".
Irgenwann wurden die Zustandsgraphen hervorgeholt und alles waren Automaten.
Und in diese Automaten werden jetzt halt Objekte eingebaut.

Aber egal welche Mode gerade aktuell ist, eigentlich gibt es für mich nur 2 Sorten SPS-Programme:
Gute Programme und Scheiß-Programme :sm11:


Gruß
Dieter

 

[Werner29]

Also wer behauptet, dass es keine Objektorientierung in der SPS-Programmierung gibt, der hat entweder die letzten Jahre verschlafen oder ist ignorant. In der IEC sind objektorientierte Erweiterungen definiert, sowohl Klassen (hier dann eben in Form des FB), Methoden, Interfaces, Vererbung, etc.

Fakt ist aber, dass diese Erweiterungen in CoDeSys 3.x drin sind, somit auch in IndraWorks und TwinCAT 3, nicht aber in der S7 (und wohl auch in absehbarer Zeit nicht kommen werden).

Vorsicht: die OO ist noch nicht normiert, voraussichtliches Datum der Veröffentlichung ist Februar 2013. Dort wird OO ein zentraler Teil sein.

Bernhard

 

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätten dann aber mal wirklich eine Aussage zu den "riesigen Vorteilen", dann könnte ich ja mal darüber nachdenken.
Was geht wirklich besser, was man nicht jetzt schon mit FB's erledigen kann?

FB's sind ja tatsächlich ein bisschen OO und waren seinerzeit auch umstritten ("Wieso muss ich da eine Instanz deklarieren?").
Ich bin im Grunde genommen hier der Schuldige, ich habe OO in CODESYS V3 implementiert.
Trotzdem will ich niemanden bekehren. Wer ohne OO auskommt, und keinen Mangel spürt, der soll doch so programmieren, wie es ihm gefällt.
(am besten natürlich mit CODESYS).

Ich drehe mittlerweile die Frage immer um: das Prinzip OO muss nicht mehr begründet werden, das hat sich weltweit durchgesetzt.
Wer sagt, OO bringt keine Vorteile bei der SPS-Programmierung, der muss begründen, warum das so sein sollte. Mir leuchtet das nicht ein.
Das Prinzip OO hängt nicht an der Aufgabe, es spielt keine Rolle, ob man einen Antrieb programmiert oder einen Compiler schreibt.
OO hat immer da Vorteile, wo man grosse, komplexe Programmieraufgaben beherrschen muss. Deswegen ist es auch so schwer, die Vorteile
an einem kleinen Beispiel zu erläutern.
Wir haben ja jetzt auch ein bisschen Erfahrung damit und im Moment ist es so, dass nur wenige Projekte die OO benutzen. In Bibliotheken
wird sie jedoch viel eingesetzt.

Bernhard Werner

 

[Ralle]

@Werner29

Ja, in Bibliotheken, entsprechend gut getestet und dokumentiert, kann ich mir das vorstellen.

Ich hab ja lange Delphi7 programmiert und dann ein wenig mit Visual#.
Da erlebte ich dann die ersten Pleiten weil ich in Objekt XY irgendwelche Daten schrieb, sich aber nciht das korrekte Ergebnis einstellte (ohne irgendwelche Fehlermeldungen). Der Fehler lag bei mir, aber er war kaum offen ersichtlich und das macht mir in einer SPS dann doch so große Bauchschmerzen. Ich hätte schon gerne rel. strenge Regeln und einen Compiler der auch moniert, was zu monieren ist und mich nicht einfach machen läßt, bis die 5 Mio. Anlage in den Schrott kann. Das ist jetzt nur eine allg. Forderung, die nichts mit eurer V3 zu tun hat, dafür hatte ich einfach noch keine Zeit, ich hab schon genug mit V2.3 zu tun.