AWL nach SCL convertieren

[kermit]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Kermit:
Sowohl Gravieren wie auch ich haben deinen PEW als Input einer Funktion bzw. eines FB's betrachtet. Hier relativiert sich deine Anmerkung, denn egal, wie oft ich einen IN-Parameter in einer FC (oder einem FB) aufrufe, es wird nur auf die übergebene Variable zugegriffen - nicht auf das PEW, wenn das der Übergabe-Parameter gewesen wäre.
Falls dieses Code-Schnipsel öfters in deinem Programm(en) Verwendung findet, so würde ich schon aus Gründen der Übersichtlichkeit hier auf ein Unter-Programm zugreifen.
In gleicher Weise säh das (bei mir) mit einem Eigenbau-Zähler aus ...
An dieser Stelle würde ich ggf. sogar beide Sachen zusammenziehen (wenn sie sowieso schon zusammengehören) um mir von der Funktion das Endergebnis als OUT liefern zu lassen. (Spart Code und erhöht definitiv die Übersichtlichkeit ...)

Zu deinem Bezug auf den anderen Thread habe ich in demselben zu dem Thema bereits meine Meinung dargestellt.

Gruß
LL

nun ja, ich hatte mal für mich entschieden, dass so ein Fünf-Zeiler, der wenn man ihn in einen FB/FC packt schon fast so viel Code für den Aufruf benötigt wie in dem Baustein dann selbst enthalten ist, ich diesen dann eben nicht als Extra-Funktion schreibe, sondern direkt code. Aber da will ich weder eine Grundsatzdiskussion lostreten, noch den von mir gewählten Weg zur obersten Maxime erheben ...

(sondern will ich eben nur erwähnen, dass sowas bei mir direkt im Programm steht und nicht in einer Unterroutine)

 

[joergel]

Hallo, die letzte Antwort ist aus dem Jahr 2008 und meine Frage wäre ob sich in den letzten Jahren etwas bezüglich eines Compilers getant hat?
Wenn's auf dem Hinweg geht, dann gehts irgendwie auch auf dem Rückweg - theoretisch.
Hat jemand etwas mitbekommen ob es aktuell einen Compiler gibt der AWL-Code nach SCL wandelt?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat jemand etwas mitbekommen ob es aktuell einen Compiler gibt der AWL-Code nach SCL wandelt?

Das ist mir nicht bekannt und das ist m.E. auch gar nicht sinnvoll (ich glaube einen aus AWL-Code automatisch generierten SCL-Code möchte ich nicht lesen wollen). Ich denke da noch an die Umsetzung S5 -> S7 ... 8)

Gruß
Larry

 

[Draco Malfoy]

Das ist mir nicht bekannt und das ist m.E. auch gar nicht sinnvoll (ich glaube einen aus AWL-Code automatisch generierten SCL-Code möchte ich nicht lesen wollen). Ich denke da noch an die Umsetzung S5 -> S7 ... 8)

Gruß
Larry

Es müsste aber mindestens irgendeinen Recompiler geben, der einen automatisch generierten AWL-Salat aus "verlorenen" oder rückgelesenen SCL Bausteinen wieder in eine Quelle zurückübersetzt. Ich wage zu vermuten, daß es solche Software bei der Firma Siemens gibt, nur bloß diese die nicht rausrückt.

 

[gravieren]

Hi

Ich mußte mir mal die mühe machen, Compilierten SCL-Code (dann war es AWL-Code, da die Quellen fehlten) erneut in SCL zu übersetzten.
Diese FC/FB waren zudem mit unterschiedlichen SCL-Compilern erzeugt worden.
(Compilerversion stand im Kopf als Kommentar)

Jeder Compiler hat je nach einstellung geringfügig anderen Code erzeugt.


Mein resume:
Es sollte schon möglich sein, einen AWL --> SCL "Translater" zu erzeugen.
(Es sind signifikante Code und Sprungmarken erzeugt worden.)

Diese habe ich jedoch erst gegen "ende der Übersetzung erkannt.
Vorher war es ein AWL-Spagetticode für mich.
Nachdem ich die SCL-Quelle hatte, erkannte ich schnelle die Funktionsweise.


