Skip to Content

Registrieren Anmelden

Industry Online Support

Technical Forum

Navigation

Grundsätzliche Empfehlung wann SCL wann AWL

Erstellt von: Chris76 am: 14.01.2008 12:46 (13 Antworten)

Bewertung (2)

Dank 0

Result pages:: |; 1 | 2; |

14 Einträge

Einträge pro Seite: 10 | alle

14.01.2008 12:46	Bewerten (0)
Chris76 Beiträge: 8 Bewertung: (0)	Hallo, ich möchte kurz zu SCL was los werden (Fragen). Ich hab jetzt ein paar Maschine mit SCL programmiert, d.h. eine Mischung aus SCL und AWL 90 /10. Die Maschinen haben zum Teil 6 Achsen (Sinamic). Zyklusszeit ca +- 3 ms. Die eingefleischten AWL Programmier sind aber der Meinung, das AWL besser ist und kleinere Zyklusszeit möglich sind. Ich finde SCL einfacher kann durch den Strukturierten Text auch einfacher andere Steuerung programmieren (Scout, B&R ......usw.). Ich dachte immer Siemens ist = AWL und SCL ist nur ein Notlösung von Siemens. Was wird Grundsätzlich empfohlen oder erlaubt, kommt man mit SCL oder AWL beruflich weiter. mfg Christoph
Chris76 Beiträge: 8 Bewertung: (0)	Zuletzt bearbeitet von: CS Moderator am: 14.01.2008 16:29 Neue Überschrift nach Splitting
Vorschlag Bedanken Zitat Antwort

