# AWL nach SCL convertieren



## Anonymous (9 Februar 2006)

*Hallo*

ich möchte bereits in *AWL* geschriebene Funktionen aus einem Step7 Projekt jetzt in ein PCS7 Projekt einbinden. Dabei möchte ich aber nicht die Bausteine so verwenden, sondern die Funktionen in *SCL * konvertieren, um anschließend diese mit Erweiterungen zu modifizieren.
Gefunden habe ich nur eine Möglichkeit der Generation von AWL Quellen, die sehen aber wieder anders aus, als die SCL Quellen. 
*Gibt es eine Möglichkeit die SCL Quelle aus AWL zu erzeugen, ohne sich die Finger wund zu tippen  :?: *

Danke schon mal!


----------



## Ralle (9 Februar 2006)

Da gibt es meines Wissens nach keine Möglichkeit. SCL ist eine "Hochsprache" und wird von einem Compiler in AWL-Code umgesetzt.


----------



## Barnee (9 Februar 2006)

Ralle schrieb:
			
		

> ...und wird von einem Compiler in AWL-Code umgesetzt.



Hi Ralle

Das kann ich auf grund meiner neuesten Erkenntnisse so nicht stehen lassen. Der SCL-Compiler erzeugt MC7-Code und nicht AWL-Text-Code.

Mir ist das in der letzten Woche aufgefallen, als ich eine in SCL geschriebene Funktion im AWL-Editor nachbearbeiten wollte. Siemens verwendet da beim SCL-Compiler nicht veröffentlichten Code und Methoden, der bzw. die vom AWL-Editor nicht erkannt werden. Z.B. kann es passieren, das bei der Einbindung von SFC-Bausteinen, der SCL-Compiler das nicht mit einem normalen "CALL" übersetzt, sondern er setzt den Befehl "UC" ein! Obwohl "UC" entsprechend Siemens nur für parameterlose Funktionen angewendet werden sollte! Der SCL-Compiler fügt Code ein, mit dem er zunächst das Adressregister "AR1" sichert. Die Parameter, die z.B. einer SFC-Funktion übergeben werden müssen, wandelt der SCL-Compiler in Ladebefehle um, die vor der Ausführung die Werte in eine bestimmten Bereich der Lokaldaten ablegen. Dann folgte eine Veränderung des Adressregister "AR1" mit einem Offset, der spannenderweise der Adresse der Lokaldaten entspricht, an denen zuvor die Parameter abgelegt wurden. Schlussendlich folgt der Sprung in die SFC-Funktion mit "UC". Bis jetzt habe ich aber (mangels Zeit) noch nicht heraus gefunden, wie die Rückgabe von Parameter erfolgt. Das ist die eine Geschichte.

Etwas unangenehmer ist die Tatsache, das offensichtlich vom SCL-Comiler hin und wieder auch mal nicht veröffentlichter MC7-Code eingebaut wird. Wenn solcher Code vorhanden ist, dann scheitert jeder Versuch, den Baustein in AWL nachzubearbeiten.



			
				wiebke schrieb:
			
		

> *Hallo*
> 
> ich möchte bereits in *AWL* geschriebene Funktionen aus einem Step7 Projekt jetzt in ein PCS7 Projekt einbinden. Dabei möchte ich aber nicht die Bausteine so verwenden, sondern die Funktionen in *SCL * konvertieren, um anschließend diese mit Erweiterungen zu modifizieren.
> Gefunden habe ich nur eine Möglichkeit der Generation von AWL Quellen, die sehen aber wieder anders aus, als die SCL Quellen.
> ...



Hi wiebke

Ich würde dir empfehlen, die in AWL geschriebenen Bausteine so zu belassen wie sie sind. SCL kann schon gar nicht alles, was man in AWL ggf. so alles machen kann. Sofern notwendig, kann man die AWL-Bausteine auch im AWL-Editor PCS7-like anpassen, das ist zwar etwas mühsamer als in SCL, aber es geht.

Ich beschäftige mich zur Zeit mit einem Projekt, um für die S7 einen C-Compiler zu bauen. Dazu haben sich einige Leute hier aus dem Forum zusammengefunden, die Sache gedeiht. Aber es wird noch ein lange Weg sein, bis das eine runde Sache ist. Die Idee mit dem C-Compiler für S7 ist bei mir deswegen entstanden, weil SCL eigentlich nur eine magere Sache ist und den AWL-Befehlsvorrat nicht ausschöpft.

