Java als SPS Programmiersprache

[EdgarRR]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich möchte hier die Diskussion über die SPS / PLC Programmiersprachen anstossen. Mich würde intressieren wie ihr die Programmiersprachen im vergleich seht. Mein Problem bei diesen SPS-Sprachen ist, das alle immer wieder die Norm 61131 bemühen aber trotz dem keine einheitliche Sprache sondern immer wieder dialekte von diese Norm angelegt werden.
Hier meine Fragen:
1.Werden die Sparchen KOP / FUP / ST / AS noch gebraucht ?
2.Sollte nicht nur Textuelle-Sprachen verwendet werden ?
3.Sollte als Programmiersprache nicht z.B. Java verwendet werden.
Diese Sprache ist sehr standardisiert. Als Entwicklungs-System könnte
eine Open Source Anwendung dienen z.B. Eclipse.

Legende:
Anweisungsliste (AWL), Instruction List (IL)
- assemblerartige Sprache, nur hardwareunabhängiger Teil ist genormt
Kontaktplan(KOP), Ladder Diadramm (LD)
- grafische Dartsellung mit Kontakten, Kästen und Spulen
Funktionsbausteinsprache (FBS), Function Block Diagramm (FBD)
- analog zu Logikplänen, deshalb auch als Funktionsplan (FUP) bezeichnet
Ablaufsprache (AS), Sequential Function Chart (SFC)
- (grafische) Beschreibung von Ablaufketten mit Schritten und Transitionen
Strukturierter Text (ST), Structured Text (ST)
- Hochsprache, an PASCAL angelehnt mit SPSspezifischen Erweiterungen
- speziell für komplexe Berechnungen und Algorithmen

Mit freundlichen Grüßen
EdgarRR

 

[Zottel]

Hallo,

bei diesen SPS-Sprachen ist, das alle immer wieder die Norm 61131 bemühen aber trotz dem keine einheitliche Sprache sondern immer wieder dialekte von diese Norm angelegt
werden
Hier meine Fragen:
1.Werden die Sparchen KOP / FUP / ST / AS noch gebraucht ?

Ja

2.Sollte nicht nur Textuelle-Sprachen verwendet werden ?

Nein.
Schau dir mal COBOL an. Wenn du nicht einen masochistischen Spass am Tippen hast, verstehst du auf Anhieb was ich meine.

3.Sollte als Programmiersprache nicht z.B. Java verwendet
werden.

Au ja. Ein Stromstossrelais auf einer kleinen SPS:

final static boolean[] Eingaenge;
Eingaenge[] = new Boolean[14];
final static boolean[] Ausgaenge;
Ausgaenge[] = new Boolean[10];
/*
Im Gegensatz zu C,Pascal oder Makroassembler gibt es nun     	leider keine Möglickeit, die physikalischen Adressen der Ein-und Ausgänge anzugeben. Sprache erweitern oder native Bibliothek einbinden?
*/
final static boolean[] Merker;
/*
So eine Definition belegt pro boolean 32 Bits. Das
ist nicht schlechte Implementierung, sondern so festgelegt.
Wenn man?s ändern würde, merkt man es spätestens, wenn man ein boolean in einen stream schreibt (casts gibts ja nicht).
*/
Merker[] = new Boolean[256];
/*
 Ok, wir wollten ja gar nicht 256 Merker verwenden, sondern nur 3:
 boolean clock, master,slave;
 wuerde es auch tun, aber wenn ich die zu einem Bus-Partner,
 z.B. Bedienpanel schicke, wie weiss ich welcher welcher
 ist ? Paket packen:

 byte[] panelInfo=new byte[5];
 panelInfo[2]=myFancyBitPacker.pack(slave,master); ?
 ProfiBus.send(panelInfo);
*/
Merker[0]=Eingang[0];  // clock=Eingang[0];
/*
  Flip-Flop:
*/
if (Merker[0]) Merker[2]=Merker[1];
if (^Merker[0]) Merker[1]=^Merker[2];

