Step 7 Step 7 5.6 SCL Bausteine werden nur im KOP/FUP/AWL Editor geöffnet.

Ok bedenkenlos 😁

Habe noch ein paar ältere Projekt, das ist der Baustein gleich SCL / AWL.
Das Projekt das ich die Tage bekommen habe, hat unterschiede.
Die Einstellungen in "meinem" Compiler sind alle Siemens Standard, habe ich nichts geändert.
Wir haben hier 256 SCL Bausteine, mit unterschiedlichen Einstellungen könnte man also die ganze Anlage abschießen!?

Haben den Baustein online geöffnet, da zeigt er mir den gleichen SCL Code an, also ist das dann vom offline Baustein?
SCL ist doch etwas verwirrend :)
SCL Code alles ok, vergleich als AWL, Aufgrund unterschiedlicher Einstellungen im Compiler, kompl. anders.
Da ist AWL doch wieder schöner, im online/offline Vergleich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir haben hier 256 SCL Bausteine, mit unterschiedlichen Einstellungen könnte man also die ganze Anlage abschießen!?
wenn Du Pech hast, ja. Wenn Du Glück hast, nein. Was sagt denn Dein Horoskop für heute?
Haben den Baustein online geöffnet, da zeigt er mir den gleichen SCL Code an, also ist das dann vom offline Baustein?
ja, wenn Du Online den Baustein öffnest, macht der Editor den Offline-SCL-Quellcode aus dem Ordner "Quellen" auf. Aber nur, wenn die Quellen niemand aus "Kopierschutzgründen" gelöscht hat.

Blöd, wenn die Quellen jemand gelöscht hat und später ältere Quellen wieder reinkopiert hat, ohne danach zu übersetzen...

Vielleicht kommt man mit Zeitstempeln der Sache näher...

Aber es ist wie immer, man muss schon im Detail wissen was man tut und zusätzlich noch beten, dass kein anderer Quatsch macht.

Kannst Du den SCL-Code online beobachten? Dann sollte der (eigentlich) passen.
 
Zuletzt bearbeitet:
Guten Abend,

keine Ahnung was in meinem Horoskop steht, lese seit Jahren keine Bild mehr :LOL:

Die Quellen habe ich, habe den Baustein auch schon neu erstellt, er ist immer anders als online.
Habe verschiedene Einstellungen des Compiliers probiert, ich bekomme den offline Baustein, nicht gleich wie online.

Einen anderen Weg, als über die Quellen gibt es nicht, den FC zu erstellen?
Den FC aus einem alten Projekt rüber kopieren geht ja nicht.
Den AWL Code anpassen und im Projekt speichern geht auch nicht, beim Speichern/Laden wird die Sprache geändert... danach kann man den Baustein nur noch in AWL öffnen, nicht mehr mit SCL, wie im Beitrag #1.

Kannst Du den SCL-Code online beobachten? Dann sollte der (eigentlich) passen.

Öffne ich den Baustein und gehe online > Die Zeitstempel des Bausteins off/online sind unterschiedlich. Laden Sie den Baustein neu.
Klar kann ich den Baustein danach beobachten, aber stimmt er dann noch?
Dan habe ich ja den "falschen" Baustein auch online.

Wie bekomme ich denn jetzt raus, was der unterschied ist und wie kann diesen beheben?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie bekomme ich denn jetzt raus, was der unterschied ist und wie kann diesen beheben?
Wenn Du 100% sicher sein willst, garnicht. Du kannst Dir nur den SCL-Code anschauen, wenn Dir nix auffällt reinladen und testen.
Wenn irgendwas nicht funktioniert, Fehler suchen oder im Notfall den vorher gesicherten Baustein wieder einspielen.

Habe noch ein paar ältere Projekt, das ist der Baustein gleich SCL / AWL.
Das Projekt das ich die Tage bekommen habe, hat unterschiede.

Du kannst maximal wenn Du noch viele alte Stände hast, irgendwas altes raussuchen, wo der Zeitstempel von offline-SCL offline-AWL und online-AWL identisch sind, und dann die SCL-Quelle und den AWL-Baustein in Dein aktuelles Projekt rüberkopieren.
Geht aber auch nur, wenns keine Abhängigkeiten zu anderen FC FB DB Variablen etc. gibt...

Falls es Dich tröstet, die Sorgen werden überall bei jedem schlimmer. Es wird überall immer schlampiger gearbeitet, Projekte nicht ordentlich verglichen, nicht ordentlich geladen, nicht ordentlich archiviert.

Haben wir ständig, dass wir keinen 100% passenden Projektstand kriegen.

