Step 7 Ablauffähiger Code

bolle1982

Level-1
Beiträge
4
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich bin neu hier in diesem Forum und würde mich mal kurz vorstellen.
Ich arbeite in der Chemieindustrie im Bereich der Instandhaltung. Zu meinen Haupttätigkeiten gehören neben der Instandhaltung und Optimierung der Anlagen auch der Entwurf neuer Systeme.

Dabei bin ich auf etwas gestoßen was ich mir nicht erklären kann.
Im SCL-Editor gibt es unter Einstellungen-->Compiler die Option "Objektcode erstellen". In der Hilfe steht "mit dieser Option legen sie fest ob sie einen ablauffähigen Objektcode erzeugen wollen oder nicht."
So...wer kann mir erklären wo der Unterschied ist.
Bislang hatte ich diesen Haken nicht gesetzt. Ein Kollege hatte mein notebook in beschlag und hatte diesen Haken gesetzt ohne das ich es wusste. Als ich an meinem Projekt weiterarbeiten wollte und meine SCL-Quelle noch einmal übersetzt habe ohne etwas zu ändern fiel mir auf das die FB auf einmal etwa doppelt so groß war. Logischerweise war jetzt nach einem bausteinvergleich (online/offline) ein Codeunterschied festzustellen.
Also...was konkret unterscheidet jetzt die FB's da ich ja den Quellcode im Editor nicht geändert habe? Das Programm läuft im System schon ein Jahr, also scheint dieser Haken nicht notwendig zu sein.
 
Heißt das wirklich "Objektcode"?
Leider habe ich kein S7 hier, doch es gibt es eine Einstellung, dass für das Debbugen der Code übersetzt wird.
Dadurch wird das Programm ca doppelt so groß.
Das stellt man ein während der Entwicklung, wenn alles läuft ohne diese Option übersetzen und gut ist es.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Im SCL-Editor gibt es unter Einstellungen-->Compiler die Option "Objektcode erstellen". In der Hilfe steht "mit dieser Option legen sie fest ob sie einen ablauffähigen Objektcode erzeugen wollen oder nicht."
So...wer kann mir erklären wo der Unterschied ist.
Hallo Bolle,

wenn der Haken "Objektcode erstellen" gesetzt ist, wird mit dem kompilieren (wenn's fehlerfrei war) der Baustein in dem zugehörigen Baustein-Behälter abgelegt, sprich bei den anderen Bausteinen.
 
@ Bike
Das heist wirklich Objektcode erstellen, und Paule hat wirklich recht, ist der Haken nicht gesetzt wird erst garkein Baustein erstellt. Das wiederum bedeutet das der Haken schon immer gesetzt war sonst hätte ich die Bausteine garnicht generieren können. Die Debug-Info macht ca 10% aus und war angehakt, sonst geht der Onlinestatus nicht. Ich hab mir das ganze Problem noch mal etwas genauer angeschaut. Also wenn ich meine Projektsicherung dearchiviere und sie mit den Online-Bausteinen auf der SPS vergleiche gibt es keinerlei Unterschiede. Ich kann mir auch im SCL-Editor online den Status ansehen. Wenn ich einen Baustein übersetzte ohne das ich in der Quelle etwas ändere wird der Baustein urplötzlich größer und bei einem Bausteinvergleich sind unterschiede im Code.
Ich hbe in der Bausteinkonsistenz mal alle Bausteine übersetzt ohne irgendetwas zu ändern. Dann werden alle Bausteine die in SCL geschrieben wurden größer und der Onlinevergleich zeigt in diesen Bausteinen einen unterschiedlichen Code an.
Hier mal ein kleiner Auszug aus dem Detailvergleich:
SCL-Unterschiede.jpg
Das eigentliche SPS-Projekt wächst nach und nach da ich immer einzelne Anlagenteile in betrieb nehme, an den SCL-Quellen ändere ich aber nichts. Die Bausteine die in SCL geschrieben sind werden in Multiinstanzen aufgerufen, von denen ich beliebig viele Stückweise hinzufüge...
Ich versteh allerdings nicht warum sich dadurch die Bausteingröße und Inhalte ändern...:confused:
 
Register "Compiler" (Einstellungen)

Objektcode erstellen

· Mit dieser Option legen Sie fest, ob Sie einen ablauffähigen Code erzeugen möchten oder nicht. Der Übersetzungvorgang ohne diese Option dient lediglich einer Syntaxprüfung.

also an dieser Einstellung sollte es nicht liegen, dass Dein Baustein doppelt so groß wird...

evtl. sind noch andere Haken anders gesetzt ...

Oder Du hast seit einem Jahr die Änderungen am Quellcode nie in die SPS geschrieben...
Jedenfalls hat der Kollege recht, der Haken muss gesetzt sein.


Gruß.
 
Zuletzt bearbeitet:
Wenn ich einen Baustein übersetzte ohne das ich in der Quelle etwas ändere wird der Baustein urplötzlich größer und bei einem Bausteinvergleich sind unterschiede im Code.
Ich hbe in der Bausteinkonsistenz mal alle Bausteine übersetzt ohne irgendetwas zu ändern. Dann werden alle Bausteine die in SCL geschrieben wurden größer und der Onlinevergleich zeigt in diesen Bausteinen einen unterschiedlichen Code an.
:

Wenn dem so ist, dann bist du über Versionsgrenzen von BigS gesprungen.
Soweit ich mir erinnere ist zwischen 5.2 und 5.3 einiges anders geworden, dadurch wird der MC7 Code größer und du kannst nicht mehr ohne Probleme vergleichen.

Mit Debbug Informationen werden die Bausteine größer, daher meine Vermutung zuerst.
Da mussten wir die Bausteine überschreiben, in der Hoffnung, dass es funktioniert. :)