Gruß Barnee


----------



## Ralle (10 Februar 2006)

Danke Barnee, das mit den Rückgabewerten intressiert mich auch, wenn du was herausfindest laß es mich bitte wissen. So umfangreiche SCL-Funktionen schreib ich meistens nicht, bis jetzt konnte ich alles in AWL lesen  8) .


----------



## Anonymous (10 Februar 2006)

@Barnee

Hallo

Es gibt in MC7 keinen CALL!!  Das ist nur die Umschreibung für das Aufbereiten von Parametern und dann UC FC/FB + einem SPA und  die Parameterpointliste im Falle eines FCs.

Kann man sich auch bei jedem normalen AWL Baustein ansehen, wenn man aus dem Projekt den aufgerufenen Baustein entfernt und dann den aufrufenden Baustein im Editor öffnet. Es kommt dann eine Fehlermeldung und man sieht den ganzen "Call"! Und bei einem komplexen Parameterlisting kommt da  einiges zusammen!!!! Allerdings zeigt der Editor den SPA nicht an! Aber den sieht man ja im .wld File.


Gruß


----------



## Josef (10 Februar 2006)

Barnee schrieb:
			
		

> Ich beschäftige mich zur Zeit mit einem Projekt, um für die S7 einen C-Compiler zu bauen. Dazu haben sich einige Leute hier aus dem Forum zusammengefunden, die Sache gedeiht.



Etwas ähnliches hatte ich auch mal vor, MC5 code in AWL oder C Kode
zu Übersetzen. Allerdings als ich mich dann mit Hashing und Symboll-
tabellen beschäftigt habe, sah ich das ich dazu noch nicht in der Lage bin.

Aber euer Projekt würde mich denoch interessieren um in dem Quellcode
zur Übung zu lesen.

Habt ihr schon irgendwo ein Projekt angelegt?

cu
Josef


----------



## Mtroniker (20 Juni 2008)

@ Josef


Josef schrieb:


> Habt ihr schon irgendwo ein Projekt angelegt?



Ein Projekt wurde nicht Angelegt.

Kannst mir ja einmal genauer beschreiben, was Du gerne möchtest, da ich nicht genau verstanden habe, was Du genau willst. Dann kann ich mal gucken, was ich machen kann. der Volker hatte ein paar posts vorher auch etwas nützliches zum Download bereitgestellt. vielleicht hilft dir das weiter.

________
Gruß
Micha


----------



## gravieren (21 Juni 2008)

Ich habe schon einigen Code von AWL in SCL übersetzt.


Ebenso "AWL-Code von SCL-Compiler"  in SCL-Code übersetzt.


Ein Vergleich mit beiden erzeugten AWL-Code war exakt möglich.

Lediglich konnte der Befehl "TAK" bereitet beim vergleich Probleme.
(In der Aufrufreihenfolge, Unterschiede bei Berechnung Reihenfolge,
mal mit mal OHNE "TAK" wobei das Ergebnis identisch ist)

Wenn mann die Version und SP identisch hat, wird auch das Ergebnis gleich.


Ich dachte schon mal an ein Schreiben eines "Wandlers", jedoch ist das ziemlich umfangreich.
(Z.b. Schachtelung mehrerer IF / ELSE Befehle)


Dadurch, dass ich den Auftrag für die "Nachbearbeitung" / "Zurückführung" auf den SCL-Code nicht bekommen hatte (Kunde hat die meisten SCL-Quellcodes verloren) ist das Projekt nach 5 Bausteinen "gestorben"

(Vieleicht habe ich zuviel verlangt  , die dachten so an 5 Euro pro Baustein)


----------



## Larry Laffer (21 Juni 2008)

Barnee schrieb:


> Hi wiebke
> Ich würde dir empfehlen, die in AWL geschriebenen Bausteine so zu belassen wie sie sind. SCL kann schon gar nicht alles, was man in AWL ggf. so alles machen kann.


 
... und in Anlehnung an den Beitrag von Gravieren:

Blödsinn ...
Ich habe bisher keine Funktion aus AWL gefunden, die ich nicht in SCL hätte nachstellen können. Ich muß hier allerdings zugeben, dass es einem bei machen Befehlen nicht ganz leicht gemacht wird (z.B. TAK). Dafür gibt es aber dann auch wieder Funktionalitäten, die sich in SCL um vieles leichter und komfortabler machen lassen, wie in AWL (und sie funktionieren i.d.R. auch gleich). Beispiel hier : Schleifen-Operationen oder umfangreichere Berechnungen.

Gruß
LL


----------



## kermit (22 Juni 2008)

mal abgesehen davon, dass dieser Thread eigentlich schon uralt ist ...

für die, die gerne AWL in SCL übersetzen möchten:

```
L Zaehler
L Weiterzaehlweite
+I
SPO M001
T Zaehler
M001: NOP 0
```
 
oder
	
	



```
L Alter_Wert
L Neuer_Wert
T Alter_Wert
TAK
-I
T Differenz
```


----------



## gravieren (22 Juni 2008)

Gíbt bestimmt WIEDER kein Geld dafür  


OHNE mache ich es NICHT


----------



## zotos (22 Juni 2008)

kermit schrieb:


> ```
> L Alter_Wert
> L Neuer_Wert
> T Alter_Wert
> ...





```
Differenz := Alter_Wert - Neuer_Wert;
Alter_Wert := Neuer_Wert;
```

Zu dem "SPO" da musste ich erst mal nachlesen was das ist. Das wird schon schwer zu übersetzen.


----------



## gravieren (22 Juni 2008)

> Code:
> Differenz := Alter_Wert - Neuer_Wert;
> Alter_Wert := Neuer_Wert;


 
Ich würde meinen:

```
Alter_Wert := Neuer_Wert;
Differenz := Alter_Wert - Neuer_Wert;
```
 
Kann mich aber täuschen


----------



## Larry Laffer (22 Juni 2008)

... du hast (ihr habt) den TAK noch vergessen ...!


----------



## gravieren (22 Juni 2008)

@Larry Laffer

Haste recht. Immer der doofe TAK


```
Alter_Wert := Neuer_Wert;
Differenz := Neuer_Wert - Alter_Wert;
```


----------



## zotos (22 Juni 2008)

Ich hab das nicht getestet.
Aber bei gravieren kommt doch wohl immer eine Differenz von Null raus.

Das TAK wechselt doch die Akku Inhalte untereinander. Wo siehst Du da den Unterschied Larry?

Der neue Wert wird von dem alten abgezogen.


----------



## Larry Laffer (22 Juni 2008)

> Wo siehst Du da den Unterschied Larry?


... beim Ergebnis ...

```
Differenz := Neuer_Wert - Alter_Wert ;
Alter_Wert := Neuer_Wert + Alter_Wert ;
```
das wäre meine Variante ...

Variante streichen ... Blödsinn ... ich habe da irgendwo ein "+I" gesehen, das es gar nicht gibt.
Somit ist Karl's Vorschlag richtig (wenn er die Zeilen vertauscht ) ...!


----------



## zotos (22 Juni 2008)

Larry Laffer schrieb:


> ... beim Ergebnis ...
> 
> ```
> Differenz := Neuer_Wert - Alter_Wert ;
> ...



Echt?

Wo siehst Du da eine Addition vom alten und neuen Wert?
Ich bin ja eine AWL Null, aber übersichtlich ist das nicht.


----------



## Larry Laffer (22 Juni 2008)

Ich habe meinen Beitrag noch 2x geändert - wegen falsch hingesehen ...!
#Ist halt Sonntag#


----------



## zotos (22 Juni 2008)

Larry Laffer schrieb:


> ...
> Somit ist Karl's Vorschlag richtig (wenn er die Zeilen vertauscht ) ...!



Quatsch da kommt Null raus!

Wenn ich den alten Wert gleich dem neuen Wert setze brauche ich keine Differenz zu berechnen.


----------



## Larry Laffer (22 Juni 2008)

Hallo ...!
	
	



```
Differenz := Neuer_Wert - Alter_Wert ;
Alter_Wert := Neuer_Wert ;
```
Erst wird die Differenz gebildet ... dann der Wert überschrieben ...


----------



## zotos (22 Juni 2008)

Ich habe das mit dem Zeilen vertauschen zwar zitiert... aber als ich es gelesen hatte war es noch nicht editiert ;o)


----------



## Larry Laffer (22 Juni 2008)

