TIA TIA S7-1500 Kopieren einer Struktur nach Array of Byte

[Mediator]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Mediator: OK, das mit Serialize auf "Im IDB" werd ich bei Gelegenheit mal probieren. Wenn es geht wäre es ein weiteres Indiz für die möglicherweise "seltsam optimierte" (ein vierter Begriff ) IDB-Option.

... aber dieses "im IDB setzen"wurde noch nirgends wirklich erklärt und erscheint mir so "dazwischen".
Daher eben meine Frage ob jemand Details zum Mechanismus kennt. Und ja, es ist irre.

@Ronin: halt das Forum bitte auf dem Laufenden!
Der eigentliche Sinn von "im IDB setzen" ist Dir aber schon klar, oder? Damit kann man die Entscheidung pro Instanz entscheiden, ob die entsprechend markierten Variablen remanent sind oder nicht, ähnlich wie man das vielleicht in alten Projekten gehandhabt hat. Alles andere sind meines Erachtens Nebenwirkungen der Lösung (solche potentiell remanenten Daten separat halten), manchmal vielleicht sogar sinnvoll nutzbare.

Persönlich würde ich das nur verwenden, wenn mir keine andere Alternative mehr einfällt. Das Serialisieren / Deserialisieren in / von Byte-Arrays müsste meines Erachtens auch ohne "im IDB setzen" funktionieren, auch wenn das momentan offensichtlich nicht der Fall ist.

 

[RONIN]

Was es tun soll ist mir schon klar, wofür man es haben muss allerdings nicht. Die Remanenzeinstellung sollte ja logischerweise beim Bausteinersteller liegen und nicht beim Anwender...
Mir fällt kein Anwendungsfall ein wo es mir bedeutend nutzen würde wenn der Bausteinanwender die Remanenz einstellen lasse.

Zurück zum Thema.
Ich hab hier jetzt auf einer 1512 beide Varianten ausprobiert. Das Serialize auf das Array mit "im IDB setzen" geht, das dürfte also eine Lösung für den TE sein.

Dann hab ich noch einen Vergleich zwischen AT und Serialize probiert.
Eine Teststruktur mit Größe 1000Byte (5x String[198]) auf jeweils ein Array[1..1000] of Byte.
Der Baustein für das Serialze bekommt den 1000-Byte-Struct über denn IN übergeben, hat im OUT ein Array[1..1000] mit "im IDB setzen" auf dass die Daten per Serialize draufgeladen werden.
Der Baustein mit AT hat ebenfalls den 1000-Byte-Struct am IN, allerdings schon dort mit "im IDB setzen", dann gibt es jeweils ein Array[1..1000] im IN (für das AT) und eines im OUT.
Der einzige Code in dem FB ist das Umkopieren des AT-Arrays auf das OUT-Array. Alles mit optimierten Zugriff.
Von jedem Baustein hab ich 5 Instanzen aufgerufen und dann dazwischen die Runtime gemessen.

Hier der Screenshot dazu.


Laut dem Runtime dauert das Serialize länger. Das AT ist meistens in den hohen 10^-4s währen das Serialze eher in den niedrigen 10^-3s ist.
Hab jetzt aber nicht viel probiert, vielleicht ist es sogar ein Laufzeitunterschied ob nun das "im IDB setzen" im IN oder im OUT deklariert wird.
Vielleicht ist das Serialize wirklich langsamer als das einfache Umkopieren beim AT. Wer weiß, zum genauer anzuschauen fehlt mir heute die Muse.

Hier das Testprojekt das ich verwendet hab, falls es jemand selber probieren will.
Anhang anzeigen CompATtoSERIAL.zip

Komisch ist aber schon das ein Serialize welches laut Hilfe ausdrücklich einen "Standardzugriff" erfordert mit einem "optimierten - im IDB setzen" klar kommt.
Langsam kommt mir der Verdacht dass die Teile die man "IDB setzen" markiert einfach ganz klassisch "nicht optimiert" gespeichert werden. Falls das überhaupt möglich ist.

 