bike
 
Also das Problem entsteht tatsache bei setzten der Feldgrenzenüberwachung... danke Erich

Hätte ich nicht gedacht das dass gleich die Bausteingröße verdoppelt...Also ich geb mein Notebook vorerst nicht mehr weg...so eine Aufregung wegen einer verstellten Compilereinstellung.
Danke erstmal an alle Beteiligten...



Bolle
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sieht so aus, als hättest Du früher das Häkchen bei "Feldgenzen überwachen" nicht gesetzt, aber jetzt schon.

Also das Problem entsteht tatsache bei setzten der Feldgrenzenüberwachung... danke Erich
Hätte ich nicht gedacht das dass gleich die Bausteingröße verdoppelt...Also ich geb mein Notebook vorerst nicht mehr weg...so eine Aufregung wegen einer verstellten Compilereinstellung.

Daher kommt auch die unsinnige Behauptung SCL wäre gegenüber AWL uneffektiv weil der Code größer ist. (klar, wenn man im AWL zu faul ist die Grenzen manuell zu checken dann ist der Code kürzer ;-) )

Mache mal bitte den Versuch und erstelle einen SCL-Baustein OHNE und eine MIT Feldgrenzenüberwachung.
Dann Verschiebst du die SCL-Quelle so, das bei Öffnen der SCL-Bausteine keine SCL-Quelle mehr gefunden werden kann.

Wenn du dir jetzt die bei SCL-nach-AWL-übersetzen Bausteine ansiehst wird du sehen, vor ARRAY-Zugriffen die beteiligten Zeigervariablen auf Sinnfälligkeit (also Feldgrenze) Überwachung sind,
aber nur der Variante "MIT Feldgrenzenüberwachung". Der eigentlich relevante Code ist in beiden Fällen nahezu gleich. Maximal wurden noch Zwischenmerker eingefügt.

Frank
 
...Dann Verschiebst du die SCL-Quelle so, das bei Öffnen der SCL-Bausteine keine SCL-Quelle mehr gefunden werden kann.

Wenn du dir jetzt die bei SCL-nach-AWL-übersetzen Bausteine ansiehst wird du sehen...
Den erzeugten AWL-Code kann man auch ohne Umbenennen oder Verschieben der SCL-Quelle sehen.
Einfach den KOP/FUP/AWL-Editor starten und von dort aus den Baustein öffnen.
Gruß
Erich
 
also das jemand behauptet dass AWL effektiver als SCL sein soll, kann ich nicht nachvollziehen.
Allein schon die Tatsache sich in fremde AWL-Codes reinzudenken...Ich habe zwar noch nicht so viel mit SCL gemacht, aber ich find's einfach klasse.
8)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
also das jemand behauptet dass AWL effektiver als SCL sein soll, kann ich nicht nachvollziehen.
Allein schon die Tatsache sich in fremde AWL-Codes reinzudenken...Ich habe zwar noch nicht so viel mit SCL gemacht, aber ich find's einfach klasse.
8)