14.01.2008 16:38	Bewerten (0)
Klaus.Ka Beiträge: 46 Bewertung: (0)	wolpi@ts Es gibt ja auch deswegen so viele Programmiersprachen, damit jeder eine findet, die er benutzen möchte. Hast Du aber Dein Problem gelöst und die Programme nach AWL konvertiert? Viele Grüße Thomas hallo thomas ja da geb ich dir recht jedem das seine :) bei kop fup sucht man halt leichter nen fehler.die bediener der anlage tun sich da halt leichter. ja konnte es konvertieren aber da kam nur .... raus.muß mich leider doch länger hinsetzen und was schreiben :( viele grüße klaus hallo chris76 ich denke das ist auslegungsache man sollte sich im endefekt alle sprachen aneignen. ich denke was deine kollegen meinen ist die indirekte adressierung wo man noch zykluszeit sparen kann. ich denke nicht das awl oder scl als programme selbst schneller sind. viele grüße klaus
Klaus.Ka Beiträge: 46 Bewertung: (0)
Vorschlag Bedanken Zitat Antwort

15.01.2008 13:19	Bewerten (1)
wolpi@ts Silber-Mitglied Beigetreten: 06.03.2006 Letzter Bes: 13.09.2024 Beiträge: 369 Bewertung: (101)	Hallo Chris, Du wirfst ja eine ganze Menge Fragen auf ... da kann ich nur auch eine ganze Menge Antworten geben .... Ich bin ein eingefleischter SCL-Programmierer und habe noch nie (seit 1998- vorher habe ich PCs objektorientiert programmiert) ein längeres AWL-Programm geschrieben, als nötig ist, um einen Befehl, den mir SCL nicht zur Verfügung stellt (z.B. bis zur letzten Version die BCD-Umwandlungen), in eine Funktion zu packen, die es mir erlaubt, diesen in SCL doch zu benutzen. Einziger Kompromiss, den ich mal gemacht habe: Zur Steuerung der Abfertigung (Türen auf und zu und was alles so dazugehört) beim SkyTrain am Düsseldorfer Flughafen (Ihr dürft gerne lästern, aber bitte nicht über die Simatic ;-)habe ich HiGraph eingesetzt - und da kann man innen drin nur AWL-Code einbauen. Da ich mich aber dort nicht um die Zustandsverwaltung kümmern muss, bin ich damit klar gekommen und das Programm funktioniert ziemlich gut. Man kann es vielleicht so sehen: Wenn man wirklich nur logische Verknüpfungen programmiert, dann geht das sehr gut mit AWL. Sobald es aber mit Bedingungen oder gar Schleifen losgeht(Sprünge, bei denen dann wieder die Labels verwaltet werden müssen), ist AWL die schlechteste Lösung überhaupt. Ich habe schon oft erlebt, dass ein AWL-Programmierer seinen Algorithmus mit Copy-Paste vervielfacht hat und die CPU dann wild in seinem Programm rumgesprungen ist, weil er die Übersicht über die Labels verloren hatte. Strukturiert Programmieren geht eben in Maschinencode nicht. Strukturiert Programmieren ist aber eigentlich die einzige Chance, den Überblick über das Programm nicht zu verlieren. Wenn man also Schleifen hat und gar Felder oder eigene komplexe Datentypen indiziert adressieren muss, ist man mit SCL deutlich besser bedient. Meine Behauptung zum Aufwand: Programmieren mit AWL ist wie ein Baum mit dem Taschenmesserfällen. SCL-Programmierer benutzen dafür eher eine Kettensäge ;-) Bei einer armdicken Haselstaude mag das auch mit dem Messer noch funktionieren, aber eine ausgewachsene Buche ... Und dann das Märchen von der Laufzeit: Man kann SCL natürlich so programmieren, dass es unendlich Laufzeit schluckt. Wenn man zum Beispiel Elemente einer UDT in einemArray von diesen UDT in jeder Zeile immer wieder neu über einen variablen Index adressiert, dann braucht das Laufzeit ohne Ende. Wenn man aber die UDT am Anfang variabel indiziert in eine var_temp kopiert, mit dieser arbeitet und sie am Schluss wieder zurückkopiert, ist das Programm fast weg (verstanden? ;-) Überhaupt hat die Architektur der Software einen wesentlich größeren Einfluss auf die Laufzeit wie die Programmiersprache. Bei meinem letzten Projekt hatte ich einen 5 ms Takt zu erfüllen. Das klingt jetzt nicht nach schnell, aber die Rechenleistung, die dahinter steckte, war die einer C7-635. Es existierte bereits ein AWL-Programm, welches diese Anforderung bei weitem nicht erfüllte (OB1-Takt ca. 25-40 ms). Trotzdem ist es mir gelungen, ein SCL-Programm zu schreiben, mit dem ich die 5 ms für die Funktionen einhalten konnte, für die sie auch wichtig waren (das sind in der Regel bei weitem nicht alle). Eine andere Möglichkeit, wenn Du Laufzeitprobleme hast, wäre mal HiGraph anzuschauen. Wenn Du Deine Anlagenfunktionen in verschiedene Zustände strukturieren und die Bedingungen, welche nötig sind, um von einem Zustand in den anderen zu gelangen genau beschreiben kannst, dann ist das genau das richtige. Und die Laufzeit ist famos klein, weil das Programm immer nur den zyklischen Code des aktuellen Zustandes (das meiste kann man ein Mal beim Eintritt in diesen Zustand programmieren)und den Code der Bedingungen prüft, die vom aktuellen Zustand weg führen. Wenn Du Dich mit einem Technologen (z.B. Mechaniker) über Dein Programm und seine Funktionen unterhalten musst, wird dieser die Darstellung in HiGraph auch besser verstehen. Und wie kommt man beruflich weiter? Was soll ich da sagen? Ich bin ja beruflich nicht wirklich weitergekommen und bin immer noch kein großer Manager .... Aber mir macht die Arbeit Spaß und mir ist es schon einige Male gelungen, eigentlich unmögliche Aufgaben erfolgreich abzuschließen - und dabei habe ich immer SCL benutzt. Ein anderes Argument, was wir oft zugunsten AWL benutzen ist dies, dass ein Inbetriebsetzer SCL nicht kennt und deshalb das Programm in AWL ändern können muss. Das ist natürlich richtig (das mit den Kenntnissen der meisten Inbetriebsetzer ;-), aber dass er das Programm ändern können muss, halte ich für falsch. Wenn ich eine Software rausgebe, dann ist die so gut getestet, dass keine offensichtlichen Fehler mehr drin sind. Und wenn doch ein Fehler drin ist, dann kann mir der Inbetriebsetzer vielleicht die Symptome beschreiben aber ganz bestimmt nicht das ganze komplexe Programm verstehen - und schon gar nicht in AWL - und den Fehler selbst beheben (die Gefahr, dass dabei neue reinkommen, ist mir viel zu groß. So - jetzt kennt Ihr meine Meinung und könnt mich zerreißen. Ich kann nur sagen, dass noch keiner meiner Kollegen (einige AWL-Fans) meine Herausforderung angenommen hat, wirklich mal das selbe Problem doppelt zu programmieren und zu vergleichen wer schneller ist. Es heißt immer nur, wir können die Arbeit nicht doppelt machen. Sorry, dass es so viel wurde, aber das Thema ist komplex - und philosophisch. Viele Grüße Thomas

Vorschlag Bedanken Zitat Antwort

15.01.2008 15:48	Bewerten (0)
gochtel Silber-Mitglied Beigetreten: 19.04.2006 Letzter Bes: 10.12.2021 Beiträge: 521 Bewertung: (31)	das ist doch mal ne coole diskussion... ich hab kaum ahnung von scl, deswegen kann ich nichts dazu sagen. aber ich bin softwareentwickler, allerdings schreiben wir unsere programme in awl. ich wollte schon lange mal umsatteln, allerdings fehlt die zeit. wir haben unsere entwicklung nun seit ca. 8 jahren immer in awl geführt. das programm nun in scl zu wandeln wäre schier unmöglich und unsere laufenden anlagen erlauben dies auch nicht. aber ich gebe dir definitiv recht mit scl. ist sicher einfacher (komplexe lösungen) und grad die möglichkeit, daß keiner ohne weiteres drin rum schreiben kann, ist wirklich wichtig. ich erlebe öffters, wenn der ein oder andere inbetriebnehmer im programm rum schreibt. hat aber auch sein für und wieder. wie gut sind denn die diagnosemöglichkeiten in scl? gibt es welche? ich könnte mir vorstellen, einige komplexe funktionen, wo keiner mehr was ändern muß/darf in scl zu schreiben... tschau sven
	...wer seine träume verwirklichen will, muß auch daraus erwachen... ARTTHEA Bühnentechnik GmbH
Vorschlag Bedanken Zitat Antwort

15.01.2008 16:05	Bewerten (0)
wolpi@ts Silber-Mitglied Beigetreten: 06.03.2006 Letzter Bes: 13.09.2024 Beiträge: 369 Bewertung: (101)	Hallo Sven, man kann auch in einem SCL-Baustein online auf Quellebene debuggen. Duhast auf der linken Bildschirmhälfte den SCL-Codeund auf der rechten dieaktuellen Inhalte der Variablen, die das Programm gerade benutzt (wenn ich dran denke, stelle ich hier mal eine Hardcopy vom Testmodus rein) Man kann auch in einen Einzelschrittmodus gehen und von Haltepunkt zu Haltepunkt springen, aber damit habe ich mich bisher nicht beschäftigt. Entweder war die Aufgabe so einfach, dass ich die Funktion nicht brauchte, oder die CPU war etwas empfindlich auf anhalten, und ich durfte sie nicht nutzen. Auch hat manbeim Debuggen die selben Probleme wie in AWL - wenn der Baustein mehrfach aufgerufen wird,bleibt es dem Zufall überlassen, welchen Aufruf man gerade erwischt. Viele Grüße Thomas

Vorschlag Bedanken Zitat Antwort

16.01.2008 07:28	Bewerten (0)
gochtel Silber-Mitglied Beigetreten: 19.04.2006 Letzter Bes: 10.12.2021 Beiträge: 521 Bewertung: (31)	hallo thomas, also sind die gängigen debugg-möglichkeiten ebendso vorhanden. das ist schon mal gut. wolpi@ts Man kann auch in einen Einzelschrittmodus gehen und von Haltepunkt zu Haltepunkt springen, ... diese debugg-möglichkeit nutze ich öffters. wolpi@ts Auch hat manbeim Debuggen die selben Probleme wie in AWL - wenn der Baustein mehrfach aufgerufen wird,bleibt es dem Zufall überlassen, welchen Aufruf man gerade erwischt. durch den einzelschrittmodus kann ich dies gezielt debuggen. wir programmieren sehr viel mit schleifen, haben zähler und adressregister, die hochgezählt werden. mit dem einzelschrittmodus komme ich dann sehr schnell zum ziel/fehler.
	Zuletzt bearbeitet von: gochtel am: 16.01.2008 07:28 ...wer seine träume verwirklichen will, muß auch daraus erwachen... ARTTHEA Bühnentechnik GmbH
Vorschlag Bedanken Zitat Antwort

16.01.2008 07:39	Bewerten (0)
Chris76 Beiträge: 8 Bewertung: (0)	Hallo, ich setz mir immer Schrittmerker und schau mir Alles in der Variablentabelle an. Hab so noch nie Probleme gehabt ein Fehlerzu finden. Beim programmieren hab ichaber ein Problem, ich arbeite überwiegend mit DB und UDT´s(anstatt Symboltabelle) . Wenn ich ein Programmteil aus einem alten Programm kopiere, DB und UDTs stimmen mit dem Programm überein. - Nun verändert man ein UDT oder DB indem man eine Variable ergänzt, oder Bereich verändert, stimmen anschließenddie Adressen mit der symbolischen Bezeichnung nicht mehr überein und nichts Funktioniert mehr. Das Programm wirdNICHT automatisch aktualisiert. Ich mach mirnun Platzhalter oder füge die Variablen am Ende ein. mfg Christoph
Chris76 Beiträge: 8 Bewertung: (0)	Zuletzt bearbeitet von: Chris76 am: 16.01.2008 07:45 Zuletzt bearbeitet von: Chris76 am: 16.01.2008 07:45
Vorschlag Bedanken Zitat Antwort

16.01.2008 08:00	Bewerten (0)
wolpi@ts Silber-Mitglied Beigetreten: 06.03.2006 Letzter Bes: 13.09.2024 Beiträge: 369 Bewertung: (101)	Hallo Christoph, bei der Variablentabelle gibt es einen Trick: Wenn Du die Symbole markierst und in ein Text- oder Worddokument einfügst, dann kannst Du die da mal wieder holen und die Variablentabelle sucht sich dann selbst die Adressen. Dass sich das Programm mit UDT und DB nicht automatisch aktualisiert, wundert auch nur einen alten Simatic-Programmierer ;-) Bei "normaler" Programmierung, z.B. C oder Pascal, musste man schon immer das Programm neu übersetzen und linken. OK - moderne Compiler haben da inzwischen ihre Make-Funktion und wissen genau, welche Programmteile sie neu übersetzen müssen. Da hat die SPS-Programmerstellung einfach eine andere Geschichte. Wir haben schon immer einzelne Bausteine im laufenden Betrieb ausgetauscht - was ja auch wirklich klasse funktioniert (wenigstens so lange man Programm und Daten in den Quellen konsequent trennt). Ich habe aber die Erfahrung gemacht, dass das Programm meistens besser funktioniert, wenn man NACH dem Ändern von Daten ALLE Quellen neu übersetzt (und am Besten vorher die Bausteine löscht, die bei der Übersetzung wieder entstehen sollen). Der Glaube, dass man mein, zu wissen, welche Programme die Daten benutzen, deren UDT man eben geändert hat, dauert meistens 10 mal so lang wie sofort übersetzen, weil man sich erst ärgert, dann den Fehler sucht, ihn nicht findet, sich doch zum Compilieren entschließt und sich wundert, dass plötzlich alles funktioniert. Und das mit der Symboltabelle funktioniert auchnur, wenn man nicht solche Schweinereien programmiert, die die AWL-Programme angeblich so schnell machen. Grüße Thomas