Tut mir leid ... aber als mir auffiel, was ich da geschrieben hatte, wollte ich deshalb keinen neuen Beitrag machen ... 
Lieber dann das Richtige schreiben ...


----------



## gravieren (22 Juni 2008)

L Alter_Wert          Alter_Wert --> Akku 1
L Neuer_Wert        Neuer_Wert --> Akku 1   Alter_Wert --> Akku 2
T Alter_Wert         Akku 1 --> Alter_Wert

Die Anweisung sollte heissen   Alter_Wert := Neuer_Wert (In dieser Reihenfolge)





TAK     Akku 1 und Akku 2 tauschen --> Akku1=Alter_Wert Akku2=Neuer_Wert

-I
T Differenz

Anweisung:    Differenz := Neuer_Wert - ALter_Wert



Oder wo habe ich einen Denkfehler ?


----------



## Larry Laffer (22 Juni 2008)

@Karl:
die Differenz wir von dem alten "Alten Wert" und dem neuen Wert gebildet ...
So habe ich es jedenfalls gesehen ...

@Zotos:
SPO heißt "Springe bei Überlauf" (also bei INT bei 32767) ...
Das wäre auch kein Problem für SCL ...


----------



## zotos (22 Juni 2008)

Larry Laffer schrieb:


> ...
> Lieber dann das Richtige schreiben ...



Dann solle man das auch mal machen: 


```
Differenz := Neuer_Wert - Alter_Wert;
Alter_Wert := Neuer_Wert;
```

Ihr habt ja recht das der alte Wert vom neuen abgezogen wird.

Aber das überschreiben des alten Werts mit dem neuen muss nach die Differenzbildung.


----------



## gravieren (22 Juni 2008)

Wie ist es jetzt richtig  ?

Muss ich erst meinen SCL-Compiler starten   ?


----------



## Larry Laffer (22 Juni 2008)

... jetzt wollte ich gerade was Schlaues schreiben ... aber ich weiß es nun auch nicht mehr ...

@Karl:
raus mit dem SCL-Compiler ...!

Edit:
Ich bleibe bei meiner Variante, weil nur die Sinn machen würde ...


----------



## Larry Laffer (22 Juni 2008)

... die Frage ist natürlich auch noch ...
Macht der Brocken, den uns Kermit hingeworfen hat, so überhaupt Sinn ...?


----------



## gravieren (22 Juni 2008)

```
FUNCTION_BLOCK FB100
VAR
  Differenz  : INT;
  Alter_Wert: INT;
  Neuer_Wert: INT;  
END_VAR
BEGIN
Alter_Wert := Neuer_Wert;
Differenz := Neuer_Wert - Alter_Wert;
END_FUNCTION_BLOCK
```
 

ergibt:


```
L     #Neuer_Wert
      T     #Alter_Wert
      L     #Neuer_Wert
      TAK   
      -I    
      T     #Differenz
```


----------



## Larry Laffer (22 Juni 2008)

... das Beispiel sah aber so aus :
	
	



```
L Alter_Wert
[COLOR=red][B][U][COLOR=magenta]L[/COLOR][/U] [/B]Neuer_Wert[/COLOR]
[COLOR=red][B][U][COLOR=magenta]T[/COLOR][/U][/B] Alter_Wert[/COLOR]
TAK
-I
T Differenz
```
sorry Karl ...


----------



## gravieren (22 Juni 2008)

Stimmt.

Mein SCL erzeugt ihn aber so.


Ich bin der Meinung, das ist der gleiche Code !  ?

Der AWL-Code des SCL-Compilers ist auch irgendwie "lesbarer"/logischer.

(UPS, hoffentlich habe ich hier nicht einen Glaubenskrieg ausgelöst  )


Wenn der Code vorher mit einem SCL-Compiler erzeugt wurde, stimmt das ergebnis. (Codegleich)


----------



## gravieren (22 Juni 2008)

Setzen wir doch mal Werte ein, und wir vergleichen das Ergebnis.


Ich mache es in SCL, du in AWL.


Gib doch mal Werte vor.


----------



## Larry Laffer (22 Juni 2008)

ich habe jetzt mal die Original-Variante und meine Version (Idee) in einen Baustein eingebaut. Meine Version erzeugt natürlich nicht den ursprünglichen Code (ist das nötig ?). Ich spiele das jetzt mal ins PLCSim und sehe mal was heraus kommt. Ach ja, deine Variante packe ich auch mal mit dazu ...

