Step 7 Was bedeutet "U L 4.2" (Aus SCL Baustein)

Betriebselektriker28

Betriebselektriker28

Level-2
Beiträge
658
Reaktionspunkte
80
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich sitze gerade vor einem FB der in SCL programmiert wurde... Keine Ahnung warum,wieso weshalb. Die ganze Anlage ist so programmiert. :sb8:
Quellen gibt's keine.


Was bedeutet es wenn dort steht "U L 4.2"? Also wofür steht das L 4.2?.

Wird scheinbar wie eine Art Zwischenspeicher/Merker verwendet?

scl1.JPG


Danke für eure Hilfe ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Betriebselektriker28 schrieb:
ich sitze gerade vor einem FB der in SCL programmiert wurde... Keine Ahnung warum,wieso weshalb. Die ganze Anlage ist so programmiert. :sb8:
Quellen gibt's keine.
Zum Vergrößern anklicken....

Was spricht für dich gegen SCL ?
Es ist allerdings ganz böse, wenn du einen (oder mehrere) Bausteine hast, die in SCL erstellt worden sind und du hast die Quellen nicht dazu. Je nachdem, was der Baustein macht, kann da die Fehlersuche (oder das Debugging) eine mittlere Katastrophe werden. Ich würde mich an deiner Stelle bemühen, die Quellen zu erhalten ...

Das mit den Lokaldaten hat Michael dir ja schon beantwortet ...

Gruß
Larry
 
@Michael:

Danke für die schnelle Antwort!
Das mit den Lokaldaten hatte ich jetzt schon herausgefunden...ist mir vorher wirklich noch nie bewusst wo untergekommen.:rolleyes:

Natürlich weiß ich das es AWL ist, der Code wurde aber aus SCL generiert. Die Erstellsprache ist ebenfalls SCL.
"generiert vom SCL Übersetzer Version: SCL K5.1.5 (C5.1.9.8)" steht im ersten NW.

@Larry:

Sagen wir so:
Für diese Art Anlage und die Funktionen ist es zumindest völlig unnötig. Fehlersuche und Programmanpassungen werden unnötig erschwert.
Der Schichtelektriker kann das PG sowieso gleich wieder zuklappen.

Alle FB´s/FC´s bestehen aus einem einzigen unübersichtlichen Netzwerk...finde ich jetzt nicht so prickelnd.

Stinknormale Bitverknüpfungen und ein paar Regler über SCL zu programmieren ist schon so richtig unnötig.
Das Projekt hat gerade mal 20 Bausteine und läuft auf einer 313C CPU...AWL,KOP,FUP hätts imho auch getan.
ALLE Bausteine inklusive OB1 sind in SCL erstellt worden!

Will da jetzt aber keine Grundsatzdiskussion anzetteln. ;)


Quelle gibt es leider keine einzige, eventuell kann man sie vom Hersteller noch bekommen, mal sehen. Ich rechne aber nicht wirklich damit.

Zum Schluss nochmal ein Beispiel warum ich SCL nicht mag.
Das muss doch nicht so aussehen: :eek:

scl2.JPG
 
Trotzdem, in meinen Augen, abenteuerlich bis wirr.
Code: 
Lade
Lade
= xy
gibt für mich keinen Sinn
dann
Code: 
Lade  32511
Vergleiche
....
....
....
Lade  -4864
Vergleiche
......
=  xyz_SF
Soll das SF vielleicht für SammelFehler stehen
Mir kommt das vor wie Drahtbruchüberwachung Temperaturfühler
Aber wenn da funzt wäre das Zufall weil das besagte L(okaldaten) 4.2 nicht sauber zugewiesen wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Paul:

Ja, das soll wohl die Drahtbruchüberwachung sein, hab mich auch schon kurz gewundert dass das funktioniert... :ROFLMAO:

Einmal auf Kurzschluss und einmal auf Drahtbruch. Aber die Reihenfolge der Anweisungen ist echt seltsam.


Ich denke das bei der Umwandlung aus dem SCL solch wirre AWL Codes werden. Das würde doch kein Mensch so programmieren. :confused:
 
Zuletzt bearbeitet:
Zum Schluss nochmal ein Beispiel warum ich SCL nicht mag.
Das muss doch nicht so aussehen: :eek:

Zum Vergrößern anklicken....

Hallo Betriebselektriker,

das Bild, dass du angehängt hast entspricht nicht SCL. Das ist alles AWL. Dein Problem sind die fehlenden Quellen.
Wurden die Quellen entfernt, so wird der SCL Baustein in AWL angezeigt.