Vorschlag Bedanken Zitat Antwort

18.01.2008 12:30	Bewerten (0)
wolpi@ts Silber-Mitglied Beigetreten: 06.03.2006 Letzter Bes: 13.09.2024 Beiträge: 369 Bewertung: (101)	Im Prinzip kann man Programmiersprachen in verschiedene Ebenen einteilen. Die CPU selbst verarbeitet Maschinencode. Das bedeutet, dass sie ihren Speicher Byte für Byte (oder auch mal mehrere Bytes) durchforstet und mit ihren Registern genau die Anweisungen ausführt, welche in den Befehlen stehen. Kaum ein Mensch kann diesen Maschinencode lesen und wir müssen es ja auch nicht. Eine Assemblersprache wie z.B. auch AWL setzt jetzt für den Maschinencode mehr oder weniger gut verstehbare Abkürzungen ein, ebenso werden Variablenadressen und Sprungzieladressen durch Eure Namen ersetzt. Trotzdem hat immer noch jede einzelne Anweisung in der Assemblersprache ihre exakte Entsprechung in einer genau bestimmten Anweisung im Maschinencode. Wer Assembler programmiert, muss also sehr genau wissen, wie die CPU im Detail mit ihren Registern funktioniert! Hochsprachen wie z.B. Basic, Pascal, C aber eben auch SCL setzen eine Abstraktionsstufe höher an. Hier beschreibt man mittels einer standardisierten Syntax in einem halbwegs verständlichen Englisch den Ablauf des Programms mit seinen Verzweigungen, Schleifen und komplexen Datenzugriffen. Um die Details - welche Assemblerbefehle in welcher Reihenfolge benutzt werden und wie die Labels und Sprungbefehle eingesetzt werden - kümmert sich der Compiler. Wie genau die CPU funktioniert, interessiert nicht mehr - dieses Wissen hat der Programmierer des Compilers in diesen eingebaut. Das erklärt jetzt auch, warum ich bei ANY-Pointer-Akrobatik voller Ehrfurcht vor dem Programm sitze, dem Programmierer absoluten Respekt bezeuge und rundum froh und zufrieden bin, dass ich das gar nicht wissen muss und mein Programm trotzdem recht komplexe Aufgaben fehlerfrei ausführt. Und wenn Ihr dann mal Fehler sucht, ist auch ein kleines bisschen Schadenfreude dabei ;-) Thomas