Ich möchte es jetzt auch einfach nur wissen ...


----------



## gravieren (22 Juni 2008)

@Larry Laffer


> Meine Version erzeugt natürlich nicht den ursprünglichen Code (ist das nötig ?).


Nein, es ging um AWL nach SCL und NICHT um Codegleichheit.




> Ich spiele das jetzt mal ins PLCSim und sehe mal was heraus kommt. Ach ja, deine Variante packe ich auch mal mit dazu ...


Schon fertig ?
Bin gespannt wie ein "Flitzebogen"





> Ich möchte es jetzt auch einfach nur wissen ...


Ich auch.   

Sonst kann ich heute NICHT schlafen


----------



## Larry Laffer (22 Juni 2008)

Ergebnis:
*Dein* Werk bringt *das gleiche Ergebnis*, wie der Vorschlag von Kermit. Differenz=0, weil nach Transfer gebildet. Hier ist das Ermitteln der Differenz Unsinn.

Mein Werk funktioniert so, wie es für mich Sinn machen würde - nicht aber wie die Vorgabe ...!


----------



## Larry Laffer (22 Juni 2008)

Ach ja,
hat Spaß gemacht mit Euch (respektive dir, Karl) ...


----------



## Larry Laffer (22 Juni 2008)

... und nochmal falsch gemacht ...
Ich hatte "Alter Wert" und "neuer Wert" oben am Kopf zugewiesen. Das war der Fehler ... somit Korrektur :
*Mein* Werk bringt *das gleiche Ergebnis*, wie der Vorschlag von Kermit. Es sieht aber vom SCL-in-AWL-Code nicht aus wie das Original ...


----------



## kermit (22 Juni 2008)

Larry Laffer schrieb:


> ... die Frage ist natürlich auch noch ...
> Macht der Brocken, den uns Kermit hingeworfen hat, so überhaupt Sinn ...?


 
Hat mich gefreut, Euch einen so vergnüglichen Sonntag-Nachmittag bereitet zu haben.

Zum Sinn meiner Code-Schnipsel: diese kommen recht regelmäßig in meinen Programmen vor. Das mit Alter_Wert und Neuer_Wert habe ich oft, wenn ich z.B. den Bewegungsfortschritt von Drehgebern rechne. Aber z.B. auch, um die Zeitdifferenz zwischen zwei SFC64-Aufrufen zu berechnen. Dadurch, dass ich nur einen Zugriff auf die Datenquelle hab (L Neuer_Wert), brauche ich mir z.B. bei PEW o.dgl. keine Gedanken darüber zu machen, ob sich der Wert zwischenzeitlich geändert haben könnte, wenn ich ihn als Alter_Wert speichere. Wenn also die Übersetzung in SCL dazu führt, dass der "L Neuer_Wert" dann zweimal als Code auftaucht, so habe ich bei einem Operanden im PEW-Bereich ein sporadisches Problem (liebe Grüße an kiestumpe, der gerade in einem anderen Thread so treffend schrieb: "der erfahrene Benutzer weiß, warum").

Der nächste Schritt ist, diesen Zeit- oder Wegfortschritt wieder irgendwo aufzusummieren. Ggf. in mehreren Zählern oder Teilprozessen, um schon mal der Gegenfrage zu begegnen, warum erst Differenzbildung und dann wieder aufsummieren Das ist der Codeschnipsel mit dem SPO-Befehl. IdR. ist es angeraten, den jeweiligen Zähler, sofern er den Endwert erreicht (oder einen Wert kurz davor), dort anzuhalten und den Überlauf nicht zuzulassen.


----------



## Larry Laffer (22 Juni 2008)

@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


----------



## kermit (22 Juni 2008)

Larry Laffer schrieb:


> @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 ...
> ...


 
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 (18 März 2014)

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 (18 März 2014)

joergel schrieb:


> 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 (25 Januar 2015)

Larry Laffer schrieb:


> 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 (25 Januar 2015)

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 (25 Januar 2015)

gravieren schrieb:


> 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 (25 Januar 2015)

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 (25 Januar 2015)

Thomas_v2.1 schrieb:


> 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 (25 Januar 2015)

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 (25 Januar 2015)

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 (25 Januar 2015)

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 (25 Januar 2015)

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.


----------

