Programmiersprachen

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wo liegt die Komplexitätsgrenze?
Was ist das? Bisher ist mir dies noch nie begegnet.
Und es ist klar, dass man als Hersteller von irgendetwas versucht einen Nutzen zu generieren.
Machen wir als Hersteller auch, da werden auch DInge angeboten die nicht immer sinnvoll sind.


bike

 

[IBFS]

Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen.
Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.

Daher ist es für mich ein Märchen, dass es KOMPLEXE SPS-Programme geben könnte.
Es gibt nur viel - hoffentlich gut strukturierten Code.

Oft komm vermeintliche Komplexität auch daher, das der Konstrukteur
was ganz besonders tolles konstruieren wollte anstatt möglichst einfach
zu konstruieren.

Beispiel:
Der Konstrukteur baut eine Kollision- bzw. Störkontur ein, die durch
frühzeitiges Verrücken einer Teilstation um wenige Zentimeter hätte
vermieden werden können.
Ergebnis ist eine viel aufwändigere Grundstellungsfahrt.


Das es bei PC-Applikationen komplexe Programme gibt, da stimme ich zu,
wobei auch hier in der Modularisierung der Schlüssel zur Einfachheit liegt.

Frank

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Komplexität bezieht sich auf die Aufgabe nicht auf den Code.

Modularisierung ist der Vorfahre bzw. einbestandteil der Objektorientierten Programmierung.

 

[drfunfrock]

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.


bike

Da sind wir uneinig. Für mich sind Stationen potentielle Objekte im Code und hier lohnt es richtig.
Ich hab vor Jahren mal damit gearbeitet:

http://www.youtube.com/watch?v=1ZS0J8UQSSg

Jede Station ist hier ein Objekt, dass beim Halten des Wagens

- sicherstellen muss, dass der Wagen auch in Position ist (Die Technik dieser Wagen ist suboptimal)
- die Wagen-ID auslesen muss um
- dann den vom Produkt, dass sich auf dem Wagen befindet, abhängigen Produktionsprozess zu starten. (nein, das war nicht fest)

Ohne Vererbung ist das unschön, aber mit FBs konventionell per Pseudo-OOP machbar. Mit OOP wäre das bei 40 Stationen noch schöner geworden. Ich habe jede Station für sich testen können oder auch nur den Wagensteuercode testen können. Gerade an solchen Anlagen lohnt es.
Ich habe die Kommunikation zwischen Wagenmanagement und dem einzelnen Prozess per Event-System gelöst. Ein Event hat z.B. einen Prozess gestartet und per Event habe ich den Status zurückgemeldet. Das wäre alles schöner mit OOP geworden. Dagegen habe ich die einzelnen Prozesse als ganz gewöhnliche Schrittketten implementiert. Ich habe während der 4 Jahre, die diese Anlage gelaufen hat, insgesamt ca. 10 grössere Änderungen eingebaut, um neuen Anforderungen zu entsprechen. Und keine von denen hat die Produktion mehr als 2h gestoppt. Das hat übrigens nur 1 TwinCat Installation gesteuert.

OOP richtig angewendet, macht das Leben leichter. Ich würde es aber nicht vollständig durchziehen, wenn es nicht lohnt. Das war übrigens mein erstes Projekt Mein Hintergrund liegt eigentlich in der Microelektronik mit VHDL und so.

 

[Werner29]

Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen.
Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.

Das ist schon richtig, aber unterscheidet sich nicht von der PC-Programmierung. Das Versprechen der OOP ist ja gerade, dieses Zerhacken zu unterstützen.
Schau dir doch mal mein Beispiel an und sag uns, wie man das mit herkömmlichen Mitteln besser macht.
Ich habe noch ein Beispiel für dich:
http://www.3s-software.com/index.shtml?de_OOP
Ist das schlechter Stil? Wo liegen die Nachteile in der Vorgehensweise?

Bernhard

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wo liegen die Nachteile in der Vorgehensweise?

Geht es um Nachteile?
Sollte nicht die Fragestellung sein:
Vorteile bei dieser Art der Programmierung?


