Programmiersprachen

Zuviel Werbung?
-> Hier kostenlos registrieren
Wer OPP behutsam einsetzt macht sein System wartbarer. Letztlich macht er sich selbst und den Kunden damit glücklicher.


Ja klar so wie bei Win$.
Ein FB kann als ein Objekt angeschaut werden, doch hat es mit OOP nicht so echt viel zu tun.

Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
Doch was ist wenn der Kunde dies nicht will?
Und denkst du auch die Nachfolger, die deinen Programm warten und ggF weiter entwickeln müssen?


bike


P.S: ich warte immer noch auf ein Beispielprogramm, das mit OOP programmiert werden muss.
 
Ja klar so wie bei Win$.

Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
Doch was ist wenn der Kunde dies nicht will?
Und denkst du auch die Nachfolger, die deinen Programm warten und ggF weiter entwickeln müssen?

Wenn der Kunde es nicht will, ist es seine Entscheidung. Und da OOP gut wartbar ist, wird auch ein Nachfolger damit zurechtkommen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
P.S: ich warte immer noch auf ein Beispielprogramm, das mit OOP programmiert werden muss.

...ich warte mit :ROFLMAO:

Da war einmal ein neuer Programmierer in einer mir nahestehenden Firma.
Schlauer Kerl, kam frisch von der UNI und wollte jede Station einer Maschine
schön verpacken - alles mit Pointer durchreichen über zwei FB-Layer usw.
Für die UNI war das SPS-Programm gut geeignet, aber in der Praxis gingen
dann die liebgewonnenen Funktionen "Referenzdaten" nur sehr schwerlich.

Frank
 
Vielleicht liegt es daran, dass ich neu beim Programmieren bin.

Wozu brauche ich Vererbung bei einer PLC?
Schnittstellen zu standardisieren ist mit normaler Programmierung ohne Probleme möglich.
Warum überladen? Ein zweites Objekt ist auch keine Sünde.

Bis heute hat mir noch niemand einen Programmcode gezeigt, bei dem OOP wirklich sinnvoll ist.

Durch die Komplexität des Programmes wird es immer schwerer ein Programm sinnvoll zu testen.
Unabhängig davon, dass es schwerer für Außenstehende wird die Anlagen zu warten.
Es wird leider immer wieder vergessen, dass wir für die Kunden arbeiten.


OOP und die Zuverlässigkeit von WIn$ passen nahtlos zusammen.



bike

Hallo Bike,

wozu braucht man Vererbung?
Um nicht ständig den gleichen Code neu zu schreiben!
In meiner letzten Firma haben wir z.B. 3 FBs für fast gleiches Module gehabt. Der Gleichanteil lag bei etwa 80%. Wenn ich etwas am gleichen Anteil geändert habe, musst ich dies 3 mal machen!

Was ist dann passiert:
Wie alle Programmierer bin ich ziemlich faul! :-D
Also, 2 mal copy and paste. Leider habe ich dabei aber einen Fehler gemacht, so dass der FB nicht mehr sauber gearbeitet hat. Festgestellt habe ich es erst einige Monate später, da diese FBs voher nicht benutzt wurden. So was kann ganz schön schmerzhaft und teuer sein.

Die andere Variante ist alles in einem Fb zu machen und die unterschiede mit cases und ifs abzufangen. Daraus wird über einen längeren Zeitraum ganz schöner Spaghetti-Code. Viel Spaß damit!

Warum überladen? Siehe oben!

Was zum Teufel ist win$? Siemens? Wenn Du den Verein meinst, kann ich Dich beruhigen, die sind von OOP so weit entfernt, wie der Mars von der Erde.

OOP ist im Übrigen ein Mittel um komplexe Problem zu lösen und nicht zu erschaffen. Ein falscher OOP Ansatz kann aber durchaus problematisch werden. Ist aber bei allen anderen Methoden genauso.

Gruß

dummy
 
