-> Hier kostenlos registrieren
Hallo @
Wenn ich die Möglichkeiten sehe, die sich mir im Simatic-S7-Bereich so bieten, da graut's mir eigentlich und für mich wird die Frage immer deutlicher, warum ein Anwender soviel Gehirnakrobatik aufwenden muss, um ein halbwegs ordentliches S7-SPS-Programm auf die Reihe zu bringen.
Was gibt es denn so in der S7-Welt:
AWL - ist was für Leute, die sich bis in die tiefsten Winkel einer CPU auskennen müssen und wird LEIDER von der Mehrzahl der Kundschaft abgelehnt. AWL ist aber bis heute immer noch das Mittel der Wahl, wenn es darum geht, effiziente Programme zu erstellen, da führt nach meinem Verständnis kein Weg daran vorbei, auch wenn es die Befürworter anderer Ansichten nicht wahr haben wollen.
KOP und FUP - ich schmeiß das mal in einen Topf (zumindest aus meiner Sicht) ist was für Leute, die mit dem Zeigefinger die grafischen Linien nachfahren und so die Logik erfassen wollen ('tschuldigung wenn ich das so salopp ausdrücke). Spätestens bei komplexeren Problemen, die mit arithmetischen Mitteln gelöst werden müssen, wird's fad und man sehnt sich nach AWL zurück (SCL klammere ich an dieser Stelle vorerst einmal aus). Zu Zeiten der S5 habe ich bei meinen Projekten FUP und KOP eine klare Absage erteilt - bei S7-CFC ergibt FUP und KOP ohnehin keinen Sinn mehr. Es macht z.B. keinen Sinn drei Logikzweige herunterzurasseln, wenn jeder Zweig nur bei einer bestimmten Bedingung Gültigkeit besitzt. Dies ist immer dann der Fall, wenn "z" durch verschiedene Logikmuster gebildet werden soll aber das jeweilige Logikmuster nur bei einer bestimmten Bedingung gültig ist. Bei z.B. drei Logikmustern führt dies unter KOP und FUP schon zu drei unnützen UND-Funktionen und einer unnützen ODER-Funktion, um schließlich "z" zu bestimmen. Bei großen Programmen kann dies schon mal dazu führen, dass die Zykluszeit nachgetriggert werden muss, was eigentlich keine gute Sache ist.
SCL - Structured Control Language, ein pathetischer Name für etwas, was es eigentlich nicht verdient so genannt zu werden. Ich drücke das mal bewusst so provozierend aus. Wenn SIEMENS in seinem Handbuch zu SCL die Orientierung zu PASCAL hervorhebt, wird mir schlecht. Ich kann gar nicht so viel essen, wie ich kotzen möchte. Was bleibt sind die zu Pascal ähnlichen syntaktischen Regeln aber spätestens beim Aufruf einer Funktion oder Prozedur werden diese Regeln bei der Parameterübergabe schon verletzt. Wenn SCL wenigstens ein Minimum dessen bieten würde, was in Pascal tatsächlich formuliert werden könnte, so wäre wenigstens der Weg von AWL zu SCL mit einem positiven Vorzeichen besetzt.
CFC - hier verkommt der SPS-Programierer zum "Verdrahter" von Funktionsbausteinen, deren Komplexität er in den allermeisten Fällen nicht übersehen kann. Das Ergebnis ist dann oft nur über Try&Error zu erreichen und basiert selten auf dem zuvor angedachten Lösungsweg, der mit einer klaren Programmformulierung in einer klaren Programmiersprache effizienter erreichbar gewesen wäre. CFC setzt daher auf den intensiven Gebrauch von SCL und AWL.
Jetzt hat die CFC-Fangemeinde sich selbst in eine Ecke manövriert (oder besser manövrieren lassen), in dem für veraltete Argumente kein Platz mehr ist. Früher hat vielfach das Argument gegolten, AWL könne nicht von Instandhaltungselektrikern verstanden werden - ja und, dann hätte der Kunde doch eigentlich mehr in die Weiterbildung seines Personals investieren müssen! Heute bietet sich die Möglichkeit an, komplexere oder wiederkehrende Funktionen in SCL oder AWL zu definieren und diese dann in CFC einzubauen und wird, erstaunlich genug, von den Kunden so akzeptiert! Man könnte natürlich auch diese komplexeren oder wiederkehrenden Funktionen als Plan-in-Plan implementieren, bei umfangreichen Projekten sind dann aber ziemlich schnell die Resourcen erschöpft, die Grenze bei einem größeren Projekt auszutesten ist dann eine ziemlich miserable Ausgangslage und man wird dann die Vernunft walten lassen und sich gleich darauf einrichten, komplexere oder wiederkehrende Funktionen von Anfang an immer in SCL oder AWL zu definieren. Womit ich fast an dem Punkt einer Idee angelangt bin, die mir seit einiger Zeit nicht mehr aus dem Kopf geht.
Es gibt immer noch Leute, die AWL hassen, wie der Teufel das Weihwasser. Aber was hat es mit dem SCL auf sich? Unter SCL kann ich z.B. die simple Addition dreier Variablenwerte so ausdrücken:
Direkt in AWL implementiert würde das so aussehen können:
Aber was macht SCL beim Übersetzen????
Man kann also einen Baustein in einer x-beliebigen Library mit SCL erzeugen und den Baustein dann anschließend in das Projekt übertragen. Es wird nur der compilierte Code übertragen, nicht jedoch die SCL-Quelle. Man kann den Baustein dann im Projekt öffnen und - oh Wunder - man sieht AWL!!!!!!
Ja also - so ganz ohne AWL geht's dann doch nicht! Warum das so ist, will ich hier nicht näher vertiefen, es reicht zu wissen, das es so ist. Natürlich schaut die Formulierung des oben genannten Beispiels in SCL viel eleganter als in AWL. Aber für jemanden, der in einer Hochsprache wie Pascal oder C zu hause ist, ist die von Siemens vorgehaltene SCL-Umgebung mehr als jämmerlich. Ich will Pascal nicht abwerten, ich selbst bin über Pascal zu C gekommen und so hätte ich mir eigentlich vorstellen können, dass Siemens statt der Anlehnung an Pascal dann doch besser eine Anlehnung an C vorgenommen hätte.
Wesentlich ist, dass es in SCL selbst keine Debugmöglichkeiten gibt. Beim Testen eines in SCL geschriebenen Bausteins ist man entweder auf Try&Error angewiesen oder man knöpft sich den Baustein auf der AWL-Ebene (!!!) vor. Auch sind die Fehlerausschriften des SCL-Compilers sehr miserabel und braucht schon eine Menge an Intuition, um die Formulierungsfehler auf Anhieb zu finden.
Bei mir ist dann so die Idee entstanden, eine Entwicklungsumgebung für S7-Bausteine zu entwickeln, die im Rahmen der Möglichkeiten, die sich auf Simatic-S7 (Serie300/400) beziehen, statt einer Anlehnung an Pascal eben mit einer Ausrichtung zu C aufwarten kann. Der generierte Code wird im AWL-Format im Rahmen einer Textdatei gespeichert, der in die S7-Umgebung als AWL-Quelle importiert werden kann. Die Ausrichtung zu C sollte alle in C üblichen Methoden beinhalten, sofern dies entsprechend den Adressierungsmöglichkeiten der S7 durchführbar wäre.
Wer hätte Lust, an einem solchen Projekt für den Compilerbau mitzuwirken?
Gruß Barnee
Wenn ich die Möglichkeiten sehe, die sich mir im Simatic-S7-Bereich so bieten, da graut's mir eigentlich und für mich wird die Frage immer deutlicher, warum ein Anwender soviel Gehirnakrobatik aufwenden muss, um ein halbwegs ordentliches S7-SPS-Programm auf die Reihe zu bringen.
Was gibt es denn so in der S7-Welt:
AWL - ist was für Leute, die sich bis in die tiefsten Winkel einer CPU auskennen müssen und wird LEIDER von der Mehrzahl der Kundschaft abgelehnt. AWL ist aber bis heute immer noch das Mittel der Wahl, wenn es darum geht, effiziente Programme zu erstellen, da führt nach meinem Verständnis kein Weg daran vorbei, auch wenn es die Befürworter anderer Ansichten nicht wahr haben wollen.
KOP und FUP - ich schmeiß das mal in einen Topf (zumindest aus meiner Sicht) ist was für Leute, die mit dem Zeigefinger die grafischen Linien nachfahren und so die Logik erfassen wollen ('tschuldigung wenn ich das so salopp ausdrücke). Spätestens bei komplexeren Problemen, die mit arithmetischen Mitteln gelöst werden müssen, wird's fad und man sehnt sich nach AWL zurück (SCL klammere ich an dieser Stelle vorerst einmal aus). Zu Zeiten der S5 habe ich bei meinen Projekten FUP und KOP eine klare Absage erteilt - bei S7-CFC ergibt FUP und KOP ohnehin keinen Sinn mehr. Es macht z.B. keinen Sinn drei Logikzweige herunterzurasseln, wenn jeder Zweig nur bei einer bestimmten Bedingung Gültigkeit besitzt. Dies ist immer dann der Fall, wenn "z" durch verschiedene Logikmuster gebildet werden soll aber das jeweilige Logikmuster nur bei einer bestimmten Bedingung gültig ist. Bei z.B. drei Logikmustern führt dies unter KOP und FUP schon zu drei unnützen UND-Funktionen und einer unnützen ODER-Funktion, um schließlich "z" zu bestimmen. Bei großen Programmen kann dies schon mal dazu führen, dass die Zykluszeit nachgetriggert werden muss, was eigentlich keine gute Sache ist.
SCL - Structured Control Language, ein pathetischer Name für etwas, was es eigentlich nicht verdient so genannt zu werden. Ich drücke das mal bewusst so provozierend aus. Wenn SIEMENS in seinem Handbuch zu SCL die Orientierung zu PASCAL hervorhebt, wird mir schlecht. Ich kann gar nicht so viel essen, wie ich kotzen möchte. Was bleibt sind die zu Pascal ähnlichen syntaktischen Regeln aber spätestens beim Aufruf einer Funktion oder Prozedur werden diese Regeln bei der Parameterübergabe schon verletzt. Wenn SCL wenigstens ein Minimum dessen bieten würde, was in Pascal tatsächlich formuliert werden könnte, so wäre wenigstens der Weg von AWL zu SCL mit einem positiven Vorzeichen besetzt.
CFC - hier verkommt der SPS-Programierer zum "Verdrahter" von Funktionsbausteinen, deren Komplexität er in den allermeisten Fällen nicht übersehen kann. Das Ergebnis ist dann oft nur über Try&Error zu erreichen und basiert selten auf dem zuvor angedachten Lösungsweg, der mit einer klaren Programmformulierung in einer klaren Programmiersprache effizienter erreichbar gewesen wäre. CFC setzt daher auf den intensiven Gebrauch von SCL und AWL.
Jetzt hat die CFC-Fangemeinde sich selbst in eine Ecke manövriert (oder besser manövrieren lassen), in dem für veraltete Argumente kein Platz mehr ist. Früher hat vielfach das Argument gegolten, AWL könne nicht von Instandhaltungselektrikern verstanden werden - ja und, dann hätte der Kunde doch eigentlich mehr in die Weiterbildung seines Personals investieren müssen! Heute bietet sich die Möglichkeit an, komplexere oder wiederkehrende Funktionen in SCL oder AWL zu definieren und diese dann in CFC einzubauen und wird, erstaunlich genug, von den Kunden so akzeptiert! Man könnte natürlich auch diese komplexeren oder wiederkehrenden Funktionen als Plan-in-Plan implementieren, bei umfangreichen Projekten sind dann aber ziemlich schnell die Resourcen erschöpft, die Grenze bei einem größeren Projekt auszutesten ist dann eine ziemlich miserable Ausgangslage und man wird dann die Vernunft walten lassen und sich gleich darauf einrichten, komplexere oder wiederkehrende Funktionen von Anfang an immer in SCL oder AWL zu definieren. Womit ich fast an dem Punkt einer Idee angelangt bin, die mir seit einiger Zeit nicht mehr aus dem Kopf geht.
Es gibt immer noch Leute, die AWL hassen, wie der Teufel das Weihwasser. Aber was hat es mit dem SCL auf sich? Unter SCL kann ich z.B. die simple Addition dreier Variablenwerte so ausdrücken:
Code:
D := A + B + C;
Code:
L #A
L #B
+R
L #C
+R
T #DMan kann also einen Baustein in einer x-beliebigen Library mit SCL erzeugen und den Baustein dann anschließend in das Projekt übertragen. Es wird nur der compilierte Code übertragen, nicht jedoch die SCL-Quelle. Man kann den Baustein dann im Projekt öffnen und - oh Wunder - man sieht AWL!!!!!!
Ja also - so ganz ohne AWL geht's dann doch nicht! Warum das so ist, will ich hier nicht näher vertiefen, es reicht zu wissen, das es so ist. Natürlich schaut die Formulierung des oben genannten Beispiels in SCL viel eleganter als in AWL. Aber für jemanden, der in einer Hochsprache wie Pascal oder C zu hause ist, ist die von Siemens vorgehaltene SCL-Umgebung mehr als jämmerlich. Ich will Pascal nicht abwerten, ich selbst bin über Pascal zu C gekommen und so hätte ich mir eigentlich vorstellen können, dass Siemens statt der Anlehnung an Pascal dann doch besser eine Anlehnung an C vorgenommen hätte.
Wesentlich ist, dass es in SCL selbst keine Debugmöglichkeiten gibt. Beim Testen eines in SCL geschriebenen Bausteins ist man entweder auf Try&Error angewiesen oder man knöpft sich den Baustein auf der AWL-Ebene (!!!) vor. Auch sind die Fehlerausschriften des SCL-Compilers sehr miserabel und braucht schon eine Menge an Intuition, um die Formulierungsfehler auf Anhieb zu finden.
Bei mir ist dann so die Idee entstanden, eine Entwicklungsumgebung für S7-Bausteine zu entwickeln, die im Rahmen der Möglichkeiten, die sich auf Simatic-S7 (Serie300/400) beziehen, statt einer Anlehnung an Pascal eben mit einer Ausrichtung zu C aufwarten kann. Der generierte Code wird im AWL-Format im Rahmen einer Textdatei gespeichert, der in die S7-Umgebung als AWL-Quelle importiert werden kann. Die Ausrichtung zu C sollte alle in C üblichen Methoden beinhalten, sofern dies entsprechend den Adressierungsmöglichkeiten der S7 durchführbar wäre.
Wer hätte Lust, an einem solchen Projekt für den Compilerbau mitzuwirken?
Gruß Barnee
).