bike

 

[Larry Laffer]

... ist interessant das hier mitzulesen ...

Die Vor- und Nachteile einer Programmierart liegen IMMER im Auge des Betrachters. Damit meine ich jetzt auch nichts Spezielles. Ich habe mich z.B. erst letztens noch mit jemanden unterhalten, der mit sein schlecht strukturiertes und unübersichtliches FUP-Programm als das Non-plus-Ultra "verkaufen" wollte. Auch da war es mir nicht möglich, den Aderen zu überzeugen - es ging nur mit zwingen ...

Im Falle des Themas hier würde ich sagen, dass man OOP wenn man es einmal wirklich und richtig verstanden hat nicht mehr missen möchte. Leider kann ich es für mich nur in meiner kleinen Visual-Studio-Welt praktizieren. In der Step7-Welt gibt es das ja LEIDER gar nicht und auch nicht die Möglichkeit, es zu nutzen - vielleicht irgendwann in ferner Zukunft mal, da auch die sich sicherlich dahin entwickeln werden. Also versuche ich für wiederkehrende Funktions-Strukturen einen Pseudo-OOP-FB zu bauen, der seine Methoden über die Schnittstelle bereitstellt.

Bezüglich dieser Vorgehensweise kann ich die von Zotos hier eingestellte Grafik nur bestätigen. Hat man erstmal seine Basis zusammen so kann man für eine Anlage (die ja bei uns in ihrer Grundstruktur auch immer ähnlich ist - trotz Sonder-Maschine) sehr schnell ein funktionierendes Programm zusammen. Da brauche ich schon heute für die Visu doppelt so viel Zeit, wie für das Programm - und so schrecklich viel können meine Visu's nun auch wieder nicht.

Wie auch immer ... ich würde die OOP-Idee absolut unterstützen und sehe sie auch nicht als "neumodischen Kram" oder wie immer man sagen möchte.
Es hat aber sicherlich jeder so seinen Stil, den er vielleicht auch mit einem gewissen Recht verteidigt - ich bin bei meiner Masche auch zu wenig Zugeständnissen bereit ...

Gruß
Larry

 

[Dummy]

Das ist schon richtig, aber unterscheidet sich nicht von der PC-Programmierung. Das Versprechen der OOP ist ja gerade, dieses Zerhacken zu unterstützen.
Schau dir doch mal mein Beispiel an und sag uns, wie man das mit herkömmlichen Mitteln besser macht.
Ich habe noch ein Beispiel für dich:
http://www.3s-software.com/index.shtml?de_OOP
Ist das schlechter Stil? Wo liegen die Nachteile in der Vorgehensweise?

Bernhard

Hallo Bernhard,

da sich niemand mit den Nachteilen auseinandersetzen möchte, werden ich mal versuchen einige Vorteile aufzuzeigen:

1.)Flexibilität
Eine Änderung des Raumtypes ist nur durch eine Deklerations-Änderung möglich. Es muss kein Quellcode verändert werden.
Dies sollte jeder Instandhalter/Hausmeister schaffen.

2.)Erweiterbarkeit
Bei einem Anbau von mehreren Räumen ist es ebenfalls nur durch eine Neu-Deklaration der neuen Räume möglich.

Sollte ein neuer Raumtyp benötigt werden, kann ebenfalls durch Vererbung auf bestehenden Code zurück gegriffen werden. Es müssen nur die zusätzlichen Funktionen implementiert werden.

Gesamteindruck:
Die Syntax ist die Gleiche wie in ST. Es wurden nur zusätzliche Funktionen der OOP hinzugefügt. Jeder der schon mit ST-Programmiert hat, kann sich darin schnell zu recht finden.

Gruß

dummy

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

1.)Flexibilität
Eine Änderung des Raumtypes ist nur durch eine Deklerations-Änderung möglich. Es muss kein Quellcode verändert werden.
Dies sollte jeder Instandhalter/Hausmeister schaffen.

Kann jeder Standard FB einer PLC auch.
Über ein OP die Eingangsparameter ändern und weiter geht es.