Ja klar so wie bei Win$.
Ein FB kann als ein Objekt angeschaut werden, doch hat es mit OOP nicht so echt viel zu tun.

Wenn du es schaffst den Kunden deinen Programmierstil aufzuschwatzen, dann gut.
Doch was ist wenn der Kunde dies nicht will?
Und denkst du auch die Nachfolger, die deinen Programm warten und ggF weiter entwickeln müssen?


bike


P.S: ich warte immer noch auf ein Beispielprogramm, das mit OOP programmiert werden muss.

Hier ein Beispiel von 3S:

http://www.3s-software.com/index.shtml?de_v3_oop&sitesearchmatch=oop#sitesearchmatch

Ist sicherlich nur ein einfaches Beispiel, dass bestimmt nicht objektorientiert Programmiert werden muss!

Aber was muss schon! Ich kann auch alles mit AWL programmiern oder noch besser den Locher für den Lochstreifen aus dem Keller holen :rolleyes:

Gruß dummy
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Bike,

wozu braucht man Vererbung?
Um nicht ständig den gleichen Code neu zu schreiben!
In meiner letzten Firma haben wir z.B. 3 FBs für fast gleiches Module gehabt. Der Gleichanteil lag bei etwa 80%. Wenn ich etwas am gleichen Anteil geändert habe, musst ich dies 3 mal machen!

Was ist dann passiert:
Wie alle Programmierer bin ich ziemlich faul! :-D
Also, 2 mal copy and paste. Leider habe ich dabei aber einen Fehler gemacht, so dass der FB nicht mehr sauber gearbeitet hat. Festgestellt habe ich es erst einige Monate später, da diese FBs voher nicht benutzt wurden. So was kann ganz schön schmerzhaft und teuer sein.

Einen Baustein ohne Prüfung raus zuschicken ist dumm. Egal ob vererbt oder neu geschrieben.


Die andere Variante ist alles in einem Fb zu machen und die unterschiede mit cases und ifs abzufangen. Daraus wird über einen längeren Zeitraum ganz schöner Spaghetti-Code. Viel Spaß damit!

Man kann sehr wohl sauber programmieren, ohne dass gleich Spagetti wird. Das liegt nur an der Planung der Funktion(en)

Was zum Teufel ist win$?

Nein, das ist ein Verein in Redmond, der es perfekt schafft Bugfix als Neuerungen für viele $ zu verkaufen.

OOP ist im Übrigen ein Mittel um komplexe Problem zu lösen und nicht zu erschaffen. Ein falscher OOP Ansatz kann aber durchaus problematisch werden. Ist aber bei allen anderen Methoden genauso.

Gruß

dummy

Ich weiß schon was OOP ist und verwende es auch in Programmen, aber bitte nicht in der PLC.

Wenn ich in VB oder C(mit Abkömmlingen) oder Delphi schreibe nutze ich OOP auch, denn da macht es Sinn und ist ein Teil der Grundlagen der Sprache.


bike
 
Einen Baustein ohne Prüfung raus zuschicken ist dumm. Egal ob vererbt oder neu geschrieben.




Man kann sehr wohl sauber programmieren, ohne dass gleich Spagetti wird. Das liegt nur an der Planung der Funktion(en)



Nein, das ist ein Verein in Redmond, der es perfekt schafft Bugfix als Neuerungen für viele $ zu verkaufen.



Ich weiß schon was OOP ist und verwende es auch in Programmen, aber bitte nicht in der PLC.

Wenn ich in VB oder C(mit Abkömmlingen) oder Delphi schreibe nutze ich OOP auch, denn da macht es Sinn und ist ein Teil der Grundlagen der Sprache.


bike

Hallo Bike,

ich kann Dich beruhigen. Der vehlerhafte Code ist nicht mit ausgeliefert worden. So dumm, bin ich dann doch nicht............

