TIA Unterschied Ladespeicher/Arbeitsspeicher

[Fragsau]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich bin gerade dabei einen Baustein etwas zu optimieren.
Dabei ist mir aufgefallen, dass der Lade- und Arbeitsspeicher irgendwie nicht so genutzt werden, wie ich dachte.
Dazu habe ich dann einfach mal Versuche gemacht:
Hier mal die Übersicht:

Nun die Inhalte der einzelnen DBs:


(100 einzelnd deklarierte Bools)

100 einzelne Bools in einem Struct

Kombination aus 100er Array und 100er Struct

selbe Kombination nur andersherum

Mal ein "x"-beliebiger Datentyp

Der Datentyp UDT_Bool besteht wieder aus 100 einzelnen Bools

Datenbaustein_8 ist einfach leer.

Und die Unterschiede sind ja immens.
Danach ist ein Array ja deutlich kleiner als einzelne Bools. Klar, bei den optimierten Bausteinen belegt ein Bool ja auch ein Byte. Aber warum dann Faktor ~5 und nicht Faktir ~8? Und der Datentyp UDT_BOOL mit den gleichen Daten hat dann nochmal eine ganz andere Größe?
Was hat der Datentyp Alarm_Data an sich, dass bei dem so verhältnismäßig viel Arbeitsspeicher genutzt wird?


Vielen Dank schonmal.

 

[Semo]

Im Programmierleitfaden gibt es dazu was:

https://www.automation.siemens.com/sce-static/learning-training-documents/tia-portal/hw-config-s7-1200/programming-guideline-de.pdf

z.b. 2.6.2
Außerdem hast du bestimmt eine Speichereserve eingestellt (Standard)

Gruß

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Programmierleitfaden gibt es dazu was:

https://www.automation.siemens.com/sce-static/learning-training-documents/tia-portal/hw-config-s7-1200/programming-guideline-de.pdf

z.b. 2.6.2
Außerdem hast du bestimmt eine Speichereserve eingestellt (Standard) Anhang anzeigen 79051

Gruß

Im Ladespeicher der SIMATIC S7-1200/S7-1500 und der SIMATIC ET 200SP (Open Controller) werden folgende S7-Programm-Informationen abgelegt:

• Codebausteine (FCs, FBs und OBs)
• Datenbausteine (DBs)
• Technologie Objekte
• Datentypen
• PLC-Variablen
• Informationen über Programmcode, Symbolik und Kommentare

Das führt dazu, dass bei der SIMATIC S7-1200/S7-1500 ein Programm typischerweise in der Größenordnung von Faktor 10 größer ist als bei einer S7-300/S7-400 CPU, ET 200S CPU und WinAC RTX.

Der Ladespeicher einer S7-1200/S7-1500 CPU befindet sich auf der SIMATIC Memory Card. Um den Speicherbedarf Ihres Anwenderprogramms im Ladespeicher, und damit die Größe der benötigten Speicherkarte, vorab zu ermitteln, gehen Sie folgendermaßen vor.
Markieren Sie im Projekt die CPU, für die der Speicherbedarf ermittelt werden soll. Klicken Sie im Menü auf "Werkzeuge" und anschließend auf "Speicherauslastung"

Beachten Sie, dass zusätzlich zum Anwenderprogramm auf der SIMATIC Memory Card folgende Daten liegen, die Sie nicht über "Speicherauslastung" ermitteln können.

• Hardwarekonfiguration
• Verbindungsprojektierung
• Rezepte, Data Logs und HMI-Backups
• Nicht-SIMATIC Dateien, wie z.B. PDF, etc.

Hier noch ein Beitrag aus 2006:

Der Ladespeicher kann in den externen und in den internen Ladespeicher untergliedert werden. Der interne Ladespeicher ist ein in die CPU eingebauter RAM-Speicher. Mit "Zielsystem/Laden" übertragen Sie Bausteine vom Programmiergerät (PG) in den Ladespeicher der CPU. Der Arbeitsspeicher wird hier gleich mit aktualisiert, wobei die ablaufrelevaten Code- und Datenbausteine in den Arbeitsspeicher übertragen werden.
Über eine RAM Memory Card oder eine Flash Memory Card kann der Ladespeicher erweitert werden. Die Memory Card ist dann der externe Ladespeicher.

