Java als SPS Programmiersprache

[Anonymous]

Na wenn ihr sonst keine Probleme habt dann is ja gut. Wer genug zu tun hat der kommt erst gar nich auf die Idee sich über sowas Gedanken zu machen. IEC hin und her. Ne einheitliche Software mag Vorteile haben, aber reizt die jeweilige Steuerung nicht aus. Und wer denkt, dass Siemens alles offenlegt der hat auch noch die Illusion vom Weihnachtsmann. Nicht irgendwelche Vorschriften zählen, sondern wer das Monopol hat. Es gibt paar grosse Siemens, AB usw. Dann gibts paar bedeutungslose Trittbrettfahrer wie V..A und H.......z die wahrscheinlich mal ne Putzfrau von Siemens bestochen haben paar Unterlagen zu beschaffen. Guckt doch Microsoft an. Denkt ihr die lassen sich Vorschriften machen wie die Programme auszusehen haben? darüber machen sich nun wirklich nur gefrustete Informatiker ne Waffel, n SPS-Anwender garantiert nicht. Aber brütet ruhig weiter. Is besser als wenn ihr Würmer schreibt. Ihr ändert daran nichts. Und wenn jemand denkt dass er was allgemeingültiges schreiben kann was für alle SPSen gilt geht erbärmlich baden. Welcher Hersteller gibt schon mehr Infos als er muss?

In diesem Sinne...

[Zottel]

Na wenn ihr sonst keine Probleme habt dann is ja gut.
Wer genug zu tun hat der kommt erst gar nich auf die Idee sich über sowas Gedanken zu machen.

Genug zu tun, mit den Editoren zu kämpfen, Trivialitäten von Hand in AWL zu kodieren,AB nach Siemens und zurück zu portieren?

IEC hin und her. Ne einheitliche Software mag Vorteile haben, aber reizt die jeweilige Steuerung nicht aus.

Das ist bei Prozessoren und C (der nicht besten aber auf den meiste Plattformen verbreiteten Sprache) ähnlich, daher hat mancher C-Compiler Erweiterungen, sei es für MMX,3D-now usw. im PC-Bereich oder Keil C51 für die Bitbefehle des 8051.

Und wer denkt, dass Siemens alles offenlegt der hat auch noch die Illusion vom Weihnachtsmann. Nicht irgendwelche Vorschriften zählen, sondern wer das Monopol hat.

Das weiss ich besser als viele andere.
http://<br /> <a href="http://libno....net</a><br />
Ist eine Bibliothek zur Kommunikation mit Siemens-Steuerungen. War Arbeit, das aus der mitprotokollierten Kommunikation nachzubilden.

Es gibt paar grosse Siemens, AB usw. Dann gibts paar bedeutungslose Trittbrettfahrer wie V..A und H.......z die wahrscheinlich mal ne Putzfrau von Siemens bestochen haben paar Unterlagen zu beschaffen. Guckt doch Microsoft an. Denkt ihr die lassen sich Vorschriften machen wie die Programme auszusehen haben? darüber machen sich nun wirklich nur gefrustete Informatiker ne Waffel, n SPS-Anwender garantiert nicht.

Sowenig wie viele Winzigweich-Anwender
[quote]
[/url]

[zotos]

http://www.heise.de/newsticker/meldung/48795

[Zottel]

Interessant, nur braucht es halt einen recht grossen Rechner um mit 22ms Reaktionszeit eine Aufgabe zu erledigen, die ein 8051 mit <1k Assemblercode auch bewäligt.

[drfunfrock]

Hallo,

ich möchte hier die Diskussion über die SPS / PLC Programmiersprachen anstossen. Mich würde intressieren wie ihr die Programmiersprachen im vergleich seht.

Ich finde JAVA derzeit nicht passend, weil diese Sprache von einem Branchenfremden kommt und in ihrem Kern nicht offen ist. Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht. Da werden implizite Automaten mit über 20 Zuständen mit vielen Merkern programmiert und das ganze noch als Leiterdiagramm. Selbstverständlich nicht aus einem Guss, sondern historisch entwickelt, so dass selbst dem langjährigen Kollegen die Puste ausgeht.