Warum man OOP nicht in der SPS benutzen sollte ist mit allerdings immer noch nicht klar. Im Übrigen kann man nur wirklich OOP-Programmieren, wenn das Tool es unterstützt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe hier mal einen Entwurf für einen Artikel für eine Fachzeitschrift angehängt (leider in englisch).
Darin zeige ich, wie wir (für unsere Systembibliotheken) die Objektorientierung einsetzen, ohne dass ein Benutzer der Bibliotheken davon überhaupt was mitbekommt. Die Grundidee kommt eigentlich von den Motion Control Blöcken der PLCOpen.
Der Artikel ist dann mit einem anderen Beispiel erschienen, das ist vielleicht auch interessant und hier
http://www.3s-software.com/index.shtml?en_publications&news=IEEE_BW_2010
zu finden.
 

Anhänge

  • IEEEPaper1Version.pdf
    73,1 KB · Aufrufe: 19
Aber was muss schon! Ich kann auch alles mit AWL programmiern oder noch besser den Locher für den Lochstreifen aus dem Keller holen :rolleyes:

Gruß dummy

Mit der Aussage hast du recht.
Schreibe ein Programm so, dass es kein anderer nicht bzw nur nach viel Aufwand versteht, dann bist du unabkömmlich.
Ich denke du kennst Lochstreifen nicht und kannst so auch nicht programmieren.


bike
 
Mit der Aussage hast du recht.
Schreibe ein Programm so, dass es kein anderer nicht bzw nur nach viel Aufwand versteht, dann bist du unabkömmlich.
Ich denke du kennst Lochstreifen nicht und kannst so auch nicht programmieren.


bike

Was willst Du mir damit sagen?
Das OOP dafür da ist damit andere das Programm nicht verstehen oder
das Du OOP nicht verstehst?

Ansonsten hat es nichts mit dem Thema zu tun.
Ist Dir langweilig oder willst Du nur ein sehr interesantes Thema zerreden?

In einer Sache gebe ich Dir recht.
Ich kann keine Lochstreifen programmieren!
 
Was willst Du mir damit sagen?
Das OOP dafür da ist damit andere das Programm nicht verstehen oder
das Du OOP nicht verstehst?

Ansonsten hat es nichts mit dem Thema zu tun.
Ist Dir langweilig oder willst Du nur ein sehr interesantes Thema zerreden?

In einer Sache gebe ich Dir recht.
Ich kann keine Lochstreifen programmieren!

Warum so nett?
Weil ich anderer Meinung bin?

Also ich kann Hochsprachen und auch OOP.
Langweilig ist mir nicht.
Ich schreibe aus der Erfahrung, da ich seit längerem programmiere und eben gelernt habe zu differenzieren, wann was und wie sinnvoll ist.
Interessantes Thema? Also bei uns ist OOP in der Entwicklung von PLC Programmen kein Thema, da es nach unserer Meinung nicht sinnvoll ist.

Es ist aber immer schön zu lesen was und wie Jungdynamiker alle paar Jahre die Maschinenprogrammierung revolutionieren (wollen).


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist eben sogenanntes Elitedenken. Weder Alter noch Erfahrung schützen vor Torheit :ROFLMAO:

Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden. Und wer eine SPS programmieren kann, der wird auch OOP so anwenden, dass es andere verstehen. Bei grösseren System wird das ganze damit auch verständlicher und vor allem lassen sich die Komponenten dann auch leichter unabhängig testen. Wer es nicht fertigbringt gute OOP-Programmierung abzuliefern, wird auch mit Nicht-OOP nichts vernünftiges ausliefern.

Alles andere ist FUD.
 
Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden.

In einem aktuellen Projekt "musste" ein bestimmter Standard (OOP-ähnlich) verwendet werden.
Im anschl. Controlling fand man heraus, dass die IB-Zeit mit diesem OOP-Stil
auf Basis von CoDeSys fast doppelt so hoch war, als mit den alten klassischen
Strukturen in STEP7.

Das hat was mit oft "endlosem" Deklarieren zu tun, die ein Übermäßiges
Kapseln mit sich bringt.