Was Dich auszeichnet, Du machst Dir Gedanken drüber. Viele andere würden einfach reinladen, was sie gekrigt haben, scheißegal. Wenn die Anlage/Maschine danach nicht mehr läuft, ist man ja nicht selber Schuld.

Nächstes Thema in dem Zusammenhang, richtiges Sichern der richtigen Aktualdaten...

Also ja, Zeit für Rente.
 
Zuletzt bearbeitet:
Ich konnte mit setzen der Häkchen, Debug-Infos und OK-Flag, die Größe auf 148kb bekommen, so wie er online vorhanden ist.
Jetzt ist nur die Prüfsumme anders, der AWL Code passt auch, bis auf ein Wert für L#. Online L#28016 Offline L#29360.

Bei sowas, fange ich dann an den SCL code zu verändern und zu übersetzen um den unterschiedlichen AWL Code im SCL Code zu finden. Damit könntest du das Offline L#29360 finden und den Zusammenhang zum restlichen SCL Code zusammenstellen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit "Der Code muss gleich sein" meinte ich dass der Zeitstempel auch unterschiedlich sein kann ohne dass der Code unterschiedlich sein muss. Aber solange der Code gleich ist, ist der unterschiedliche Zeitstempel nicht relevant für die Funktion.
 
Mit "Der Code muss gleich sein" meinte ich dass der Zeitstempel auch unterschiedlich sein kann ohne dass der Code unterschiedlich sein muss. Aber solange der Code gleich ist, ist der unterschiedliche Zeitstempel nicht relevant für die Funktion.
ja, schon klar, aber wie willst Du das anstellen, wenn der SCL-Compiler einer neuen Step7 Version mit anderen Compilereinstellungen jetzt auf einmal leicht anderen AWL-Code erzeugt? Weil das ist ja scheinbar das Problem von @s.t.a.r.s
 
SCL in Step7 Classic verhält sich ähnlich einer doppelten Datenhaltung, was ein hohes Maß an Selbstdisziplin erfordert. Und dennoch schlägt Murphi bei so einem Konstrukt früher oder später erbarmungslos zu.

Wie sieht es eigentlich diesbezüglich im TIA-Portal aus? Ich selbst habe mit Classic-Steuerungen im TIA nur sehr wenig Erfahrungen. Lediglich ein Projekt mit mehreren Steuerungen und Panels hatte ich in der Übergangszeit aus nachvollziehbaren Kundenwunsch nach V14 migriert. Dass dort keine SCL-Quellen zu sehen sind, fällt mir erst jetzt auf.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,

erstmal danke an alle, jetzt bin ich im Umgang mit SCL etwas "schlauer".
SCL mag schön zum lesen und bearbeiten sein, wenn aber der Maschinecode unterschiedlich wird, dann fangen die Probleme an.
Ich habe selbst noch keine SCL Bausteine geschrieben, bisher immer abgeändert, aber da waren die Bausteine online/offline die gleichen.
Und durch die selbst gemachten Änderungen, weiß man ja was los ist.

Zu dem Projekt, ich habe das jetzt so gemacht....

Zwischen dem Projekt auf meinem Laptop und Online gab es keine Unterschiede. Ich habe jetzt die Änderungen aus dem Projekt, was wir von der Firma zurück bekommen haben, in meinem angepasst.
Die Referenzdaten waren dann unterschiedlich, diese habe ich aktualisiert und alle betroffenen Bausteine, auch die SCL, wurden neu übersetzt.
Dann wieder einen offline/online Vergleich durchgeführt.
Der betroffene Baustein aus meinem ersten Beitrag, war immer noch gleich, dafür waren jetzt fünf andere Fc´s unterschiedlich.
Für die fünf, habe ich in den Compiler Einstellungen mal die Häkchen für "Debug Info erstellen" und "OK Flag setzen" entfernt und übersetzt, Vergleich zeigt nun keine Unterschiede.
Daraus folgere ich, das die fünf Fc´s zu unterschiedlichen Zeiten geändert und immer einzeln mit den "falschen" Einstellungen im Compiler übersetzt, und dann übertragen wurden. Die restlichen 250 Bausteine, wurden mit den beiden Häkchen übersetzt.
Jetzt passt alles, offline wie online, der Zeitstempel hat sich jetzt natürlich geändert.
Ich werde nochmals die fünf FC´s übersetzen, das für alle auch die gleichen Compiler Einstellungen gelten, und übertragen.

Was mit dem ersten FC "falsch" ist, weiß ich nicht.
Ich hatte nochmals verschiedene Einstellungen probiert, aber keine ergibt den gleich Baustein wie online, keine Ahnung wie dieser 2015 übersetzt wurde. Werde mal testen was @vollmi vorgeschlagen hat.