2.)Erweiterbarkeit
Bei einem Anbau von mehreren Räumen ist es ebenfalls nur durch eine Neu-Deklaration der neuen Räume möglich.

Sollte ein neuer Raumtyp benötigt werden, kann ebenfalls durch Vererbung auf bestehenden Code zurück gegriffen werden. Es müssen nur die zusätzlichen Funktionen implementiert werden.

Einen neuen FB mit den richtigen Parameter einfügen und es funktioniert ebenso.

Gesamteindruck:
Die Syntax ist die Gleiche wie in ST. Es wurden nur zusätzliche Funktionen der OOP hinzugefügt. Jeder der schon mit ST-Programmiert hat, kann sich darin schnell zu recht finden.

Gruß

dummy

Leider sehe ich den Vorteil bei PLC mit OOP immer noch nicht.

 

[Dummy]

Kann jeder Standard FB einer PLC auch.
Über ein OP die Eingangsparameter ändern und weiter geht es.

Ja, das kann man so machen.
Aber:

Jedes SPS-Programm besteht im Prinzip aus einer Sammlung von ganz simplen Sachen.
Wenn ein SPS-Programm zu komplex wird, hat man die Teilabläufe
oder Teilprobleme nicht lange genug in appetitliche SPS-Happen zerhackt.
Frank

Wiederspricht sich dies nicht? Wenn ich alle Varianten in einem FB programmiere sind doch die Teilaufgaben nicht mehr in appetitlichen Happen.
Es geht aber auch X-Fbs mit nahezu identischen Code zu pflegen.
Finde ich persönlich gar nicht gut!

Einen neuen FB mit den richtigen Parameter einfügen und es funktioniert ebenso.

Auch das geht, wenn man zusätzlich auch noch den Code ändern möchte.

Gruß

dummy

 

[bike]

Auch das geht, wenn man zusätzlich auch noch den Code ändern möchte.

Gruß

dummy

Ein Objekt mit zusätzlichen Eigenschaften, muss ich doch auch ändern, oder versteh ich jetzt etwas wieder nicht?
Ob ich einen FB habe mit den Standardfunktionen habe und den dann ggF ableite(kopiere) oder zusätzlich aufrufe für neue und zusätzliche Funktionen, dann funktioniert dies.

Ich gehe absolut konform, dass OOP eine Berechtigung hat.
Doch in der PLC noch? nicht.
Vielleicht sieht man es anders wenn man nur Anlagen programmiert.


bike

 