In PC-Applikationen bin ich der letzte, der etwas gegen OOP sagen würde,
aber in der SPS-Technik funktioniert OOP führt mich nur, wenn die
Schreib- und Deklarierarbeit im Rahmen bleibt.

Wenn du einmal in CoDesys V2.3 in ST (STRUCTURD TEXT) endlose
FB-Deklarationen wie Matrioshkas ineinander packen musstest - ohne
Kontexthilfe - dann sieht du möglicherweise manches anders :ROFLMAO:.

Frank
 
In einem aktuellen Projekt "musste" ein bestimmter Standard (OOP-ähnlich) verwendet werden.
Im anschl. Controlling fand man heraus, dass die IB-Zeit mit diesem OOP-Stil
auf Basis von CoDeSys fast doppelt so hoch war, als mit den alten klassischen
Strukturen in STEP7.

Frank

Ich glaub dir das. Ich denke auch mehr an einen Mix aus konventionellem Code und Objekten. Ich denke zur Zeit nur an Rundtische mit mehr als 4 Prozessen und Montrac-Anlagen. Wie schön wäre es gewesen, OOP dort einzusetzen, wenn man per Vererbung, die Grundstrukturen für jeden Prozess schon fertig hat. Das sieht dann schöner aus, als einen FB im FB zu instanzieren und die IO durchzureichen und sollte lesbarer sein.

Ich denke aber auch an die Kommunikation zwischen Labview (Testsystem) und der SPS. So etwas schreit förmlich danach, vor allem weil ich es ständig brauche.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist eben sogenanntes Elitedenken. Weder Alter noch Erfahrung schützen vor Torheit :ROFLMAO:

Entweder taugt OOP etwas oder es taugt nichts. Wenn es taugt, dann gibt keinen Grund es nicht im Bereich von SPSen anzuwenden. Und wer eine SPS programmieren kann, der wird auch OOP so anwenden, dass es andere verstehen. Bei grösseren System wird das ganze damit auch verständlicher und vor allem lassen sich die Komponenten dann auch leichter unabhängig testen. Wer es nicht fertigbringt gute OOP-Programmierung abzuliefern, wird auch mit Nicht-OOP nichts vernünftiges ausliefern.

Alles andere ist FUD.

Hab ich dir auf die Füße getreten?
Das tut mir leid.
Die Kunst besteht darin, eine Anlage so zu strukturieren, dass die einzelnen Teile für und in sich in Betrieb und getestet werden können.
Wenn bei der Inbetriebnahme bei der 4. Station ein Fehler auftritt und die Funktion geändert werden muss, dann beginnst du mit der Inbetriebnahme wieder von vorne.
Das kann es nicht sein.

Daher setzt sich ja OOP bei PLC noch? nicht durch, das hast du richtig erkannt.
Für jede Aufgabenstellung sollte das richtige Werkzeug genommen werden.

Und deine Erfahrung mit LabView kannst du nicht auf Maschinen und Anlagen anwenden, würde ich sagen.
Wenn wir zeitkritisch programmieren, dann wird jedes Bit mehrmals überprüft, ob es notwendig ist.

Wie IBFS geschrieben hat, steht der Aufwand für OOP Entwicklung in keinem Verhältnis zum Ergebnis.
Wenn ich meine PC Applikationen anschaue kommen diese nicht ohne OOP aus und das ist ja auch da so sinnvoll.


bike
 
...
Wie IBFS geschrieben hat, steht der Aufwand für OOP Entwicklung in keinem Verhältnis zum Ergebnis.
...

Eine "schöne" Verallgemeinerung. Alle Projekte sind ja auch gleich ;o)

Die Firma BR hat im Januar im SPS-Magazin das etwas besser dargestellt:

73494.jpg

Quelle: sps-magazin.de
Hier der Link zum Artikel: http://www.sps-magazin.de/?inc=artikel/article_show&nr=59182
 
Zurück
Oben