Hier mal ein Beispiel:

Quelle noch vorhanden, Doppelklick auf den FB6 ( SCL )
MitQuelle.jpg

Jetzt die Quelle entfernt und noch einmal einen Doppelklick auf den FB6:
OhneQuelle.jpg
 
Also ich würde das neu machen
So wie es da steht ist es Quatsch.
Und falls sich da ein "Supercrack" ein Denkmal gesetzt hat und es tatsächlich einen Sinn hat....
dann hat es trotzdem nichts in einem Programm zu suchen, weil nicht nachvollziehbar
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@DeltaMikeAir:

Gut dann korrigiere ich mich:

Ich mag den AWL Code nicht der aus einer SQL Quelle entsteht. ;)

Áber der AWL Code ist doch das womit die CPU dann arbeitet, oder sehe ich das falsch?
Also es ist das was in die CPU geladen wird, oder täusche ich mich?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@DeltaMikeAir

Das passiert dann wohl beim "übersetzen"...
Und wenn ich das Programm aus der CPU lade wandelt der Programmeditor die ganze Sache wieder zurück?
Warum dann nicht auch gleich in SCL? :rolleyes:

P.s.:
Mir war schon irgendwie klar der Code in der CPU etwas anders aussieht. So mit ganz vielen 0 und 1 :ROFLMAO:


Man lernt wirklich nie aus...:sb8:
 
Paul schrieb:
Trotzdem, in meinen Augen, abenteuerlich bis wirr.
Code: 
Lade
Lade
= xy
gibt für mich keinen Sinn
Zum Vergrößern anklicken....
Betriebselektriker28 schrieb:
Ja, das soll wohl die Drahtbruchüberwachung sein, hab mich auch schon kurz gewundert dass das funktioniert... :ROFLMAO:

Einmal auf Kurzschluss und einmal auf Drahtbruch. Aber die Reihenfolge der Anweisungen ist echt seltsam.
Zum Vergrößern anklicken....
Eine Spezialität des Siemens-SCL-Compilers ist, daß er kaum optimiert und nicht vorausschaut und immer erst im letzten Moment merkt, wenn er Zwischenergebnisse speichern muß. Dadurch sieht der erzeugte AWL-Code so verwirrend und planlos aus, da ist das Speichern des Zwischenergebnisses oft einige Anweisungen später als die Erzeugung des Zwischenergebnisses. Sehr schön zu sehen in dem Bild in #1:
Code: 
[COLOR="#0000FF"]L  "3009B81"  //PEW266
L  -4864
<I            //Vergleichsergebnis ins VKE[/COLOR]
L  [COLOR="#FF0000"]"3009B81"  //PEW266 (!Programmierfehler!)[/COLOR]
L  32511
[COLOR="#0000FF"]=  L 4.2      //hier merkt der Compiler, daß er das VKE speichern muß für OR-Verknüpfung[/COLOR]
>I            //hier ist der zweite Vergleich    (PEW > 32511)
O  L 4.2      //OR Ergebnis vom ersten Vergleich (PEW < -4864)
=  #TT81_SF
Die Zuweisungen "= L 4.2" gehören eigentlich immer 2 Zeilen höher direkt nach das "<I". Weil aber die beiden Lade-Anweisungen dazwischen das VKE nicht verändern funktioniert der Code trotzdem auch so "verschoben".

Der SCL-Quellcode für das obige AWL-Kompilat sah vermutlich so aus:
Code: 
#TT81_SF := ("3009B81" < -4864) OR ("3009B81" > 32511);


Allerdings sind da auch noch systematische Fehler im Programm, für die der SCL-Compiler nichts kann, sondern die der "tolle" SCL-Programmierer so im SCL-Quelltext geschrieben hat: man darf nicht mehrmals nacheinander das PEW abfragen um es mehrmals zu verarbeiten, weil es sich bei der zweiten Abfrage zur ersten Abfrage geändert haben kann. Man muß sich eigentlich ein eigenes "Prozessabbild" des PEW machen, indem man das PEW zunächst auf eine (lokale) Variable umkopiert und danach kann man den Wert der Kopie so oft verarbeiten wie man will.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Eine Spezialität des Siemens-SCL-Compilers ist, daß er kaum optimiert und nicht vorausschaut und immer erst im letzten Moment merkt, wenn er Zwischenergebnisse speichern muß.
Zum Vergrößern anklicken....