Ausgang[0]=Merker[2];
/*
  Das war jetzt ein Stromstossrelais. JAVA typisch könnte
  das Flip-Flop auch gleich eine Klasse sein:
*/
  public class FlipFlop {
  	boolean clock,master,slave;
	public setInput(boolean in){
	  clock=in;
	}
	public getOutput(){
	  return master;
	}
	/*
	jetzt tut es noch nix. 1.Vorschlag:
	*/
	public setInput(boolean in){
	  clock=in;
	  if(clock) slave=^master; 
	  else master=^slave;
	}
/*
 Jetzt tut es was. Vielleicht wäre es aber noch
 schöner, es zu einer "autonom" agierenden
 Komponente zu machen, aus der man Netwerke "bauen" 	
 kann:
 Irgenwo im aufrufenden Programm stünde dann:

 FlipFlop flipFlop1;
 Eingang[0].addPropertyChangeListener(flipFlop1);
 flipFlop1.output.addPropertyChangeListener(Ausgang[0]);
*/

  public propertyChanged(PropertyChangeEvent e){
    if(e.get.// Auswertung von Art des Events und neuem Wert
    if(clock) slave=^master; else
	  	master=^slave;
  }
/*
  So, jetzt haben wir 2 Dinge geschafft: 
  1. die Reihenfolge der Abarbeitung ausgehebelt.
  Schaltnetze mit invertierenden Rückführeingängen lösen 
  jetzt Event-Stürme aus. Nachbildung eines Schütz, das
  seinen Spulenanschluss unterbricht, perfekt möglich.
  2.Im ersten Ansatz waren die Variablen statisch. Auftritt
  GarbageCollector, um den Event-Müll abzufahren.
*/
 }

Diese Sprache ist sehr standardisiert.

Und deshalb müssten sich die SPS-typischen booleans daran halten, wie booleans für die gelegentliche Verwendung in allgemeinen Programmen definiert wurden.

Als Entwicklungs-System könnte
eine Open Source Anwendung dienen z.B. Eclipse.

Ja, das geht auch so. Man kann ja ein Eclipse-Plugin für jede der vorhandenen Sprachen schreiben: Editor, Compiler, Eingabe-Syntaxprüfung, automatische Ergänzungsvorschläge, Debugger, Simulator.
Das kann dann Step7 und alle anderen ähnlichen Werkzeuge ablösen. Neue SPS-Marke braucht nur ein paar Erweiterungen.
Dann haben wir alles zusammen, um eine richtig komfortable Analyse draufzusetzen:

Du gehst an eine unbekannte Maschine, wo unerlärlicherweise der Ausgang A46.3 ("Hubtisch senken") nicht kommt. Das Tool lädt sich das undokumentierte SPS-Progamm aus der CPU. Du klickst auf "Explain state", tippst A46.3 ein und kreuzt an "explain not true". Das Tool vollzieht über beliebige Netzwerke die Ergebnisbildung nach und zeigt dir:
1.Möglichkeit E16.3 und E32.3 müsssten 1 sein.
2.Möglichkeit: M45.2 müsste 1 sein. M45.2 würde in PB 22 NW 3 speichernd gesetzt, wenn zu den vorhandenen Bedingungen hinzukäme: E46.7=1

Aus dem Schaltplan:
16.3 Handbetrieb,
E32.3 manuell senken,
E46.7 Initiator Tisch oben

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube dass die 61131 schon der richtige Weg ist. Jetzt müssten "nur noch" die Hersteller auch wirklich standardisieren.
Das ist wirklich nicht so einfach wie es sich anhört. Die Großen Hersteller und ihre Systeme blicken ja nun auf ein paar Jährchen Entwicklung zurück und haben ihr Süppchen mehr oder weniger gut gekocht. Das jetzt einfach mit einer einheitlichen Sprache oder Sprachfamilie abzulösen ist nicht nur firmenpolitisch sondern auch technisch schwierig. Das sind historisch gewachsene Systeme. Und stell dir erst mal vor was die „älteren“… sorry das ist jetzt etwas hart… sagen wir mal die… die alteingesessenen Programmierer dazu sagen würden. Ich kann mich dunkel daran erinnern wie die S7 auf dem Markt auftauchte war das Geschrei groß. Aber von Zeit zu Zeit muss eben eine Veränderung her. Wenn man aber die AWL/FUP/KOP Programmier die eh selten zu solch nützlichen Sprachen wie ST und AS greifen dazu bewegen will (um nicht zwingen zu sagen) in einer Sprache wie z.B. Java zu Programmieren dann wird die Reaktion sehr deutlich „negativ“ sein.

Außerdem ist Java gar nicht für die Automatisierung gedacht und das würde man immer wieder merken und bis es jeder Hersteller an sein System angepasst hätte wäre davon nicht mehr viel identisch.

Es ist nun mal so dass es nötig ist für jede Aufgabe die Richtige Programmiersprache zu wählen. Das bestätigt wohl jeder Programmierer. Die meisten (größeren) Projekte sind wohl in mehr als einer Sprache verfasst. Wenn ich es mit einer S7 zu tun habe, benutze ich für 20-30% FUP (Verknüpfungen und Verriegelungen) das ist ziemlich unabhängig von der Aufgabe den Rest teilen sich dann ST für Berechnungen und Wortverarbeitung und natürlich AS (Graph7) für den Ablauf. Das man die Aufgaben z.B. nur in AWL lösen könnte ist ja wohl jedem klar, ob es sinn macht wohl eher nicht.

Warum eigentlich Java? Viele SPS-Hersteller bieten doch an C Programme zu implementieren das kannst Du auch mit dem Notepad schreiben und anschließen Kompilieren.

Mir gefällt CoDeSys von 3S sehr-gut. Ich habe eine Entwicklungsumgebung für Hardware von verschiedenen Herstellern bzw. für Soft-SPS&en.

Gruß

ZoToS

 

[plc_tippser]

Hi,
ich programmiere S7 und B&R. Ich hasse dieses eingeschränkte S7-Zeug. Die B&R kann C und Automation Basic neben KOP,AWL,AS. Ich bevorzuge die C und A-Basic. Ich habe noch nie ST unter S7 getestet, steht aber ganz oben auf der Liste. Kann ich da auch mit Zeigern und Strukturen vernünftig arbeiten?

Das Problem ist, nicht jeder SPSler hat ein gescheites Infostudium oder ähnliches. Schon gar nicht die Elektriker, Kundendienstler, denk an die kleinen Betriebe. Deshalb kommst Du nicht um die KOP,FUP Sache herum. Das nichts untereinander kompatibel ist, ist schei.... und lässtig. So schreibe ich ein Standardprogramm unter S7 und ein halbes Jahr tippe ich es in B&R.

Zottelchen hat ja einen Kurz :lol: kommentar geschrieben. Leg den mal einem Nichtinformatiker vor.

Gruß pt

 

[Zottel]

Bin selbst kein "gelernter" Informatiker
Unter anderem dachte ich, daß dieser Kommentar den ursprünglichen Poster von seiner eigenen Idee abschrecken möchte.
Ich selbst wäre ganz zufrieden wenn es nur einen gescheiten Assembler von jedem SPS-Hersteller gäbe. Eingabe in beliebigem Texteditor, assemblieren fertig. An Step7 habe ich mich gewöhnt. Microwins Syntaxhilfe fügt mir Schaden zu: Ich tippe was ein, Microwin korrigiert, ich weiss im selben Moment, daß es nicht korrekt ist, korrigiere aber die Korrektur,nicht meine Eingabe, woraus wieder Müll entsteht...

Dein S7 nach B&R Problem liesse sich dann so lösen:
1. Im S7 Quelltext per Suche&Ersteze oder per Script bekannte Inkompatibilitäten durch äquivalente Ausdrücke von B&R ersetzen.
2. Eventuell verbleibende Reste nacharbeiten.

Wenn das zu viel Arbeit macht oder nur oft genug vorkommt, eigene Makros schreiben, die sich per #define oder Schalter im Script S7- oder B&R-spezifisch auflösen lassen.

Edgar könnte dann ein Backend (Codegenerator) zu GCJ (gnu JAVA Compiler) haben, was ihm den Assemblercode beliebiger Steuerungen aus JAVA erzeugt. Einmal in der Welt, würde dieses Backend automatisch auch mit GCC (gnu C Compiler) fuktionieren und dir gestatten, die Steurung in C zu Programmieren. Liebhaber erhielten Fortran und Ada als Dreingabe.
Das alles bräuchte noch jeweils eine ( für C kleine, für JAVA grosse) Zusatzbibliothek, die ein paar Funktionen
enthält, die der Compiler zur Laufzeit vorraussetzt.

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit dem Assembler hört sich zwar gut an ist aber nicht so. Das würde nie ein wirklich gutes System ergeben wenn Du versuchst eine Maschine in Assembler zu Programmieren. Selbst C ist sehr unkomfortabel für aufgaben die nach dem Prinzip der Echtzeitfähigkeit laufen sollen. Man verfängt sich sehr schnell in einer schleife oder spricht eine falsche Hardwareadresse an. Bei Assembler mit den ganzen JMP (Jump&s/Goto&s) würdest Du wahnsinnig werden. Dazu kommt noch das Betriebssystem der Hersteller, jeder Hersteller hat da doch ein OS auf der Kiste laufen um die Hardware anzusprechen und übergeordnete Funktionen wie Schnittstellen-Protokolle, Watchdogs, Diagnosetools, etc. zu realisieren.
Das ist mit Sicherheit auch nicht überall gleich!
Es gibt aber doch Steuerungen die mit C Programmiert werden?! Ja, die gibt es und zwar jede menge. Aber die meisten benutzen diese Funktion als Erweiterung um Abläufe zu programmieren komplexe Berechnungen auszuführen… eben um Algorithmen abzubilden.
Der „Verknüpfungskram“ ist dort meist immer noch in einer SPS-Funktion in AWL/FUP/KOP gelöst. Was soll euere SPS eigentlich machen? Wollt ihr noch Prozesse und Maschinen steuern(?) oder doch lieber die Lohnbuchhaltung darauf machen? Es ist nun mal so das jedes Problem nach der geeigneten Programmiersprache verlangt. Und der schritt zu C/Assembler wäre ein Rückschritt. Assembler sollte man den Herstellern überlassen.
Ich meine das es sinniger wäre ein genormtes Projektformat zu erzeugen dass auf der IEC61131-3 beruht und dann von verschiedenen Entwicklungsumgebungen bearbeitet werden kann.
Aber das ist ja alles nur Wunschdenken! Es ist nun mal so das jeder Hersteller (in Deutschland Siemens) ein berechtigtes Interesse daran hat das jeder sein Süppchen weiter alleine kocht. Es ist nun mal so dass die Inkompatibilität auch ein Vorteil ist. Wie oft kommt es denn vor das der Kunde auf ein SPS-System besteht auch wenn er dafür mehr Geld ausgeben muss? Das System das die eigenen Betriebselektriker beherrschen ist das beste System für den Kunden. Folglich verdient z.B. Siemens daran das ihr System nicht einfach austauschbar ist. //um die zurufe und was ist mit den kompatiblen Systemen wie VIPA und Co. Gleich zu beantworten. Es ist doch so wenn ein Maschinenbauer auf billige Produkte wert legt dann kauft er auch billige Produkte. Wenn man als Firma Siemens nicht in die Preisklasse einsteigen möchte verkauft man eben Lizenzen macht damit noch genug Geld und braucht sich nicht mit den Kunden zu belasten die um den Preis feilschen und dann auch noch Garantieansprüche stellen.//

Fazit 1: Historischgewachsene Monopole und Systeme sind schwer zu kippen!

Fazit 2: Jeder Programmierer hat einwenig Macht. Und kann das System vorschlagen das er für das bessere hält. Wenn die Argumente gut sind kann er dies vielleicht auch mal durchsetzen.

Gruß
ZoToS

 

[EWS]

Hi

Also ich bin einer von den schlecht ausgebildeten.
Leider bin ich selbst kein "gelernter Informatiker" und wenn ich die Jungs an den Anlagen sehe bin ich auch oft froh das es so ist.

Mir persönlich gefällt die IEC1131-3 nicht ganz so gut. Wir setzen Sie zwar bei AEG und S7 200 -Steuerungen ein aber ist nicht 100% mein Fall.

Von allen "Sprachen" wenn man Sie so nennen darf gefällt mir AWL eigentlich am besten aber beim Beobachten im Status haben FUP und KOP doch einige Vorteile.

Viele Kunden wünschen sich auch ein Programm in KOP oder FUP so das wir in den letzten Jahren immer mehr in KOP oder FUP die Programme schreiben. Das KOP und FUP etwas mehr Speicher braucht weiß ich auch.
Unsere eigenen Funktionsbausteine schreiben wir nur in AWL oder SCL.

Ich glaube das die gut ausgebildeten Informatiker auch nur C, C++, Pascal,VB,COBOL usw. wählen weil in Ihrem Studium der Schwerpunkt auf diesen Sprachen liegt und keiner gerne was neues lernt und manchmal liegt es auch daran das sich die Informatiker vielleicht für was besonderes halten.


netten Gruß

Christian

 

[Zottel]

Asl erstes mal: Ich wollte den Assembler als Basis-Tool. Dann kann man den Codegenerator eines beliebigen Compilers veranlassen, passende Assembler-Code zu generieren. In der Praxis nur GCC oder SDCC, da man deren Codegeneratoren selbst verändern kann.

Das mit dem Assembler hört sich zwar gut an ist aber nicht so. Das würde nie ein wirklich gutes System ergeben wenn Du versuchst eine Maschine in Assembler zu Programmieren.

De facto hat AWL sehr viel Ähnlichkeit mit Assembler. Ich stelle hier mal S7 code und 8051-Assembler nebeneinander. 8051 bietet sich an, da er Befehler zur direkten Bit-Manipulation hat. Manche Mnemonics mögen falsch sein, ist schon etwas her:

S7			S7-200		8051
U E3.4 	 	LD I3.4		MOV C,P3.4
O M2.6		O M2.6		ORL  C,2.6
S M3.4		S m3.4,1		JNC	M1:			*
								SET	3.4
								M1: <folgeanweisung>	
L MB 17		LD MB7				 MOV 17,A
L 15							
+I			+I,15,MB7	ADD A,15
T MB17					MOV A,17

Schreibe jetzt nicht mehr, weil es ätzend ist, dass einigermaßen in Spalten zu schreiben...
Die Sprunganweisung über den set-Befehl zusammen mit der folgenden Marke kann man in ein Makro packen, dann siehts noch gleicher aus.

Selbst C ist sehr unkomfortabel für aufgaben die nach dem Prinzip der Echtzeitfähigkeit laufen sollen. Man verfängt sich sehr schnell in einer schleife oder spricht eine falsche Hardwareadresse an.

Bei Schleifen ist die Hauptgefahr, dass sie halt mit mehr oder weniger Durchläufen wechselnde Laufzeiten benötigen. Du hast aber auch in Step7 Schleifenbefehle...

Bei Assembler mit den ganzen JMP (Jump&s/Goto&s) würdest Du wahnsinnig werden.

Ist das mit Marken bei Step7 anders? Ok, du kansst nur im selben Block springen.

Dazu kommt noch das Betriebssystem der Hersteller, jeder Hersteller hat da doch ein OS auf der Kiste laufen um die Hardware anzusprechen und übergeordnete Funktionen wie Schnittstellen-Protokolle, Watchdogs, Diagnosetools, etc. zu realisieren.

Da must du die Dokumentation der Schnittstelle und der Funktionalität haben. Ist mit den SFBs/SFCs genau das gleiche.

Das ist mit Sicherheit auch nicht überall gleich!
Es gibt aber doch Steuerungen die mit C Programmiert werden?! Ja, die gibt es und zwar jede menge. Aber die meisten benutzen diese Funktion als Erweiterung um Abläufe zu programmieren komplexe Berechnungen auszuführen? eben um Algorithmen abzubilden.
Der ?Verknüpfungskram? ist dort meist immer noch in einer SPS-Funktion in AWL/FUP/KOP gelöst. Was soll euere SPS eigentlich machen? Wollt ihr noch Prozesse und Maschinen steuern(?)

C oder andere Hochsprachen machen genau da Sinn, wo heute auch ST Sinn macht.
Manchmal brauch man auch Mathematik und Algorithmen in der Maschinensteurung:
Ich Habe eine Niveauregelung, wo ich von einem Gas-Ausperlrohr ein recht "verrauschtes" Signal bekomme. Neben dem absoluten Wert muss ich auswerten, ob der Spiegel steigt fällt und ob er das schnell oder langsam tut. Direkte Differenzbildung geht nicht. Ich habe auf einer 95U (10 Jahre her) zwei oder drei FIR-Filter programmiert, die mir Tiefpässe verschiedener Grenzfrequenz bilden. Damit ist die Kiste restlos ausgelastet.

Aber das ist ja alles nur Wunschdenken! Es ist nun mal so das jeder Hersteller (in Deutschland Siemens) ein berechtigtes Interesse daran hat das jeder sein Süppchen weiter alleine kocht.

Ja

 

[Anonymous]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Zottel: Hallo!
Technisch gesehen sind unsere Ansichten gar nicht weit von einander entfernt. Nur die Interpretation der Aussagen ist eine andere.
Z.B. ich deute auf eine Gefahr hin, das bei Assembler oft mit Sprüngen gearbeitet wird und dies zu Problemen führen kann.

Ist das mit Marken bei Step7 anders?

Antwort: Nein, man kann sich dort auch „tot“ springen.

Jetzt kommt das Aber: Man muss nicht so Häufigspringen wie in Assembler. Als beweis verweise ich auf Deinen „Code“ in dem Du sehr anschaulich S7-AWL, S7-200-AWL und 8051-Assembler vergleichst. In dieser simplen Anweisung benötigst Du bereits eine Sprungmarke für Assembler auch wenn diese sehr übersichtlich auf einen Blick zu überschauen ist kann das in größeren Programmen zur Verwirrung führen.

Da must du die Dokumentation der Schnittstelle und der Funktionalität haben. Ist mit den SFBs/SFCs genau das gleiche.

Das die Schnittstellen des SPS-OS genauso übersichtlich gehalten sind wie die der SFBs/SFCs halte ich für ein Gerücht.

Das es sinn macht auf einer SPS eine Hochsprache wie C anzubieten habe ich nie bestritten. Aber mit ST/SCL ist es auch getan.

Meine Meinung steht: Mit Assembler sollen sich die SPS-Hardwarehersteller rumschlagen. Für den SPS-Programmierer wäre das ein Rückschritt.

Gruß
ZoToS

 

[Zottel]

@Zottel: Hallo!
Jetzt kommt das Aber: Man muss nicht so Häufigspringen wie in Assembler. Als beweis verweise ich auf Deinen ?Code? in dem Du sehr anschaulich S7-AWL, S7-200-AWL und 8051-Assembler vergleichst. In dieser simplen Anweisung benötigst Du bereits eine Sprungmarke für Assembler auch wenn diese sehr übersichtlich auf einen Blick zu überschauen ist kann das in größeren Programmen zur Verwirrung führen.

Und genau da habe ich dazugeschrieben, dass man das in ein Makro packen kann. Ausserdem benötigt man es nur auf einem 8051. Die S7 hat wahrscheinlich ein VKE-bedingtes set als einzelnen Maschinenbefehl.
Der 8051 braucht auch Bibliotheksaufrufe für Realzahlberechnungen. Ein 80486 braucht das nicht. Eine S7 wohl auch nicht.
An anderen Stellen agiert auch Step7 bei der Code-Erzeugung wie ein Makroassembler. Disassemblier mal den Maschinencode, der aus einem FB-Aufruf mit Parametern wird...

Dass die Schnittstellen des SPS-OS genauso übersichtlich gehalten sind wie die der SFBs/SFCs halte ich für ein Gerücht.

Ich halte die SFBs/SFCs nicht für den Gipfel der Übersichtlichkeit.Beispiel: Wozu überhaupt ein SFX zum Lesen der Uhrzeit? Das könnte man auch aus einem Sondermerkerbereich lesen. Gegenargument: Konsistenz der Daten über mehrere Byte-Lesebefehle. Gegengegenargument: In einem Rutsch mit dem Blockkopierbefehl kopieren. Der sollte ja auch wegen der Konsistenz beliebiger Daten ununterbrechbar sein.

Wenn die Funktionalität eines SPS-OS nicht umfangreicher ist, sollte auch die Schnittstelle nicht größer ausfallen.

Meine Meinung steht: Mit Assembler sollen sich die SPS-Hardwarehersteller rumschlagen. Für den SPS-Programmierer wäre das ein Rückschritt.

Mein Beispiel sollte zeigen, dass ein AWL-Programmiere schon jetzt de facto Assembler programmiert. D.h., auf derselben niedrigen Abstraktionsebene.

Was ich ändern möchte, ist das ein Programm namens Assembler zur Verfügung steht, was AWL-Quelltext(wie im AWL-Bausteineditor und wie im AWL-Quelleneditor), von mir aus mit absolut identischer Syntax wie Step7, in den Binärcode umsetzt.
Als Standalone-Programm und nicht hinter dem Bausteineditor verborgen.
Dann kann ich mein AWL-Programm in einem beliebigen Editor schreiben.
An anderer Stelle wurde hier im Forum über irgendwelche EXCEL-Anwendungen, die irgendwelche
Bezeichner oder Kommentare auf eine Länge von 40? bringen, diskutiert. Ein anständiger Assembler "fräße" Textdateien mit beliebig langen Bezeichnern und Kommentaren, "whitespace" als Trennzeichen. Er erwartet nicht bestimmte syntaktische Elemente an bestimmter Spaltenposition.
Wenn ich heute Code wiederverwenden will, muss er sich entweder für einen FB/FC eignen, oder ich muss ihn manuell per copy/paste übertragen. Da würde ein #include helfen.
Und dann gibt es nebenbei, als Abfallprodukt, die Möglichkeit Codegeneratoren für Hochsprachen zu schreiben, egal wie sinnvoll das ist, aber es gäbe sie.
Es gibt auch andere Gründe, AWL automatisch generieren zu wollen:
Auf der S5 hatte ich öfter das Problem, Analogwerte skalieren zu müssen mit den MUL und DIV FBs. Dabei darf man keine Überläufe bei den Ganzzahlen erzeugen. Andererseits möchte man keine Genauigkeit verschenken. Man kan mit Schiebebefehlen die Eingangsvariablen der Rechnung anpassen. Das ist aber fehlerträchtig. Genau das ließe sich mit einem Programm automatisieren und auf Korrektheit testen.

 

[Anonymous]

Sprachen

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

Re: Sprachen

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.
[url]http://libnodave.sourceforge.net
[/url]
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

[/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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Ralf

Guter Aufsatz von meinem Namensvetter !!! :shock:

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 (1968) 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.