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

shiks

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

ich benutze aktuell eine CPU 1515-2 PN und möchte gerne mein Programm auf optimierte Bauteine umstellen.

Leider bin ich auf ein Problem gestoßen für das ich keine Lösung habe und zwar....

möchte ich eine Struktur (String,Byte,Int usw) in ein Array of Byte umkopieren und auch andersrum :D

Da ich wie gesagt alle Bausteine optimieren möchte fallen die Bausteine Serialize und Desarialize leider weg

Vl hat von euch jemand die Lösung
mit besten Dank im vorraus
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Array kann ja auch in einem optimierten Baustein liegen!

Da würde die TIA-Hilfe aber was anderes sagen...
TIA-Hilfe schrieb:
Serialize: Serialisieren S7-1200, S7-1500

Der Speicherbereich, in dem die umgewandelten PLC-Datentypen abgelegt werden, muss den Datentyp ARRAY of BYTE haben und mit Standardzugriff deklariert sein.

Parameter RET_VAL
Die folgende Tabelle zeigt die Bedeutung der Werte des Parameters RET_VAL:

Fehlercode*
(W#16#...) Erläuterung

8236 Der Datenbaustein am Parameter DEST_ARRAY ist kein Baustein mit Standardzugriff.
 
In optimierten FBs kann man mit Sichten AT arbeiten, wenn bei den betreffenden Variablen die Remanenz auf "Im IDB setzen" eingestellt wird.
Somit kann man die Struktur in was auch immer umkopieren.

Die Sichten sind auch mit KOP, FUP und AWL nutzbar.
 
Du könntest probieren ob das mit dem Slice zugriff geht vermutlich müsstest du dann aber den String mit String to Char umwandeln.
 
Da würde die TIA-Hilfe aber was anderes sagen...
Stimmt, Du hast Recht, das Array muss mit Standardzugriff deklariert sein :confused:
Sorry, ich dachte, ich hätte das schon mal verwendet. Könnte aber sein, dass ich da mit "Im IDB setzen" gearbeitet habe.
Davon abgesehen verstehe ich allerdings nicht, warum das nicht geht. Bei einem Bytearray ist es doch wohl egal, wo das liegt:confused:
@shiks: ware es überhaupt ein Problem, wenn das Byte-Array in einem nicht optimierten DB liegt? Wenn ja, warum? Was soll damit passieren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@shiks: ware es überhaupt ein Problem, wenn das Byte-Array in einem nicht optimierten DB liegt? Wenn ja, warum? Was soll damit passieren?

Prinzipiell ist es kein Problem mit nicht optimierten Bausteinen aber weil sich durch das mischen von nicht optimierten und optimierten Bausteinen die Zykluszeit verschlechtert und es ja eine Lösung
geben muss habe ich mich da etwas festgebissen :p
 
Prinzipiell ist es kein Problem mit nicht optimierten Bausteinen aber weil sich durch das mischen von nicht optimierten und optimierten Bausteinen die Zykluszeit verschlechtert und es ja eine Lösung
geben muss habe ich mich da etwas festgebissen :p

Verstehe :) In Fallen, in denen man Serialize bzw. Deserialize braucht, entstehen ja aber meist keine zusätzlichen Konvertierungen (außer diejenige durch Serialize und Deserialize). Im Programmierleitfaden für S7-1200/S7-1500 ist in Kapitel 2.6 recht gut beschrieben, was ungünstig ist: https://support.industry.siemens.com/cs/ww/de/view/90885040
 
Vielen Dank für deine Antwort.
Weißt du warum der "AT" Befehl laut Siemens Doku nicht in optimierten Bausteinen Funktioniert aber wenn man im im IDB setzen anklickt es trotzdem geht?
:confused:
Wo steht in dem von Dir angegebenem Dokument, dass es nicht gehen soll?
(Meine Suche findet dort nichts zu Sichten :()


Das ist aber von Siemens selbst zumindest in der TIA-Hilfe so dokumentiert:

TIA Hilfe F1 schrieb:
Variablen mit AT überlagern

Beschreibung
Um auf Datenbereiche innerhalb einer deklarierten Variablen zuzugreifen, können Sie die deklarierten Variablen mit einer weiteren Deklaration überlagern. Sie haben so die Möglichkeit, eine bereits deklarierte Variable mit einem anderen Datentyp anzusprechen. Sie können z. B. die einzelnen Bits einer Variablen vom Datentyp WORD mit einem ARRAY of BOOL ansprechen.

Regeln
Folgende allgemeine Regeln gelten für das Überlagern von Variablen:

  • In AWL, KOP, FUP und GRAPH ist das Überlagern in S7-1200 und S7-1500 möglich.
  • In SCL ist das Überlagern in allen CPU-Familien möglich.
  • Das Überlagern von Variablen ist in folgenden Bausteinen möglich:
    • In Codebausteinen mit Standardzugriff
    • In Codebausteinen mit optimiertem Zugriff für Variablen mit der Remanenzeinstellung "Im IDB setzen"
  • Die Datenbreite der überlagernden Variablen muss gleich oder kleiner als die der überlagerten Variablen sein.
  • Die Datenypen VARIANT und INSTANCE können nicht überlagert werden.
  • Bausteine aus Bibliotheken, die als Parameter in der Schnittstelle deklariert sind, können nicht überlagert werden.
  • Strukturierte PLC-Variablen, die als Parameter in der Schnittstelle deklariert sind, können nicht überlagert werden.
  • Überlagernde Variablen können nicht durch Slice-Zugriffe adressiert werden
Also kein "trotzdem" sondern gewollt.
Ich denke mal, für genau solche Anwendungen.
 
:confused:
Also kein "trotzdem" sondern gewollt.
Ich denke mal, für genau solche Anwendungen.
Naja, das primäre Ziel bei dem "im IDB setzen" wird wohl nicht die AT-Sicht gewesen sein. Hoffe ich halt. Ich denke das war ein "angenehmer" Nebeneffekt.

Was mich allerdings mehr interessieren würde...
Weiß irgendjemand was das "im IDB setzen" genau macht bzw. wie es die Speicherzugriffe verbiegt?
Damit AT-Sichten gehen werden die Daten wahrscheinlich irgendwie Blockweise und vielleicht "quasi nicht optimiert" abgelegt.
Allerdings, obwohl zwar die Zugriffszeiten darauf höher sein sollen, kann ich mir auch nicht vorstellen dass die wirklich "nicht optimiert", also BigEndian, abgelegt werden.

Wäre interessant was diese Verbieger-Option tut.
 
Was mich allerdings mehr interessieren würde...
Weiß irgendjemand was das "im IDB setzen" genau macht bzw. wie es die Speicherzugriffe verbiegt?
Im weiter unten verlinkten Programmierleitfaden steht auch hierzu etwas, das Deinen Verdacht bestätigt, auch wenn die Beschreibung nicht wirklich konkret wird:
Empfehlung
[FONT=Arial,Arial][FONT=Arial,Arial]Verzichten Sie auf die Einstellung „m IDB setzen" ("Set in IDB"). Stellen Sie remanente Daten immer im Funktionsbaustein ein und nicht im Instanz-Datenbaustein. Die Einstellung „m IDB setzen" ("Set in IDB") erhöht die Abarbeitungszeit des Programmablaufs. Wählen Sie für die Schnittstellen im FB immer entweder „nicht remanent" („non-retain") oder „remanent" („retain"). [/FONT][/FONT]
[FONT=Arial,Arial][FONT=Arial,Arial][/FONT][/FONT]
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Mediator: Eben diese Zeile hatte ich gemeint. Ich habe den Leitfaden ja sogar gelesen... ;)