Daraufhin began ich ein Experiment mit der Sprache ST. Ich erstellte wie in der VHDL-Programmierung einen einfachen Moore-Automaten (siehe http://tinyurl.com/68bxv) und erzielte sofort einen Erfolg. Es hat sich herausgestellt, dass ST einfachste Objektorientierung möglich macht, aber nicht sonderlich gut unterstützt. Wenn man ST noch eine einfache Objektorientierung verpassen würde, könnte man sehr zufrieden sein. Uns hat jedenfalls die Möglichkeit der einfachsten Objektorientierung sehr geholfen. Wir haben dabei den Code, der innerhalb von 3 Jahren "gewachsen" ist, innerhalb von 3 Wochen ersetzt. Ich hätte mir aber gewünscht, dass ganze sauberer zu programmieren, so dass ein Teil der Doku unnötig geworden wäre.

Gerade wenn viele, auch selbstständig einsetzbare Einheiten , zusammenarbeiten sollen, ist Objektorientierung ein bequemer und fast selbstdokumentierender Weg. Es geht als nicht so sehr um den Namen der Programmiersprache, sondern um deren Eigenschaften und da meine ich, sollte über Objektorientierung nachgedacht werden. AWL ist IMHO inakzeptabel, weil diese Sprache in keiner Weise Problem beschreibend ist.

Ach ja: Performance hat es nicht gekostet, aber jede Menge eingesparten Code.

Doc Funfrock

[Zottel]

Ich finde JAVA derzeit nicht passend, weil diese Sprache von einem Branchenfremden kommt

Das kann nicht der Punkt sein. Typische Betriebsblinde würden wach werden müssen, wenn ein Auswärtiger was besseres bringt.

...und in ihrem Kern nicht offen ist.

Was ist der Kern? Die Sprachdefinition? Da ist JAVA meines Wissens offen. Für AWL x-beliebiger Hersteller existieren im allgemeinen nicht einmal formale Definitionen.

Ich beschäftige mich erst seit 3 Wochen mit SPS-Technik und musste feststellen, dass es in der Automatisierungstechnik manchmal (nicht immer!) noch wie zu Anfang der 80'-Jahre zugeht. Da werden implizite Automaten mit über 20 Zuständen mit vielen Merkern programmiert und das ganze noch als Leiterdiagramm. Selbstverständlich nicht aus einem Guss, sondern historisch entwickelt, so dass selbst dem langjährigen Kollegen die Puste ausgeht.

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

Daraufhin began ich ein Experiment mit der Sprache ST. Ich erstellte wie in der VHDL-Programmierung einen einfachen Moore-Automaten (siehe http://tinyurl.com/68bxv) und erzielte sofort einen Erfolg.

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.
Ein AWL- oder Assembler-Programm (oder beliebig programmiertes Programm zur Steuerung von Maschinen) ist ok, wenn es das tut. In der OO teilst du dies in zwei Schritte auf:
Dein Programm bildet dein Objektmodell richtig ab und du nennst dein Programm sei korrekt.
Zwischen der Wirklichkeit und dem Programm steht nun die Modellierung als Objekt. Wenn dein Programm nicht funktioniert, mußt du das Objektmodells infrage stellen.
In einem Zyklus von Testen und Korrigieren hast du jetzt auch zwei Schritte.

[Ralf]

Guten morgen,

ich kann nicht umhin davor zu warnen jedem Trend hinterherzulaufen. Wenn man versucht Erkenntnisse aus der schnellebige IT Welt auf die doch eher konstante der Automatisierungstechnik zu beziehen - wir sind ja schließlich in einem Automatisierungstechnikforum - sollte man sich (dies mag jetzt bissig klingen) nicht auf nur eine Teilsicht beschränken.
Die IT hat eine rasante Entwicklung hinter sich. Zu der Zeit als die ersten PCs auf den Markt gebracht wurden, gab es ja schon leistungsfähige Kleinrechner; Digital Equipment (Hi PLC_T) hat zu dieser Zeit als Reaktion auf den IBM PC mal schnell deren ‚Clusterrechner’ PDP 11 mit ´nem bißchen Userinterface zusammengedengelt und ihn als RAINBOW oder PROFESSIONAL verkauft, die Dinger waren um einiges Leistungsfähiger als der PC, aber auch für das private rumspielen unerschwinglich.
Im IT Massenmarkt wurden folglich der PC als Leistungsschwaches Gerät angeboten, der Sektor, der Rechenleistung benötigte, bediente sich mit professionellen Geräten (selbstverständlich für teuer Geld).
Die professionellen Geräte – auch der Nachfolger der PDP (die gute alte VAX) wurden – zumindest wenn es um technische Problemstellungen in FORTRAN programmiert, bei eher Daten- als Rechenintensiven Anwendungen war glaube ich ALGOL on the top. Betriebssysteme die im Profibereich zum Einsatz kamen, waren UNIX und für die DEC Rechner VMS.
Im ‚Amateurbereich’ - der ja nun erst mal zum Profibereich werden mußte – wurde das getan was jeder Amateur macht, es wurde mächtig gepfuscht. Ein unbedeutender EDV – Händler aus Seattle, dessen größter verdienst wohl immer noch die Erfindung der ‚unhandled exception’ ist, kaufte das Betriebssystem DOS und verschacherte teure Lizenzen (das war nicht ungeschickt / ich hätte auch gerne ganz viel Geld). Die Anforderungen der Kunden verschoben sich – EDV, jetzt ja für jeden erschwinglich, mußte auch für jeden bedienbar werden – zu ebendieser Zeit kam meine damalige Freundin mit ´nem Mac nach Hause. Microsoft sah Handlungsbedarf, es wurde auf das antiquierte DOS – Gerüst ein schönes buntes Windows Haus aufgesetzt, diesem Konstruktionsprinzip blieb Microsoft bis Win ME treu; jeder kann sich bildlich vorstellen, daß ein Haus maximal soviel taugt wie sein Fundament, das Haus war aber
A – Ein virtuelles Haus, bei dem ein Einsturz nicht wehtut
B – Ohnehin nur das Haus für die Amateure, die Profis blieben ja beim bewährten
Erst als die Profiwelt sah, daß es in der Amateurwelt leistungsfähige Rechner für kleines Geld gab, wollte Microsoft auch den Profisektor bedienen, den Profis konnte man jedoch nicht die alte DOS Bretterbude andrehen. Microsoft tat was es immer getan hat und ging Einkaufen. DEC hingegen – ziemlich klamm – entwickelte ein neues Betriebssystem. Heraus kam Windows NT, von DEC halbfertig erworben von Microsoft zuerst angekündigt, dann noch mal verschoben und angekündigt, dann ... verschoben ... angekündigt (irgendwie hieß das Betriebssystem zu diesem Zeitpunkt Windows NOT THERE) und endlich lang erwartet unausgereift wie es war auf dem Markt geworfen.
Diese gesamten Beschriebenen Betriebssysteme sind auf Objektorientiertheit zugeschnitten. (Für alle die bis hierhin gelesen habe – das war das Thema.) Der Hauptsinn der Objektorientiertheit bestand darin, Strukturen die schon vorhanden sind (Klassen) zu verwenden, also eine Schalfläche nicht neu zu programmieren sondern aus der Klasse Schaltfläche eine spezifische Schalfläche oder abermals eine Klasse der OK / abbrechen Schaltfläche zu machen. Den Betriebssystemen entstand hieraus ein riesiger Arbeitsspeicherverwaltungsaufwand, sie hatten es nicht mehr mit Programmierern zu tun, die direkt auf Speicher oder auch auf Schnittstellen zugriffen, sondern mußten diese Aufgaben selbst erledigen. Durch diesen Kunstgriff hatte man Computer gebaut, die nicht mehr nur mit einer Aufgabe befaßt sind, Computer wurden erst durch die Objektorientiertheit universeller - ! UND INSTABIELER !
Rechenintensive Anwendungen, kritische Finanzprozesse oder auch Automatisierungsprozesse müssen aber eins nicht sein: Universell, stabil hingegen wäre gelegentlich nicht schlecht. Fürs Universelle gibt’s ja in der Automatisierung noch den Visualisierungsrechner im Leitstand oder das CE Panel in der Schranktür, für den Fall, daß diese Geräte ausfallen schafft man sich Notbedienmöglichkeiten und kann auch Auftraggebern plausibel machen, daß dies nun fehleranfällige IT und nicht Automatisierungstechnik ist. Wer seine Anlagensteuerung auf fehleranfällige Speicherzuweisungen durch Objektorientiertheit aufsetzt, kann größere Schäden hierdurch nicht einfach begründen, sondern braucht ein Ticket für ‚den Zug nach Nirgendwo’ – da finden sie einen nicht.

Gruß

Ralf

[Ralle]

@Ralf

Guter Aufsatz von meinem Namensvetter !!!

Ralf hat Recht, es ist ja nicht so, daß im Bereich der Automatisierungstechnik keine Innovationsfreudigkeit herrscht. Man kann dem Markt nur Stabilität wünschen (technische natürlich), nur so können stabile SPS-Systeme betrieben werden. Inzwischen stürzt mein W2K-Rechner höchst selten ab (warum????), aber trotzdem, eine SPS ist mit persönlich in 10 Jahren erst einmal gestorben. Objektorientiert ist ja schön und gut, aber wenn ich so meinen Programmierstil (Delphi) betrachte, dann würde ich nicht wagen, mit einem meiner Programme eine kritische (Sicherheit und Kosten) Maschine zu steuern, daß überlaß ich lieber einer guten alten SPS.

rk

[Zottel]

Objektorientiert ist ja schön und gut, aber wenn ich so meinen Programmierstil (Delphi) betrachte, dann würde ich nicht wagen, mit einem meiner Programme eine kritische (Sicherheit und Kosten) Maschine zu steuern, daß überlaß ich lieber einer guten alten SPS.

Wenn man in der SPS "Zeiger" =berechnete Adressen, B MW x in der S5, alle Aren indirekter Adressierung in der S7 benutzt, kann man auch typische Probleme von Pascal und C bekommen: Zeiger, die auf nicht existierenden oder anderweitig genutzten Speicher verweisen und Überläufe der Ziel-Speicherbereiche.

Bei ganz "einfachen" Problemen, die überwiegend Boole´sche Logik bearbeiten, habe ich schon haarsträubende Progamme gesehen, vor allem bei Schrittketten. Erst neulich habe ich in eine Steuerung hineingeguckt, bei der zwei Teilschrittketten das Hoch- und Herunterfahren steuern. Bei ungünstigem Zusammentreffen "Ein-Taster noch gedrückt" und "gewisse Störung tritt auf" ist sie nach der Benennung der Merker gleichzeitig "ein" und "aus" !
Der Kummer gewohnte Bediener kommt da nur durch Not-Aus raus und muß von vorne Einrichten.

[zotos]

Ich bin kein Fan von der Idee Java in einer SPS einzusetzen. Ich muss aber drfunfrock recht geben das es zeit ist Objekt orientierte Programmierung in der Automatisierung zu verbreiten. Das die Automatisierungstechnik größten teils noch tief in den Achtzigern steckt erlebe ich auch tag täglich. Das ist aber größtenteils legitim. Es wird ja auch selten ein Projekt wirklich neu geschrieben. Die meisten Programmierer arbeiten wohl nach dem Patchwork Prinzip, Copy -> Past. Und dann behaupten sie noch das wäre eine Art Bibliothek. Die Schuld für die rückständliche Programmierweise Tragen wohl die Hersteller der SPS-Systeme. Das AWL so was von out ist werden einige Kollegen nicht akzeptieren wollen aber was ist an AWL besser im vergleich zu ST (für Siemens SCL)? Dass Sprünge aller GOTO super schlecht für die Übersichtlichkeit und Fehlersicherheit sind ist seit 1968 genügend Diskutiert worden

Dijkstra (196 einen Artikel in den Communications of the ACM, der den Anfang moderner Software-Entwicklung markierte. Statt wilder Sprünge durch GOTO-Befehle sollten WHILE, DO oder UNTIL den Programmfluss strukturieren

Ein weiteres Problem sehe ich in der gerade durch Siemens unterstützen Merker und Datenbaustein Philosophie. Ich verstehe nicht warum das sich immer noch hält die Speicheraufteilung sollte Aufgabe des Betriebssystems sein. Das ich als Benutzer mit Merkerwortadressen arbeiten muss ist schlicht eine Aufforderung unsaubere Programmierung zu betreiben und Überschneidungen zu provozieren. Das sollte wie in jeder Hochsprache nur über Variablen laufen.
Aber ich verschwende hier nur Zeit und Energie. Das der Weg in der Automatisierung weiter in Richtung Hochsprache und Objekt Orientierung geht ist leicht ersichtlich, der Strukturierte Text ist ein beweis dafür.
Es ist aber ebenso klar das FUP (zur Not auch AWL und KOP) für einfache Logische Verknüpfungen unersetzlich und unschlagbar ist. Speziallösungen wie grafische Schrittketten a la Graph7 sind natürlich auch sehr berechtigte Ansätze und werden wohl noch zunehmen ich denke da an Datenflussmodelle a la LabView.
Man kann da aber nicht nach einem klaren Schnitt rufen. Ein sehr großer Prozentsatz der Automatisierungslösungen basiert auf AWL und daher muss man sich damit abfinden die Philosophie die dahinter steckt als Praxistauglich zu bewerten und nicht zu verurteilen.

Ich möchte hier keine Anfeindungen es ging mir nur darum die Richtung zu zeigen in die sich, meiner Meinung nach, die Automatisierungstechnik entwickelt.