Meiner Meinung nach ist nicht effektiver ...obwohl man damit einige Sachen schneller laufen lasen kann !
AWL ist fast M7 Code also ist SCL auf abstraktere Ebene lauter fix vorgegeben AWL Routinen (die aber nicht für JEDE denkbare Aufgabe zeitoptimiert sind ).
Aber wenn eine "AWL Routine"/ M7 Routine in SCL nicht änderbar ist ... oder gar nicht gibt ... in AWL kann man sie optimiert schreiben .
;)

Es gibt aber "Sachen" die man auch mit AWL nicht schneller machen könnte .... obwohl es manchmal schreklich ist was für und wie viele POINTER und Merker sich unter der SCL "Haube" verstecken , SPAGHETTI CODE auch :p ! (übrigens obwohl schlecht lesbar ist "guter" Spaghettikode das schnellse was gibt )

Manche Routinen kann man in ASSEMBLER auch nicht schneller machen als in C !
 
Zuletzt bearbeitet:
also das jemand behauptet dass AWL effektiver als SCL sein soll, kann ich nicht nachvollziehen.
Allein schon die Tatsache sich in fremde AWL-Codes reinzudenken...Ich habe zwar noch nicht so viel mit SCL gemacht, aber ich find's einfach klasse.

Die Zyklus-Effektivität des Codes spielt IMHO in der heutigen CPU Technik keine soo grosse Rolle mehr. Oder wann konntet ihr das letzte Mal ein Band wegen der SPS nicht mehr schneller laufen lassen und nicht wegen der Mechanik?
Früher hat Optimieren um jeden Preis noch ab und zu Sinn gemacht um eine Fertigungsstrasse noch an die Mechanische Grenze zu fahren, heute ist das aber wohl nur noch sehr sehr selten der Fall.

Und ich bin deiner Meinung in vielen Fällen ist SCL übersichtlicher aufzubauen als AWL. Allerdings die Debuging Funktion in Step7 lässt leider vor allem in schon laufenden Programmen mit Multiinstanzen kein Onlinebetrachten von FBs zu was das Testen und Fehlerbeheben wesentlich aufwändiger macht als dies in AWL der Fall ist.

mfG René
 
Mit der PERIPHERIE muss man schon schnell rechnen ... also AWL ist hier effektiver !
René hast du mal ein Regler mit SCL geschrieben ?
;)

DIGITALTECHNIK = AWL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit der PERIPHERIE muss man schon schnell rechnen ... also AWL ist hier effektiver !

Bei Siemens ist SCL AWL. Wird dazu compiliert und das nichtmal schlecht.
Ebenfalls kann man SCL optimal und suboptimal programmieren was den daraus entstehenden AWL Code ebenfalls optimal oder weniger optimal rauswirft.

Bei welcher Peripherie muss man schnell rechnen?

René hast du mal ein Regler mit SCL geschrieben ?
;)

Hab ich.
 
Mit der PERIPHERIE muss man schon schnell rechnen ... also AWL ist hier effektiver !
René hast du mal ein Regler mit SCL geschrieben ?
;)

DIGITALTECHNIK = AWL

Schwachsinn ...
Mit deinen Fähigkeiten bist du ganz sicher nicht in der Lage schnelleren AWL-Code zu schreiben als ich in SCL
Wenn ich mir den vom SCL-Compiler erzeugten Code anschaue, dann muß man schon tiefer in die Trickkiste greifen um schneller zu sein.

Dieter
 
Mit der PERIPHERIE muss man schon schnell rechnen ... also AWL ist hier effektiver !
René hast du mal ein Regler mit SCL geschrieben ?
;)

DIGITALTECHNIK = AWL

Mache mal zwei Wochen Pause! - in 10 Tagen 117 Beiträge - :rolleyes: - reflektiere mal dein Tun hier und denke auch daran das man seinen selbst geschriebenen Käse auch noch in 5 Jahren hier lesen muss :ROFLMAO:
 
Zurück
Oben