Java als SPS Programmiersprache

[Heinz]

@zotos
Siemens geht den Weg in Richtung objektorientierte Programmierung.
Durch die Zugriffe auf die Daten der Multiinstanzen und durch die Multiinstanzen überhaupt entwickelt sich langsam eine objektorientierter Ansatz. Weiterhin wurde der Ansatz durch das CFC Zusatzpaket weiterentwickelt. Es ist natürlich so, dass vieles noch fehlt insbesondere die Ereignisse und Methoden.

Andere Programmiersprachen wie Steeble Chase sind dort schon weiter.

Ansonsten denke ich auch, dass die "alten" Sprachen wie AWL aussterben werden

Gruß Heinz

[Ralle]

Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten. Sicher, ein Schlumi-Programmierer kann jede gute Programmiersprache versauen.
In der normalen Maschinensteuerung ist doch die Problemstellung(hier kraß vereifacht) folgende:

500 Eingänge, 200 Ausgänge --> Automatischer Ablauf in Abhängigkeit der Eingänge und von ein paar internen Vorgaben (auch nichts anderes als Eingänge).

Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind. Übersicht oder gar Einblick in die Abläufe geht da völlig verloren.

Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten. Die Gefahr dabei, soetwas könnte gute Programmierer "fast!!!!!" überflüssig machen (Script-Kiddis reichen )

rk

[Ralf]

Nunja, vereinfacht gesagt, Java:
Wenn der Maus - Listener sich aufgehängt hat schließe ich das Programm und mach es wieder auf.
Wenn der Hydraulikstempel listener sich in der Automatisierung aufgehängt hat mach ich ein Dummes Gesicht und geh laufen ...

Gruß

Ralf

[Zottel]

Die Multiinstanzen gehen insofern Richtuung OO, als sie Daten und Methoden zu deren Bearbeitung zusammenfassen.
Was nicht geht, ist Verebung und überladen:
"Pumpe C läuft wie Pumpe A und B, aber mit anderer Hyterese"
Hier bleibt nur:
1. Dem FB einen extra Parameter zu geben, der bei A und B konstant ist.
2. Den FB kopieren, umbenennen und die Hysterese ändern.

1. führt auf Dauer zu Bibliotheks-FBs, die im konkreten Anwendungsfall mehr überflüssige als benutzte Parameter haben.
2. führt zu einem Haufen spezialisierter Bausteine.

OO macht das nicht automatisch besser: Entweder sind analog zu 1 schon Methoden für alles und jedes drin oder man leitet ständig neue Objekte ab.
Mehrfachverebung sollte es richten, aber schaut euch mal C++ mit Mehrfachvererbung an!

JAVAs Ansatz, verschiedenens Verhalten an Klassen zu deligieren finde ich da überschaubarer. Es führt aber dazu, daß man im Nachhinein bestehende Objekte zerlegt und die Funktionalität auslagert. Ich habe noch keine gute Methode kennengelernt, um beim ersten Entwurf eines Objekts gleich alles "richtig" zu machen.

Ich denke eher, daß Beschreibungssprachen interessant werden. Man gibt ein Problem vor (Fahrwerk mit 5 Haltstellen etc.) und eine Software generiert daraus den Code. Allerdings ist auch hier Vorsicht geboten, sonst kann das Ergebnis keiner mehr bewerten, geschweige denn warten.

Die Wartung hätte natürlich auf der Ebene der Beschreibung zu erfolgen. Man nimmt ja auch nicht den C-Compiler her, um nachher das Ergebnis auf Assemblerebene zu ändern. Aber wie es Assembler-Unterprogramme in Hochsprachenprogrammen gibt (oder native Code, der von JAVA aufgerufen wird), wird es wieder AWL geben, um Probleme zu lösen, die man in der Beschreibungssprache nicht ausdrücken kann oder bei denen es auf maximale Effizienz ankommt.
[/quote]

[Ralf]

Guten... diesmal abend

Ich ergänze hier meinen Beitrag von heute morgen. Ich habe dort einiges Allgemeines erzählt, ohne meine ‚gemeinte’ Kernaussage auch nur ansatzweise zum Ausdruck zu bringen.

(kann Markus das ganze Topic nicht in den Stammtisch verschieben, das wäre wahrscheinlich eher was für ´ne Diskussion mit Wein, Bier, Zigaretten und ‚nem Dicken Kopf am nächsten Morgen)