Ok, ich habe jetzt erstmal das fertige Projekt auf dem PC, für den Notfall, da wir die Anlage demnächst zum Netzcheck ausschalten müssen.
Wir haben in der CPU keine Flashkarte, sondern ein extra RAM Modul gesteckt.

Grüße
 
Hallo zusammen.
Weiter oben in eurem thread war die Frage nach einem Beispiel für einen MC7 Baustein, der mit AWL und SCL unterschiedlich generiert wird.
Es scheint das Szenario weiter verbreitet zu sein:

SCL Quelle - compile - MC7(SCL) Baustein - generiere AWL Quelle - übersetze AWL Quelle - MC7(AWL) Baustein.

Dies ist eine gefährliche Vorgehensweise und sollte NICHT praktiziert werden!
Warum? Weil die entstehenden MC7 Bausteine nicht identisch sind, und nur der SCL generierte Baustein korrekt arbeitet!

Gehen wir von folgender SCL Quelle aus:
1753688412334.png


Diese Quelle wird vom SCL Compiler in diesen MC7 Baustein übersetzt:
1753688427292.png

Wenn wir daraus eine AWL Quelle generieren und diese übersetzen entsteht ein im AWL Editor genau gleich aussehender MC7 Baustein.

Wird jedoch der Befehl L P##DB_IN genauer betrachtet fällt folgendes auf:

1753688462639.png

In diesem Status des SCL Bausteins ist sichtbar, dass der Ladebefehl die Nummer des DBs in das Lowwort des Akkus lädt.


1753688493139.png
Hier der Status des AWL generierten Bausteins. Der Ladebefehl lädt die DB Nummer in das Highwort des Akkus. Der nachfolgende Transferbefehl
legt damit einen viel zu großen Wert ab.

Damit ist der SCL generierte FC funktionsfähig!
Der AWL generierte FC ist NICHT funktionsfähig!
Der AWL Editor wird immer den Doppelwort ladenden Befehl erzeugen, während der SCL Compiler den Wort ladenden Befehl erzeugt.
Es entstehen unterschiedliche Bausteine mit unterschiedlicher Funktion!


Dies ist nur ein Beispiel, es gibt weitere.
Daher sollten SCL Bausteine auch immer SCL Baustein bleiben!

have a nice day....
Linus
 
Wird jedoch der Befehl L P##DB_IN genauer betrachtet fällt folgendes auf:

Anhang anzeigen 89548

In diesem Status des SCL Bausteins ist sichtbar, dass der Ladebefehl die Nummer des DBs in das Lowwort des Akkus lädt.
Der vom SCL Compiler erzeugte MC7 Code wird bei Betrachten als AWL Code falsch dargestellt. L P##DB_IN ist falsch und bedeutet was anderes: das lädt die Adresse des Übergabeparameters #DB_IN bzw. in FC die Adresse der außen angeschalteten Variable in AKKU1. Da könnte aber auch eine Konstante verschaltet sein, deshalb ist da vermutlich so ein spezielles FC-Getrickse, um den Wert vom Übergabestack zu holen, was im AWL-Editor wohl nicht darstellbar ist.

Der zu verwendende AWL-Befehl müsste heißen L #DB_IN - der ist für BLOCK_DB aber nicht erlaubt.
In FB ist L #DB_IN für BLOCK_DB ebenfalls nicht erlaubt, da kann der übergebene Wert aber indirekt aus dem IDB gelesen werden: L DIW [AR2,P#0.0]

FC10 von SCL 56 Byte, L P##DB_IN = 2 Byte lang
FC10 von AWL 58 Byte, L P##DB_IN = 4 Byte lang, "Code ist unterschiedlich" zu SCL-FC10

(Parametertyp BLOCK_DB = 2 Byte lang)


Hier der Status des AWL generierten Bausteins. Der Ladebefehl lädt die DB Nummer in das Highwort des Akkus. Der nachfolgende Transferbefehl
legt damit einen viel zu großen Wert ab.
Nein, der Transferbefehl schreibt 0 in #DB_OUT, weil #DB_OUT vom Datentyp WORD ist. (das ändert aber nicht das Problem)
Beachte: AWL-Code-Beobachten zeigt den Inhalt der Akkus, nicht den Inhalt von Variablen. Wenn man wissen will, welcher Wert in eine Variable geschrieben wurde, dann muss man danach die Variable einlesen (L #Variable).


Damit ist der SCL generierte FC funktionsfähig!
Der AWL generierte FC ist NICHT funktionsfähig!
(...)
Es entstehen unterschiedliche Bausteine mit unterschiedlicher Funktion!
(...)
Daher sollten SCL Bausteine auch immer SCL Baustein bleiben!
das ist korrekt
 
Zuletzt bearbeitet:
Zurück
Oben