Der Applikationscode bezeichnet den Maschinencode, den eine Steuerung ausführt, wenn Sie eine Applikation starten.
CODESYS erzeugt den Applikationscode aus dem im Entwicklungssystem geschriebenen Quellcode automatisch vor dem Download der Applikation auf die Steuerung. Dabei wird vor dem Erzeugen des Applikationscodes eine Prüfung der Zuweisungen, der Datentypen und der Verfügbarkeit von Bibliotheken durchgeführt. Weiterhin werden beim Erzeugen des Applikationscodes die Speicheradressen vergeben.
Sie können diesen Vorgang auch explizit über den Befehl „Erstellen Code erzeugen“ ausführen. Damit können Sie mögliche Fehler in Ihrem Quellcode finden, auch wenn die Steuerung noch nicht verbunden ist. Die Fehler werden im Meldungsfenster in Kategorie "Übersetzen" ausgegeben.
HINWEIS
Wenn Sie die Applikation verschlüsselt haben, ist Folgendes zu beachten: Wird nach einem Online-Change auf Anfrage eine (neue) Bootapplikation erzeugt, dann wird diese mit dem aktuellen Code im RAM gebildet. dieser Code ist nicht verschlüsselt!
Explizites Erzeugen von Applikationscode
Voraussetzung: Die Applikation lässt sich fehlerfrei übersetzen.
-
Wählen Sie den Befehl „Erstellen Code erzeugen“.
Der Applikationscode wird erzeugt. In dem Meldungsfenster werden Detailinformationen zur Speicherbelegung ausgegeben.
Meldungen beim Erzeugen des Applikationscodes
Wenn Sie den Applikationscode erzeugen, gibt CODESYS Informationen zur Speicherbelegung im Meldungsfenster aus. Da aufgrund der inkrementellen Kompilierung der Speicher nur für geänderte und neue Bausteine und Variablen neu vergeben wird, entstehen Lücken im Speicher. Denselben Effekt haben Online-Changes. Diese Fragmentierung verringert den verfügbaren freien Speicher. Sie können in diesem Fall den Speicher mit Hilfe des Befehls „Bereinigen“ komplett neu vergeben und somit den freien Speicher wieder vergrößern.
Syntaxfehler und Fehler, die CODESYS während der Codegenerierung und Speichervergabe feststellt, erscheinen ebenfalls im Meldungsfenster, in Kategorie „Übersetzen“.
Ausgegebene Informationen zur Speicherbelegung:
-
„ Größe des erzeugten Codes“ (in Bytes): Summe aller Codestücke
-
„Größe der globalen Daten“ (in Bytes): Gesamter von den globalen Variablen belegten Speicher. Ein- und Ausgaben werden dabei nicht berücksichtigt, es sei denn, es werden Ein- oder Ausgaben im Bereich der globalen Variablen abgebildet.
-
„Gesamter allozierter Speicherumfang für Code und Daten“ (in Bytes): Der gesamte allozierte Speicher umfaßt die bereits belegten Speicherbereiche plus den reservierten, noch nicht belegten Speicherplatz für inkrementelles Übersetzen und Online-Change. Nach dem ersten Übersetzen entspricht der bereits belegte Speicher in etwa der höchsten verwendeten Adresse (siehe unten). Die größte zusammenhängende Speicherlücke (siehe unten) entspricht noch in etwa der Differenz zum gesamten allozierten Speicherumfang. Mit ansteigender Zahl von inkrementellen Übersetzungsläufen und Online-Changes steigt jedoch auch die Anzahl von Speicherlücken und die größte zusammenhängende Speicherlücke wird kleiner.
-
„Speicherbereich <n>“: Inhalt der einzelnen belegten Speicherbereiche:
Hintergrund: Es hängt von der SPS ab, in welchen Speicherbereichen welche Daten und der Code untergebracht werden. Beispielsweise liegen auf CODESYS Control Win V3 Code und Daten im gleichen Bereich. Für die Adressen
%I,%M,%Qwird immer Speicher reserviert, auch wenn keine Variable einer Adresse zugewiesen ist. Nach einem "Bereinigen" der Applikation wird der Speicher komplett neu vergeben. In diesem Fall kommt es durch das vorgegebene "Alignment" (in der Regel 8) eventuell zu kleinen Lücken. Größere Lücken entstehen bei der Änderung eines Datums ohne "Bereinigen", beispielsweise durch Vergrößern eines Arraybereichs. In diesem Fall werden nur die betroffenen Bausteine neu übersetzt. Und auch im Fall eines Online-Changes wird der Speicher nur für neue Variablen und neuen Code verwendet. Speicher, der zuvor durch gelöschte Variablen und Code belegt war, wird wieder freigegeben. So kann es nach vielen inkrementellen Übersetzungsläufen und Online-Changes zu einer Fragmentierung des Speichers kommen. Es entstehen viele kleine Lücken, die unter Umständen gar nicht mehr genutzt werden können. Damit klar ist, wieviel Speicher sicher zur Verfügung steht, wird bei der Codegenerierung die "größte zusammenhängende Speicherlücke" des Speicherbereichs ausgegeben.-
„Höchste verwendete Adresse“ (Byte) : Dies ist die höchste belegte Adresse im gesamten allozierten Speicherbereich. Beim ersten Kompilieren nach einem "Bereinigen" werden die Speicheradressen unter Berücksichtigung der Ausrichtung (in der Regel 8 Byte) in aufsteigender Reihenfolge an Variablen ausgegeben. Somit entspricht zu diesem Zeitpunkt die höchste verwendete Adresse in etwa dem belegten Speicherumfang. Der Rest des allozierten Speicherbereichs steht noch komplett für inkrementelles Übersetzen und Online-Change zur Verfügung.
-
„Größte zusammenhängende Speicherlücke“ (in Bytes): Dies ist der Speicherumfang, der gesichert zur Verfügung steht.
Entstehende Lücken im allozierten Speicher werden soweit möglich bei weiteren Änderungen wieder verwendet. Wenn beispielsweise eine globale Variable vom Typ
Bytehinzugefügt wird, wird sie im ersten freien Byte des Speichers platziert. Dafür genügt also eine kleine Lücke. Aber: Eine FB-Instanz, eine Variable vom Typ Struktur oder Array, oder der Code für einen Baustein müssen zusammenhängend gespeichert werden und belegen daher entsprechend mehr Speicher. Sie können somit nur dem größten zusammenhängenden Speicherbereich zugeordnet werden. Und deshalb wird bei der Codegenerierung die als sicher zur Verfügung stehende "größte zusammenhängende Speicherlücke" ausgegeben (in Bytes), außerdem ihr prozentualer Anteil am Gesamtspeicher.
-
Beachten Sie hierzu auch die Optionen zur Applikationserzeugung.
Verschlüsselung des Applikationscodes
Siehe auch