Jemand der meint Objektorientiertheit sei die allseligmachende Eigenschaft einer guten Programmiersprache, befindet sich auf dem Holzweg. Objektorientiertheit ist gut, wenn man Probleme zu lösen hat, die
- gut zu modellieren sind
- häufig in abgewandelter Form zu finden sind
Die meisten derjenigen, die SPSen programmieren arbeiten im Anlagenbau. Sie finden keine geeigneten Modelle für die auftretenden Probleme (es sei denn man hat da eine Reglung, da ist ja PID ein geeignetes Modell. Sie haben es nicht mit Problemen zu tun, die häufig in abgewandelter Form bestehen. Entweder gibt es eine Funktion zigmal auf gleiche Art gelöst werden muß, oder Funktionen sind so unterschiedlich, daß sie mit verschiedenen (Unter)Programmen gelöst werden müssen.

Ähnlich geht es den IT – Leuten, aber mit geänderten Vorzeichen. Der große Anteil der IT – Anwendungen, die der ‚Normaluser’ so sieht, beruht auf Modellen / die Benutzerschnittstelle ist ja nur ein einziges Modell. Auch sind in der IT vielfach Probleme zu lösen, die auf dem selben Rechner in leicht abgewandelter Form an vielen Stellen zu lösen sind (z.B. Rufe den Datei öffnen Dialog auf, und öffne die gewählte Datei). Hier macht Objektorientiertheit Sinn.

Wenn die IT aber mit Problemen konfrontiert ist, die denen des Anlagenbaus vergleichbar sind (in meinem vorherigen ‚Guten morgen’ - Beitrag ‚Profibereich’), geht sie einen anderen Weg. Im Profibereich wird viel Geld für Rechenleistung ausgegeben. Probleme die singulär auftreten werden auch singulär d.h. nicht Performance lastig und Instabilitäten fördernd gelöst. Wenn eine Bank sich einen Rechner leistet, der die Bankgeschäfte abwickelt, ist nach wie vor COBOL (in meinem anderen Beitrag hatte ich ALGOL geschrieben / Ist aber COBOL) Maß aller Dinge, große Forschungsabteilungen die Großrechner benutzen, geben diesen ihre Aufgabenstellungen (‚simulier mir mal das Schwingungsverhalten einer Nockenwelle’) nach wie vor in FORTRAN. Würde hier der dringende Wunsch nach Objektorientiertheit bestehen, hätte man längst umgeschwenkt. Dies tut man nicht, da man keine Performancediebe oder noch schlimmer Rechnerstabilitätsgefährder gebrauchen kann.

Die Lastenhefte dieser Aufgabenstellungen entsprechen am ehesten denen, die auch wir aus der Anlagenautomation kennen: Ganz wichtig ist, das Programm läuft stabil.

Gruß

Ralf

[drfunfrock]

Möglicheweise dann, wenn er fremde Programme nachvollziehen muß. Das ist aber in einer OO-Sprache nicht eo ipso (automatisch) besser

Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht. Ich bin selbst mit Einplatinen-Z80-Platinen gross geworden und habe nicht die mindesten Skrupel gehabt, eine höhere Sprache zu wählen.

AWL und ähnliche Sprachen unterstützen die Beschreibung der Problemlösung nicht oder anders, derartige Programmiersprachen ermöglichen eine Lösung, dass ist aber schon alles. ST ist das schon ein ganzes Stück weiter. Mit einer objektorientierten Sprache ist das i.d.R. wesentlich einfacher. Aus einem Programmtext sollte i.d.R. das Konzept herauszuslesen sein.

Wie mißt du den Erfolg? Ich messe ihn mal daran, daß das Steuerprogram richtig auf Eingaben des Bedienes und Ereignisse der äußeren Welt (Prozeß) reagiert.

Das allein wäre nun doch ein bischen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein. Ich wäre nie zur Programmierung einer SPS gekommen, wenn es nicht organisatorisches Chaos gegeben hätte, welches zu einem Code führte, der funktionierte, aber weder veränderbar noch selbstdokumentierend war.

Mein Erfolg war der, das Kollegen sofort mir bestätigten, dass mein Experiment nicht nur funktionierte, sondern auch für andere lesbar war.

Zwischen der Wirklichkeit und dem Programm steht nun die Modellierung als Objekt. Wenn dein Programm nicht funktioniert, mußt du das Objektmodells infrage stellen.

So arbeite ich nicht. Erst wird ein Konzept aufgestellt, dass die wichtigsten Kriterien darstellt und zum Entwurfkriterium eines Algorithmusses macht. Hält der Algorithmus den Kriterien stand, beginne ich zu Kodieren und nicht nach dem Trial- und Error-Verfahren. Das hat den Vorteil, dass Irrwege nicht so schnell beschritten werden und Kollegen eine Chance haben sich zu beteiligen.

Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konderativ sind, obwohl das oftmals nur eine Scheinsicherheit ist.

[drfunfrock]

Ich versuche mal etwas kurz zur Auswahl von Programmiersprachen einzuwerfen:

Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein. Bsp: Die Programmierung mit Assembler kann ein Problem lösen, dass dann aber selten gut beschrieben ist. Daher sind Diagramme mit LD durchaus i.O. wenn sie die Prolemlösung angemessen darstellen.

Eine Programmiersprache sollte auch die sichere Programmierung unterstützen und nicht nur ermöglichen. Bsp. In ST ist es möglich enumerated Datentypen zu Integern durch eine Zuweisung zu konvertieren, um solche Werte auch in Case-Of Anweisungen benutzen zu können. Grundsätzlich sollten implizite Casts nicht möglich sein. Das Konzept von Pointern macht die Systeme auch nicht sehr viel zuverlässiger.

Eine Programmiersprache (und ihre Umgebung) sollte ein gute Codeorganisation unterstützen.

[drfunfrock]

Also, ich glaube nicht, daß die Objektorientierung soweit gehen wird wie unter Win, man sehe sich nur mal die S7-Software von Siemens an, tausende DLL-, Exe-, und Sonstwas-Dateien, immer wieder mal Abschmierer meist einzelner Komponenten.

Ich selbst habe Step7 und die Software von Beckhoff in den Fingern gehabt und kann nur sagen, das Siemens Step7 eine Zumutung ist. Ich weiss noch nicht wie stabil Beckhoff TwinCat wirklich ist, aber zumind. ist die Programmierungebung sehr sauber und gut programmiert. Die Installation ist innerhalb von 3 Minuten abgeschlossen. Keine langwierige Registrierung diverser Komponenten....

Wenn jetzt alle Eingänge z.Bsp. Ereignisse auslösen sollen, auf die man dann reagieren kann, ist allein dafür der interne Aufwand des BS enorm groß. Außerdem muß dann der gesamte deterministische Mechanismus anders gestaltet sein, schon bei SPS-Software mit mehreren parallelen Tasks passiert genug, weil Signale zu früh oder zu spät sind.

Ich denke, wenn man nicht unbedingt alle Features von C++ implementiert, ist auch das zu schaffen. Zudem sind heutige Prozessoren doch etwas leitungsfähiger. Zudem benötigt man sicherlich leicht abgewandelte Konzepte. Events lassen sich durchaus über Hardware erzeugen. Eine Beschreibung einer Anlage über Objekte ist nicht in jedem Fall sinnvoll, aber sicherlich kann es einen grossen Gewinn bei verteilten Anlagen bringen.

[Anonymous]

Aber sonst habt ihr wohl keine Probleme? Sinnlose Diskussionen! Automatisierungstechnik ist kein Feld für Hobbyprogrammierer. Macht lieber was mit "Hello World"

Bernd

[Ralf]

Ich kann in Assembler , AWL etc. sicherlich alles machen, nur sinnvoll ist es nicht.

Ein Postulat!
Gott sei dank hat Drfunrock keinen Brief an meinen Chef geschrieben mit der Betreffzeile
Wofür kriegt der eigentlich Geld, bei dem Sinnlosen Kram, den der tut
dann wär's um mich geschehen.

Das allein wäre nun doch ein bißchen wenig. Ein Programm sollte sich im weitesten Sinne selbst dokumentieren und - wenn konzeptionell möglich - einfach erweiterbar sein

Schon wieder ein Postulat,
Meiner Meinung zufolge muß ein Programm in erster Linie den Aufgaben entsprechen, die vom Auftraggeber respektive der Anlage an das Programm gestellt werden, erst sekundär können Eigenschaften wie Verständlichkeit und Erweiterungsfähigkeit gestellt werden. Versuch mal einer einem Auftraggeber zu erklären, das die Programmierung zwar nicht ganz den erheblichen Performanceanforderungen entspricht, aber dafür jederzeit erweiterbar... spätestens hier ist man tot.

Deine Einwürfe zu Java sind richtig und es wäre zu überlegen, ob hier nicht mehr getan werden könnte. Schade das die Automatisierer so konserativ sind, obwohl das oftmals nur eine Scheinsicherheit ist.

Ich versteh den Zusammenhang nicht, ich bin konservativ, aber das ist nur eine Scheinsicherheit Kratzamkopf wird schon richtig sein.

Eine Programmiersprache sollte die Beschreibung der Problemlösung unterstützen und nicht nur Problemlösung sein.

Hier ist noch mal die (nicht nur in der Automatisierung) wichtige Prioritätenfrage zu klären.

Grundsätzlich sollten implizite Casts nicht möglich sein.

Woher nimmst Du das? Wenn es Zweckdienlich ist wandle ich Dir jede REAL in INT