Der Arbeitspeicher ist in zwei Teile untergliedert. Davon wird ein Teil für den ablaufrelevanten Code verwendet. Im Arbeitsspeicher für den Code sind auch das Prozessabbild der Eingänge (PAE), das Prozessabbild der Ausgänge (PAA) und der Diagnosepuffer abgelegt. Der andere Teil des Arbeitsspeichers wird für die ablaufrelevanten Daten verwendet und enthält ebenso die Daten des Lokaldatenstack. Der Arbeitspeicher ist ein batteriegepufferter RAM.

 

[Fragsau]

HI,

vielen Dank für eure Rückmeldung und Mühe, leider beantwortet das nicht meine Frage.
Ich würde gerne verstehen, warum der Arbeitsspeicher und auch der Ladespeicher sich so unterschiedlich verhalten. Gibt es dazu einen "Ratgeber"?
Wie kann ich beeinflussen, dass ich einen DB möglichst viel im Ladespeicher ablege, also möglichst wenig den Arbeitsspeicher belaste? Immerhin kann der Ladespeicher recht einfach erweitert werden.
Wie sieht es denn von der Zugriffszeit her aus, was ist das besser?

 

[PN/DP]

Es wird immer die compilierte Version von DB im Arbeitsspeicher abgelegt. Die CPU kann nur mit Daten im Arbeitsspeicher arbeiten (deshalb heißt der so), mit DB im Ladespeicher kann die CPU nicht arbeiten. Manche CPU können DB zwischen Ladespeicher und Arbeitsspeicher hin und her kopieren, das dauert aber deutlich länger als ein Programmzyklus.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde gerne verstehen, warum der Arbeitsspeicher und auch der Ladespeicher sich so unterschiedlich verhalten. Gibt es dazu einen "Ratgeber"?
Wie kann ich beeinflussen, dass ich einen DB möglichst viel im Ladespeicher ablege, also möglichst wenig den Arbeitsspeicher belaste? Immerhin kann der Ladespeicher recht einfach erweitert werden.

Im Prinzip hat das @DCDCDC in #3 bereits beantwortet.
Im Ladespeicher wird im Prinzip alles projektspezifische zum DB abgelegt, also Symbolik/Komentare etc.
Das Zeug braucht die SPS im Arbeitsspeicher nicht, das gehört NUR zu deiner TIA-Projektierung (die eben auch auf der SMC abliegt)

Die Unterschiede im Arbeitsspeicher müssten aufgrund von unterschiedlichen Zusatzinformationen, die der Ablaufcode benötigt, zustande kommen.
Verschiedene Datenstrukturen generieren teils unterschiedliche Zusatzdaten, zusätzlich zu dem eigentlichen Speicherplatz, den die Variablen netto belegen müssten.
100 Bool sind zudem 12,5 byte => benötigt effektiv 14 byte + DB-header + Speicherreserve

Wie sieht es denn von der Zugriffszeit her aus, was ist das besser?

Zugriffe auf die SMC-DBs und "besser"?
Nur "besser" wenn du in der Zwischenzeit nen Kaffee trinken gehen willst.
Das sind azyklische Funktionen (also über mehrere SPS-Zyklen im "Hintergund" laufen) die zur eher gemütlichen Sorte gehören & auch nur komplette DBs lesen/schreiben können.
Schau dir mal die Befehle "READ/WRITE_DBL" in der TIA_Hilfe an.
Ich hab das schon für Konfigurationsspeicher, Rezepte oder als Möglichkeit den DB auf Startwerte zurückzusetzen benutzt.

 

[Staubsauger]

Was auch ziemlich interessant ist:

Wenn man auf einer 1500er große UDTs aus einem nicht optimierten Baustein an einen optimierten FB (oder umgekehrt) übergibt, benötigt das sehr viel Code-Speicher.

Der Datentyp hatte ca. 13300Byte und war ein bunter Mix aus anderen UDTs bestehend aus diversen standard-Datentypen.
Übergabe von DB nicht optimiert an FB optimiert -> ca. 21000 Byte Code-Speicher
Übergabe von DB optimiert an FB optimiert -> ca. 50 Byte Code-Speicher

Ist vielleicht für den ein oder anderen interessant, vor allem dann, wenn man bspw. mit HMIs von Drittherstellern arbeitet.