Wir haben hier im Forum sehr gute Programmierer, denen es sicher möglich wäre diesen "Konverter" zu Programmieren.

P.S.:
Ich habe SCL-Compiler bis hinunter zu V2.1 benötigt ;-)


P.P.S.:
Letztendlich war ein Fehlerhafter Aufruf/Parametrisierung das Problem.
Also, der Fehler lag NICHT im "SCL/AWL" - Teil.

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein resume:
Es sollte schon möglich sein, einen AWL --> SCL "Translater" zu erzeugen.
(Es sind signifikante Code und Sprungmarken erzeugt worden.)
<...>
Wir haben hier im Forum sehr gute Programmierer, denen es sicher möglich wäre diesen "Konverter" zu Programmieren.

Dieser Meinung bin ich auch, und ich finde es schade daß sich bisher noch keine Leute gefunden haben, die sich für diese Aufgabe gewachsen oder in diese Richtung berufen fühlen. Denn der Nutzen für die Allgemeinheit wäre ja enorm. Meine Programmierkenntnisse reichen da leider bei Weitem nicht aus. Es gibt indes Leute, die bereits zu Fuß SCL Quellen rekonstruieren und das als eine Art Freizeitbeschäftigung praktizieren: http://plc4good.org.ua/index.php?sub=2 Dort liegt unter Anderem z.B. die ganze PID Modular Control Bibliothek in Quellenform vor.

Was noch eine wichtige Baustelle wäre, die mal angegangen werden sollte, ist die Rückentschlüsselung der Panelprojekte die nur in kompilierter Form vorliegen. Zumdestens die Bilder, Betriebsmeldungen und die Tag-Verbindungen in die Steuerung müsste man ja wohl irgendwie rekonstruieren können. Bei Projekten wo die Original-Dateien verloren sind (kann ganz einfach eine abgestürzte Festplatte, oder ein plötzlich verstorbener Programmierer sein) täte es die Arbeit wohl erheblich erleichtern.

 

[Thomas_v2.1]

Automatisiert lassen sich nicht immer 100% des Quellcodes wiederherstellen. Bestimmte Informationen wie AT-Sichten gehen z.B. vollständig beim Übersetzungsvorgang verloren. Schleifenkonstrukte lassen sich zwar prinzipiell erkennen, aber bestimmte Konstrukte erzeugen identischen AWL-Code. D.h. es wäre in vielen Fällen händische Nacharbeit notwendig.
Wenn du so ein Projekt veröffentlichst, würde ich gleich alle Kontaktdaten entfernen, weil du dir sicher sein kannst dass du etliche Anfragen bekommst warum dies und das nicht automatisiert funktioniert. Und das von Leuten die überhaupt keine Ahnung von der Thematik haben, und es somit sinnlos ist es zu erklären.

 

[Draco Malfoy]

Automatisiert lassen sich nicht immer 100% des Quellcodes wiederherstellen. Bestimmte Informationen wie AT-Sichten gehen z.B. vollständig beim Übersetzungsvorgang verloren. Schleifenkonstrukte lassen sich zwar prinzipiell erkennen, aber bestimmte Konstrukte erzeugen identischen AWL-Code. D.h. es wäre in vielen Fällen händische Nacharbeit notwendig.
Wenn du so ein Projekt veröffentlichst, würde ich gleich alle Kontaktdaten entfernen, weil du dir sicher sein kannst dass du etliche Anfragen bekommst warum dies und das nicht automatisiert funktioniert. Und das von Leuten die überhaupt keine Ahnung von der Thematik haben, und es somit sinnlos ist es zu erklären.