Naja, irgendwie anders als "optimiert" (weil da geht kein AT) und "nicht optimiert" (weil ich mir BigEndian - wie bei nicht-opt. - auch nicht vorstellen kann) müssen die Daten ja abgelegt werden damit man zu diesem "AT geht jetzt in optimiert, aber die Zugriffszeiten sind trotzdem hoch"-Ergebnis kommt. Von daher gesehen finde ich den Begriff "verbiegen" nicht so falsch.
 
@Mediator: Eben diese Zeile hatte ich gemeint. Ich habe den Leitfaden ja sogar gelesen... ;)

..., aber die Zugriffszeiten sind trotzdem hoch"-Ergebnis kommt. Von daher gesehen finde ich den Begriff "verbiegen" nicht so falsch.
@Ronin: Ich hatte schon den Verdacht, dass Du ihn gelesen hast, aber ich wollte sicher gehen ...;)

Ich glaube aber eher nicht, dass die Zugriffszeiten in diesem konkreten Beispiel hoch werden. Denn shiks müsste ja nur das Byte Array auf Set in IDB setzen. Die Struktur könnte ja ganz normal Non-retain oder Retain sein, was vermutlich ganz normal optimiert wäre. Sicher bin ich mir aber nicht :confused: Bei Gelegenheit werde ich das vielleicht mal probieren. Man erkennt die Ablageform ja ganz leicht am Speicherbedarf.
 
Hmm.. Wie meinst du das? Wenn er AT (Array AT Struct) verwenden will dann muss doch das auf das die AT zeigen soll, also die Struktur, als "im IDB" deklariert werden, sonst kann ich ja keine AT eintippen?

Kann man eigentlich ein Serialize auf ein "im IDB"-deklariertes Array machen, geht das? Noch nie probiert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hmm.. Wie meinst du das? Wenn er AT (Array AT Struct) verwenden will dann muss doch das auf das die AT zeigen soll, also die Struktur, als "im IDB" deklariert werden, sonst kann ich ja keine AT eintippen?

Kann man eigentlich ein Serialize auf ein "im IDB"-deklariertes Array machen, geht das? Noch nie probiert.

Ich meinte den ursprünglich geäußerten Wunsch, Serialize / Deserialize zu verwenden. Ich glaube das habe ich schon mal probiert, deshalb war ich fälschlicherweise der Meinung, dass Serialize / Deserialize ganz allgemein mit Arrays in optimierten Bausteinen geht.

Ob der Ansatz mit AT oder der Ansatz mit Serialize / Deserialize besser ist und ob es sich eher lohnt, sich über die Performance Gedanken zu machen oder eher über die Einfachheit des Programms oder andere Gesichtspunkte, hängt von der Anzahl (pro Sekunde) der normalen Zugriffe auf die Struktur ab, von der Anzahl (pro Sekunde) der Serialize / Deserialize - Aufrufe und von der Größe der Struktur.
 
Das ganze ist doch irre... Gibts jetzt nicht nicht nur optimiert und nichtoptimiert sondern auch noch teiloptimiert? Was soll der Scheiss? Was macht eigentlich ein optimierter OB? Und ein optimierter FC? ... Fragen ueber Fragen...
 
@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 :ROFLMAO:) IDB-Option.

@Ducati: "teil-optimiert" ist jetzt nur mein Begriff und hab nur Vermutungen die aus den Veröffentlichungen von Siemens und den Möglichkeiten beim Programmieren basieren.
Da muss nicht viel dran sein, vielleicht schwafle ich nur Blödsinn. Mit meinem beschiedenen Wissen stochere ich doch eher im Trüben.
Die Unterschiede zwischen optimiert und nicht-optimiert scheinen einigermaßen klar, 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.
 
Zuletzt bearbeitet:
Zurück
Oben