[Dummy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein Objekt mit zusätzlichen Eigenschaften, muss ich doch auch ändern, oder versteh ich jetzt etwas wieder nicht?
Ob ich einen FB habe mit den Standardfunktionen habe und den dann ggF ableite(kopiere) oder zusätzlich aufrufe für neue und zusätzliche Funktionen, dann funktioniert dies.

bike

Gut, wenn Du ein neuen bisher unbekannten Typen implemtieren willst, musst Du auch bie OOP den Code ändern. Hast Du das Beispiel überhaupt angesehen.

Allerding hat Ableiten so gut wie nichts mit kopieren zu tun!

Was mich bei Dir nervt, ist dass Du hier immer solche Dinger raus haust:

Ich gehe absolut konform, dass OOP eine Berechtigung hat.
Doch in der PLC noch? nicht.
Vielleicht sieht man es anders wenn man nur Anlagen programmiert.

bike

Warum musst Du für die ganze SPS-Fachwelt sprechen.
Es gibt eben welche, die sehen die Vorteile.
Also sprich besser für Dich und nicht für alle.
Außerdem warten hier immer noch viele darauf, dass Du uns mal die Nachteile erklärst.

Schönen Abend noch.

dummy

 

[bike]

Also sprich besser für Dich und nicht für alle.
Außerdem warten hier immer noch viele darauf, dass Du uns mal die Nachteile erklärst.

Schönen Abend noch.

dummy

Falscher Ansatz, würde ich sagen.
Es geht drum etwas zu verbessern, nicht das neue rote Rad als neu zu verkaufen, weil der Vorgänger schwarz war.

Ich programmiere in einer Firma mit zur Zeit 30 Programmieren in einem Großraum.
Wir programmieren nicht nur Step7, sondern Fanuc und Bosch und Heidenhain und Codesys und ...
Denkst du wir reden nicht und wenn so viele Entwickler zusammen sind, kommen viele Meinungen und Erfahrungen zusammen.

Ich versuche die Vorteile zu verstehen und wie unsere Kunden davon profitieren können.
Mir hat ein Autohersteller in Paris ins Gesicht gesagt:
"Eure Entwicklung ist für den Hersteller gut, aber nicht für den Kunden."
Das war keine OOP, sondern AWL und SCL.

Daher ist in unserem Focus der Kunde und nicht mit oder ohne OOP oder sonstigem.

Dir auch einen entspannten Abend


bike

 

[Dummy]

Falscher Ansatz, würde ich sagen.
Es geht drum etwas zu verbessern, nicht das neue rote Rad als neu zu verkaufen, weil der Vorgänger schwarz war.

Ich programmiere in einer Firma mit zur Zeit 30 Programmieren in einem Großraum.
Wir programmieren nicht nur Step7, sondern Fanuc und Bosch und Heidenhain und Codesys und ...
Denkst du wir reden nicht und wenn so viele Entwickler zusammen sind, kommen viele Meinungen und Erfahrungen zusammen.

Ich versuche die Vorteile zu verstehen und wie unsere Kunden davon profitieren können.
Mir hat ein Autohersteller in Paris ins Gesicht gesagt:
"Eure Entwicklung ist für den Hersteller gut, aber nicht für den Kunden."
Das war keine OOP, sondern AWL und SCL.

Daher ist in unserem Focus der Kunde und nicht mit oder ohne OOP oder sonstigem.

Dir auch einen entspannten Abend


bike

Die Menschheit hat auch mal geglaubt im Mittelpunt des Universum zu stehen. Da war die Erde auch noch eine Scheibe.
Heute reicht dafür schon ein Großraumbüro...........

Nur ein Beispiel warum wir aus anderen Welten kommen:

Unser Kunde bekommt den Quellcode nicht zu gesicht.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Menschheit hat auch mal geglaubt im Mittelpunt des Universum zu stehen. Da war die Erde auch noch eine Scheibe.
Heute reicht dafür schon ein Großraumbüro...........

Deine Weisheiten sind echt Klasse.
Den "Mittelpunt" sind wir doch immer noch, oder?

Nur ein Beispiel warum wir aus anderen Welten kommen:

Unser Kunde bekommt den Quellcode nicht zu gesicht.

Wir müssen unseren Code nicht verstecken *ROFL*

So als kleiner Denkansatz


bike


P.S: bei uns in Bayern gibt es den Begriff des Klugscheißers.

 

[IBFS]

@bike
@Dummy

Ich denke

1. ihr redet momentan völlig aneinander vorbei
2. wir müssen hier nicht mit Adam und Eva oder Gallileo anfangen
3. das Teilprojekte oder Aufgaben eben noch lange keine Objekte sind
4. die Vererbung ist im "harten" Vorort-SPS-Alltag ohne Netzzugang zum firmeninteren Code-Source -Safe nur in sehr wenigen Fällen praktikabel
5. solange der Eine von LabView und C# und der Andere von CodeSys und STEP7 redet bringt ein Diskussion recht wenig, weil die Daten- ,Wissens- und Erfahrungsbasis völlig verschieden sind.
6. die Gebäudetechnik als Maßstab herzunehmen ( Anbau von mehreren Räumen ) ist unglücklich, weil das mit KNX, LON etc. gemacht wird und da wird eher parametriert als programmiert.
7. geht mal zusammen ein Bier trinken, dass ist effektiver

Grüße

Frank

 

[bike]

7. geht mal zusammen ein Bier trinken, dass ist effektiver

Das ist der beste Beitrag zu diesem Thema, denn da gibt es keinen Reibpunkt.

Ich hätte gern ein beck's gold, nicht zu kalt bitte.

bike