Also wenn es eine Wahl zum Satz des Jahres gäbe, das wäre der heisseste Favorit!

Harald, that made my day!
Thanks!
 
borromeus schrieb:
Also wenn es eine Wahl zum Satz des Jahres gäbe, das wäre der heisseste Favorit!
Zum Vergrößern anklicken....

Naja, der erzeugte Code ist nicht primär dafür da angesehen zu werden, sondern um zu funktionieren. Und das tut er. Es schreibt keiner einen Compiler damit der erzeugte Code möglichst gut menschenlesbar ist.
Außerdem weiß man nicht die Hintergründe, vielleicht hat das auch Vorteile bei der Abarbeitung in der CPU oder beim Beobachten eines SCL-Bausteins.
 
Man kann auch nicht jeden Code den der SCL Compiler ausgibt wieder als AWL bearbeiten und in die CPU laden. Besonders bei Bausteinaufrufen kann der SCL compiler Code erzeugen, den man mit dem AWL Editor nicht darstellen und wieder in die CPU laden kann.
D.h. es gibt MC7 Anweisungen welche nicht in AWL umgesetzt werden können!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie auch immer ... man kann das so und so hindrehen.
Fakt ist, dass der TE um überhaupt weiterkommen zu können, den SCL-Quellcode (also die SCL-Quellen) braucht.
Ein SCL-Baustein ohne die Quellen ist schon "ein bißchen" so etwas wie ein Kopierschutz (oder Know-How-Protect).

@TE:
Du solltest also versuchen, bei dem Lieferanden deiner Steuerung diesen zu erhalten. Wenn es im Guten nicht geht dann ggf. mit "etwas" Druck. So hast du eigentlich gar keine Chance. Es werden zwar auch SCL-Passagen vom Compiler so übersetzt das richtig toller AWL-Code dabei herauskommt - das ist aber eher seltener der Fall. Den SCL-Code aus dem AWL-Code zu refactorn halte ich für Unsinn - da wäre dann tatsächlich Neuschreiben schon der bessere Ansatz.

Gruß
Larry
 
Könnte es sein, daß es sich um ein "Lizenzproblem" handelt? Auf den "Vor-Ort Panels" zwar S7 aber ohne SCL installiert? Dann kommt beim Öffnen des Projekts natürlich "Fehlendes Paket SCL blabla ..." Das können manche Kunden nicht ertragen, obwohl sie SCL als Programmiersprache zugelassen haben. Dann SCL Quelle weg und reorganisieren und man bekommt den "schönen AWL Code" und keine Meldung mehr. Den AWL Code des SCL Compilers zu verstehen ... hmmm. Kannst Du Assembler?
Versuche die SCL-Quellen zu erhalten, die gibt es 100% noch! Druck machen wie schon von Larry erwähnt, ich habe die Quellen von vor 10 Jahren auch noch immer (natürlich inoffiziell).
Ansonsten neu schreiben in der Sprache "Deines Vertrauens" wie schon #18 gesagt.
 
Vielen Dank für eure Unterstützung, nach mehreren Anfragen gabs dann doch noch irgendwann das Originalprogramm vom Hersteller.
Leider musste ich zwischendurch mit dem alten Projekt eine CP343-Lean einbinden. Also war dann natürlich die Hardwarekonfig vom Original nicht mehr aktuell.

Also wollte ich unser Projekt "reparieren" so das alles wieder in SCL angezeigt werden kann.
Die Datenquellen ins Programm einfügen hat interessanterweise nicht gereicht, ein komplettes übersetzen der Quellen führte zu Unterschieden in Schnittstelle und Code Offline/online.
Bausteine aus dem Originalprogramm kopieren/einfügen geht auch nicht. (wird dann wieder als AWL angezeigt)

Was dann funktioniert hat: Kompletten Programmordner aus unserem Projekt löschen und den aus dem Originalprojekt einfügen.
Jetzt ist alles Offline/Online gleich und lässt sich auch als SCL öffnen und beobachten.

Für alle die sich fragen wie der Codeschnipsel tatsächlich in SCL aussieht:

scl3.JPG
 

Similar threads

P
SFB35 InstanzDB: Alarmmeldungen in SCL-Quelle
Antworten
10
Aufrufe
4K
Peetz
P
C
Azubi mit Problem: Normieren - was und warum und ahhh
Antworten
7
Aufrufe
3K
kiestumpe
kiestumpe
Zurück
Oben