Vorschlag Bedanken Zitat Antwort

23.01.2008 08:28	Bewerten (1)
mescalar Erfahrenes Mitglied Beigetreten: 05.01.2008 Letzter Bes: 07.10.2024 Beiträge: 85 Bewertung: (6)	wolpi@ts Hallo Sven, ....Auch hat manbeim Debuggen die selben Probleme wie in AWL - wenn der Baustein mehrfach aufgerufen wird,bleibt es dem Zufall überlassen, welchen Aufruf man gerade erwischt. Viele Grüße Thomas Hallo an alle, ist so nicht richtig; sowohl bei AWL awl auch bei SCL kann man die "Aufrufumgebung" setzen. Dann wird auch wirklich nur der Bausteinaufruf angezeigt, der interessiert. Ich selbst nutze dafür am liebsten (weil am einfachsten) den Instanz-DB. Zur AWL-SCL-Diskussion: Für mich eigentlich keine Frage mehr. SCL für jeden FB/FC. Vorteil: Auch nach Jahren verstehe ich meinen eigenen Code noch, Änderungen jederzeit problemlos. In AWL kann ich gar nicht so viel kommentieren, dass ich das nachJahren noch verstehe, wenns etwas komplizierter ist. Das Argument "der Servicemann versteht das nicht" zählt für mich nicht. Ein Baustein hat zu funktionieren, und dann ist es dem Servicemann egal, wie der Baustein programmiert ist, solange Ein- und Ausgangsparameter sowie die Funktion des Bausteins vernünftig dokumentiert sind. Es werden doch auch SFC/SFB eingesetzt, für die kein Quellcode vorhanden ist. Als Anwenderprogramm kommt für mich dann nur FUP oder noch lieber, wenn irgend möglich, CFC in Frage. CFC versteht zu Not auch jede(r) Sekretär(in). Zu den Nachteilen von SFC:Ein optimal programmierter SCL-Code wird immer grösser undlangsamer sein als ein optimal programmierter AWL-Code; das ist nun mal der Nachteil eines Compilers. Aber wo spielt das bei der heutigen CPU-Performance noch eine grosse Rolle? Grüsse mescalar

Vorschlag Bedanken Zitat Antwort

|

Teile diese Seite:

Teile diese Seite auf...

Verwandte Themen nach Schlüsselwörtern:

TIA STEP7 PLC-Programmierung Programm erstellen

Folgen Sie uns auf