TIA S7: Keine Benutzer definierte Datentypen bei InOut-Variablen möglich?

[Automatinator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum eigentlich?
Das du den SPS Speicher vollbekommst?

Damit ich eine Variable nicht drei mal anlegen muss, um vollen Zugriff und Einsicht zu erhalten.
Aber was meinst du mit Speicher füllen? Wieso würde das den Speicher mehr belasten?

 

[vollmi]

Wenn man viel mit UDTs arbeitet, geht man mit den Elementen darin oft auch etwas grosszügiger um. Zumindest erwische ich mich immer dabei, dass ich z.B. auch DINT nehme wenn ein INT oder Byte reichen würde etc.
Wenn dann diese UDTs dann von jedem Baustein auch noch in der Instanz angelegt werden müssen (IN und OUT), dann füllt das natürlich den Ladespeicher recht schnell. Darum ist INOUT oft vorzuziehen, auch wenn man nur lesen oder nur Schreiben muss. Da dann per Pointer referenziert wird und keine Kopie im InstanzDB angelegt werden muss.

mfG René

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, Ladespeicher spart man nur bei vielen Instanzen. Wenn man UDTs via INOUT an FB übergibt, dann wird der Datenspeicherbedarf der Instanz kleiner, aber wegen dem viel höheren Codeaufwand zum Zugreifen auf die INOUT-UDTs wird der Codespeicherbedarf größer (der IDB wird kleiner, der FB wird größer).

Harald

 

[PN/DP]

@Automatinator
Warum willst Du unbedingt von außen auf den Bausteinparameter des FB zugreifen (in dessen IDB), warum kannst Du nicht direkt auf den übergebenen UDT zugreifen (auf den Global-DB)? Wo ist da für Dich der Unterschied?

Harald

 

[vollmi]

Naja, Ladespeicher spart man nur bei vielen Instanzen. Wenn man UDTs via INOUT an FB übergibt, dann wird der Datenspeicherbedarf der Instanz kleiner, aber wegen dem viel höheren Codeaufwand zum Zugreifen auf die INOUT-UDTs wird der Codespeicherbedarf größer (der IDB wird kleiner, der FB wird größer).

Jap, das kommt sicher auf die Art der Software an. Bei mir isses halt meistens so dass ein ObjektFB 200 Mal aufgerufen wird. Da ist die Codegrösse des FBs nicht so massgebend, die Grösse der zu speichernden Daten aber dann eben schon, vor allem wenn sie dann auch noch doppelt und dreifach vorhanden sind.

Dafür ist der Codeaufwand ja auch ein Zykluszeitfresser. Da ist mir übrigens aufgefallen dass die 1500er dahingehend weniger anfällig sind als die 400er. Will heissen meine Portierten SCL Bausteine leisten sich weniger Zykluszeiterhöhung wenn ich sie ins TIA Portal portiere.

mfG René