[shiks]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe jetzt auch mal bei Siemens nachgefragt und will euch natürlich diese Info nicht vorenthalten


Antwort Siemens:
momentan besteht noch keine Möglichkeit ein Array in ein Struct bzw. ein Struct in ein Array in einem optimierten Baustein direkt umzukopieren.

Eine Alternative wäre es die Bausteine Serialize und Deserialize zu verwenden. Dies ist aber nur mit nicht optimierten Bausteinen bzw. mit der Remanenz "Im IDB setzen" möglich.

Nähere Informationen zu diesen Bausteinen finden Sie unter folgendem FAQ beschrieben.

https://support.industry.siemens.com/cs/ww/de/view/42603881

Eine weitere Alternative wäre es ein AT-Konstrukt zu verwenden. Dies können Sie auch in optimierten Bausteinen mit der Remanenz "Im IDB setzen" verwenden. Sie könnten die Struct z.B. mit einem Array überlagern und anschließend zwischen den Arrays umkopieren.

Nähere Informationen zum AT-Konstrukt finden Sie unter folgendem FAQ beschrieben.

https://support.industry.siemens.com/cs/ww/de/view/57132240

 

[Mediator]

Dann hab ich noch einen Vergleich zwischen AT und Serialize probiert.
...

Laut dem Runtime dauert das Serialize länger. Das AT ist meistens in den hohen 10^-4s währen das Serialze eher in den niedrigen 10^-3s ist.
...

Komisch ist aber schon das ein Serialize welches laut Hilfe ausdrücklich einen "Standardzugriff" erfordert mit einem "optimierten - im IDB setzen" klar kommt.
Langsam kommt mir der Verdacht dass die Teile die man "IDB setzen" markiert einfach ganz klassisch "nicht optimiert" gespeichert werden. Falls das überhaupt möglich ist.

Ich gehe davon aus, dass Dein Beispiel eher für die Verwendung von Serialize spricht. Warum? Deine Struktur enthält Strings und außer dem Kopieren / Serialisieren gibt es keine Zugriffe.
Angenommen Du hättest eine Struktur mit Bool, Integer, Real, usw. und Du würdest im Programm relativ oft auf die Strukturelemente zugreifen und etwas berechnen, dann würde das Programm relativ stark von der Einstellung "optimiert" profitieren bzw. relative stark verlangsamt, wenn Du diese Struktur mit Set in IDB "verbiegen" würdest. Bei so einem Programm würde ich erwarten, dass der Ansatz mit Serialize besser ist, wenn Du diese Struktur aus welchen Gründen auch immer in ein Byte - Array serialisieren müsstest.

Ich denke, Du liegst mit Deinem Verdacht schon richtig, dass mit "Set in IDB" markierte Daten "nicht optimiert" gespeichert werden. Bei einem Byte-Array ist das allerdings kein Laufzeitnachteil. Trotzdem würde ich mit Set in IDB nur arbeiten, wenn mir keine Alternative mehr einfallen würde.

 

[Paule]

Was für ein Quatsch mit dem "optimierten" und "nicht optimierten" Zugriff um die Geschwindigkeit zu erhöhen.
He Leute das sind Steuerungen der neusten Generation, die sollten ordentlich Power unter dem Plastikhäusle haben,
ohne das sich der Programmierer Gedanken darüber machen muss um Zykluszeit zu sparen.
Oder machen wir jetzt wieder ein Schritt Richtung S5 Zeiten.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was für ein Quatsch mit dem "optimierten" und "nicht optimierten" Zugriff um die Geschwindigkeit zu erhöhen.
He Leute das sind Steuerungen der neusten Generation, die sollten ordentlich Power unter dem Plastikhäusle haben,
ohne das sich der Programmierer Gedanken darüber machen muss um Zykluszeit zu sparen.
Oder machen wir jetzt wieder ein Schritt Richtung S5 Zeiten.