Nun, das wäre ja prinzipiell kein problem solange man durch die Software darauf hingewiesen wird, wo Nachbearbeitung notwendig wird und wo z.B. welche Varianten in Frage kommen. Mit Etwas Übung kommt man da wahrscheinlich schnell rein, aber ein gutes Analysewerkzeug fehlt weiterhin. Ich habe zwar in den Weiten des www. etwas gefunden, wo sich ein Basteler scheinbar daran versucht hat, aber da kommt immer noch ein ziemlicher Salat bei rum.Anhang anzeigen Converter.zip

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe sowas vor ein paar Jahren mal angefangen, aber dann nicht zu Ende geführt, weil es mir eigentlich nur um einen Baustein ging den ich übersetzt haben wollte. Ich war so weit, dass ich mir aus dem AWL Code einen Quasi-SCL in einer Grafik in der Struktur des Syntaxbaums generiert habe. Das hilft schon einiges weiter, und diesen Schritt benötigt man eh für die weitere Analyse.
Solche Sachen wie FC- oder FB-Aufrufe sind nochmal eine ganz andere Baustelle. Um diese wieder zurückzuübersetzen muss man die Makros kennen die der jeweilige Compiler aus den Aufrufen erzeugt. Und ich glaube sogar die sehen je nach Compilerversion unterschiedlich aus. Teilweise wird bei solchen Aufrufen kein AWL sondern direkt MC7 erzeugt.

Im Anhang eine Diagramm vom CONT_C den mein Programm generiert hat (hoffe man erkennt bei der Auflösung noch was).

 

[Draco Malfoy]

Man erkennt nicht viel, aber das Diagramm sieht gut aus, und ich denke, daß sich damit bestimmt was anfangen lässt. Ich habe schon weiter oben gelesen daß Bausteinaufrufe ein Problem sein sollten.
Das heißt also, wenn ein bestimmter Quellcode gegeben ist, angenommen ich übersetze den mit verschiedenen Compilerversionen und vergleiche nachher die Cheksummen - gibt es dann Differenzen ?
Die Frage ist, ob ich dann überhaupt diese 100% Übereinstimmung in der Prüfsumme brauche, wenn das sogar je nach Compiler unterschiedlich ist.

 

[Thomas_v2.1]

Ja, scheint zu groß. Ich habe noch ein einfacheres Beispiel.
AWL-Input ist

      SET   
      SAVE  
      =     L      4.1
      L     1
      T     #x
      L     100
      T     #i
A7d0: L     #i
      L     0
      >I    
      SPBN  A7d1
      L     #i
      L     5
      >I    
      SPBN  A7d2
      L     #x
      L     #i
      +I    
      T     #x
      L     #x
      L     10
      >I    
      SPBN  A7d4
      L     0
      T     #x
      SPA   A7d4
A7d2: L     #i
      L     20
      >I    
      SPBN  A7d5
      L     #i
      T     #x
      SPA   A7d4
A7d5: L     1
      T     #x
A7d4: L     #i
      L     1
      -I    
      T     #i
      SPA   A7d0
A7d1: CLR   
      U     L      4.1
      SAVE  
      BE

SCL-Code war

FUNCTION FC201 : VOID

VAR_TEMP
    i : INT;
    x : INT;
END_VAR
BEGIN

x := 1;
i := 100;

WHILE i > 0 DO
    IF i > 5 THEN
        x := x + i;
        IF x > 10 THEN
            x := 0;
        END_IF;
    ELSIF i > 20 THEN
        x := i;
    ELSE
        x := 1;
    END_IF;
    i := i - 1;
END_WHILE;    

END_FUNCTION

Um die Schleifentypen zu erkennen benötigt man etwas Wissen aus der Graphentheorie, dominierende Blöcke usw. Dann gilt es zu erkennen ob und welche die Schleifenvariable ist. Ich weiß gar nicht wie weit ich da war. Glaub ich würde es heute neu schreiben.
Eigentlich ein interessantes Themengebiet, aber z.Zt. habe ich dafür keine Anwendung.

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hm. Also ich habe dafür schon Verwendung, weil ich grundsätzlich da Bedarf sehe, weil wenn die Kunden dann mal vor so einem Problem stehen dann heißt es Software neu entwickeln, obwohl man es möglicherweise vermeiden könnte.
Zu obigem Diagramm: die IF-Abfragen lassen sich recht gut erkennen (... zwei Zustände) beim Zyklus sieht man daß es einer ist, aber nicht welcher. Mir wäre es aber wurscht weil WHILE / FOR / DO-WHILE lassen sich ja gegenseitig ersetzen. Wichtig ist, daß man die Funktionalität beibehält.

So ein Diagramm ist in der Tat eine gute Grundlage.