Sehe ich genauso!!!
Meiner Meinung nach hat Siemens die "optimierten" DBs nur eingeführt, um den Zugriff von Fremdsytemen ala libnodave zu erschweren...
Werd mein nächstes 1500er Projekt mal komplett nichtoptimiert durchziehen... Mal schaun was da rauskommt. Gibts da schon wieder Siemens Funktionen, die bei nichtoptimiert nicht funktionieren?

 

[DarthMaddin]

Hi,
ich war vergangene Woche bei Siemens wegen V14.
Ab dieser Version können die Bausteine "Serialize" und "Deserialize" auch auf optimierte Speicherbereiche zugreifen!
Habe es auch in der Pilotversion testen können.
Wenn man ein Projekt hochrüstet muss man in der Bibliothek zwingend die Bausteine auf Version 2.0 stellen!
Außerdem ist Firmware 2.0 auf den CPUs notwendig.

Grüße
DarthMaddin

 

[shiks]

Was für ein Quatsch mit dem "optimierten" und "nicht optimierten" Zugriff um die Geschwindigkeit zu erhöhen.
He Leute das sind Steuerungen der neusten Generation, die sollten ordentlich Power unter dem Plastikhäusle haben,
ohne das sich der Programmierer Gedanken darüber machen muss um Zykluszeit zu sparen.
Oder machen wir jetzt wieder ein Schritt Richtung S5 Zeiten.

Meiner kurzen Erfahrung nach macht es einen großen unterschied ob man optimiert arbeitet oder nicht.
In meinem aktuellen (und ersten) 1500er Projekt habe ich meine Standardbausteine aufrund von bequemlichkeit,Zeitersparniss und weil ich wusste das die Bausteine funktionieren einfach migriert.
Die neu hinzugekommen Funktionen habe ich dann optimiert angelegt.

Die Zykluszeit war erschreckend hoch bei 50ms also habe ich alles bis auf 1-2 austehende Standardbausteine optimiert und siehe da die Zykluszeit ist aktuell bei ca 7-10ms.

Es gab auch schon einen Beitrag hier im Forum der das Thema durchgekaut hat und bei dem ist so ganz grob raugekommen:
alles optimert = kürzest mögliche Zykluszeit
nur Standardzugriff = bis zu 3x mal langsamer
Mischbetrieb = bis zu 6x mal langsamer

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also kann man ja imerhin die Bausteine, bei denen man spezielle Zugriffe (HMI; Libnodave, Any) nutzen will nicht optimiert machen. "Normale" FB lasse ich auch auf "optimiert" stehen.
Man muß nicht Alles "optimiert" machen. Hinzu kommt, dass ach nicht optimierte Bausteine schnell sen können, auf die Datenstruktur kommt es an, denn das ist es, was Siemens da eingentlich optimiert, Zugriffe durch die CPU sollen möglicht mit wenigen Schreib/Lesezyklen erfolgen.

Für mich ist das ein typischen Siemens-Debakel. Man bürdet den Programmiereren die Last auf zu entscheiden und umzusetzen. Das im Lichte dessen, dass man mit "optimierten" Bausteinen nciht alles machen kann. Man denke hier nur mal an Bitmeldungen für die HMI, die man im DB schön Bitweise mit Nummer im Variablennamen sehen möchte. Das geht nicht "optimiert". Ein Hoch auf guten Code. Bei Codesys muß ich mich um so etwas wirklich kaum mal kümmern, was also macht Suemens da?

 

[ducati]

Schneller oder langsamer ist halt immer relativ... Fuer mich stellt 10mal langsamer kein Problem dar, wenn die Zykluszeit dann bei 50ms liegt. In der Prozessautomatisierung reicht das in der Regel dicke aus.