TIA SCL: String in AT-Sicht beschreiben

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe ein Array of Byte, das an einen Baustein (RFID Reader) übergeben wird.
Über dieses Array habe ich eine AT-Sicht mit der Datenstruktur des Transponders gelegt.

Scheinbar kann TIA (V16 mit 1517er) aber die Strings nicht schreiben.
Bin ich zu doof oder gibt's da einen Trick?

Unten im Screenshot sieht man das Drama...
Es geht weder mit einer Variable (FaNummer) noch mit einer Konstante (LetzterArbeitsgang)

Mit S_MOVE geht es auch nicht.

 

[PN/DP]

Sind die beiden Header-Bytes des Zielstrings initialisiert bzw. mindestens MaxLen? Falls in MaxLen eine 0 drin steht, dann wird nichts in den String geschrieben.

Harald

 

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sind die beiden Header-Bytes des Zielstrings initialisiert bzw. mindestens MaxLen? Falls in MaxLen eine 0 drin steht, dann wird nichts in den String geschrieben.

Harald

Harald...
Du bist einfach der Beste!
Danke dir!

 

[Markus]

OK, ich könnte noch etwas Hilfe bei der Kosmetik gebrauchen.

Das hier geht natürlich:

#WriteDataArray[1] := 20; // Erstes Byte in "#WriteData.FaNummer" auf 20 schreiben weil ab dort der Datentyp STRING[20] beginnt

Schicker wäre das aber mit Slice, aber irgendwie will das beim String nicht:

#WriteData.FaNummer.%B0 := 20;

Jemand eine Idee?

 

[hucki]

OK, ich könnte noch etwas Hilfe bei der Kosmetik gebrauchen.

Das hier geht natürlich:

#WriteDataArray[1] := 20; // Erstes Byte in "#WriteData.FaNummer" auf 20 schreiben weil ab dort der Datentyp STRING[20] beginnt

Schicker wäre das aber mit Slice, aber irgendwie will das beim String nicht:

#WriteData.FaNummer.%B0 := 20;

Jemand eine Idee?

Ist das nicht eigentlich Aufgabe der Deklaration des String im UDT?
Oder geht das durch die Übernahme der Bytes verloren?

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du mal versucht, concat zu benutzen? Das sollte die beiden (den leeren und den neuen) Strings mitenander vertknüpfen und die Länge entsprechend korrigieren.

 

[Markus]

Normal schon...
Bei einer AT-Sicht wird das bei der Deklaration scheinbar nicht an die darunterliegenden Bytes übergeben.

Das ist entweder ein Fehler oder Absicht.
Angenommen es könnte mehrere verschiedene AT-Sichten auf das Bytearray geben, dann wäre es ja so schön richtig. Welche Deklaration hat dann recht?

 

[hucki]

Angenommen es könnte mehrere verschiedene AT-Sichten auf das Bytearray geben, dann wäre es ja so schön richtig. Welche Deklaration hat dann recht?

Wie immer (z.B. bei Zuweisungen u.ä.), die zuletzt verwendete...

 

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du mal versucht, concat zu benutzen? Das sollte die beiden (den leeren und den neuen) Strings mitenander vertknüpfen und die Länge entsprechend korrigieren.

Habe nicht, wird aber das gleiche Problem ergeben, da im ersten Byte 0 steht.

Wie gesagt, wenn ich da die Maxlänge ins erste Byte schreibe dann geht's.

 

[hucki]

OK, ich könnte noch etwas Hilfe bei der Kosmetik gebrauchen.

Das hier geht natürlich:

#WriteDataArray[1] := 20; // Erstes Byte in "#WriteData.FaNummer" auf 20 schreiben weil ab dort der Datentyp STRING[20] beginnt

Schicker wäre das aber mit Slice, aber irgendwie will das beim String nicht:

#WriteData.FaNummer.%B0 := 20;

Und warum wäre das schicker?

Du korrigierst doch die falsche Zuweisung genau auf der Seite, auf der sie auch geschieht.
IMHO ist da nix unsauberes dran.

 

[Markus]

Angenommen jemand ändert die Datenstruktur des Transponders, also das was die AT-Sicht über das Bytearray legt, dann passt sich das dynamisch an.

Ist allerdings auch nicht ganz durchgängig, da diese Lösung eine Änderung der Stringlänge auch nicht berücksichtigt.

Ich mag absolute Sachen nicht so gerne, wenn möglich versuche ich den Code möglichst Idiotensicher zu machen damit bei Änderungen nicht an vielen Stellen gefummelt werden muss.

Aber egal.
Warum geht das nicht was ich da oben tun wollte?

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Alternativ könntest Du noch das ByteArray über den udt legen (statt udt über ByteArray).
So bleibt zumindest die String-Deklaration erhalten.

Dann muss die Sicht aber vermutlich in den Static-Bereich und das gleiche Array noch mal auf den Out (OutArray := AtArray), damit Du es außerhalb weiterverwenden kannst.

Oder Du nutzt Serialize um den udt auf das Byte-Array zu übertragen. Dann fällt auch das halboptimierte unter den Tisch.

 

[Heinileini]

Schicker wäre das aber mit Slice, aber irgendwie will das beim String nicht:

#WriteData.FaNummer.%B0 := 20;

Jemand eine Idee?

Vielleicht noch eine weitere AT-Ansicht drüberlegen - nur über die beiden LängenBytes am Anfang des Strings - die einen SliceZugriff erlaubt?

 

[Onkel Dagobert]

Laut Onlinehilfe sind Strukturen, Konstanten und mit AT überlagerte Variablen nicht durch Slice-Zugriffe adressierbar. Darüber hinaus muss die adressierte Variable vom Datentyp Bitfolge oder Ganzzahl sein.

Markus, wie wird denn das ARRAY an den RFID-Reader übergeben? Kannst du nicht direkt den UDT übergeben und das ARRAY ganz weglassen?
Je länger ich darüber nachdenke, ist das Pferd vermutlich von hinten aufgezäumt.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Laut Onlinehilfe sind Strukturen, Konstanten und mit AT überlagerte Variablen nicht durch Slice-Zugriffe adressierbar. Darüber hinaus muss die adressierte Variable vom Datentyp Bitfolge oder Ganzzahl sein.

Der DatenTyp Ganzzahl wäre ja passend (USINT) - ausser, dass es dann eigentlich nichts mehr zu slicen gibt.

Aber, wenn AT-überlagerte Variablen grundsätzlich nicht durch SliceZugriffe ansprechbar sind ...
Vielleicht hilft hier Wortklauberei.
Wenn Variable A durch Variable B überlagert wird, ist dann Variable A die überlagerte und Variable B die überlagernde und gilt die Einschränkung für beide Variablen oder nur für eine der beiden?

 

[Onkel Dagobert]

Für mein Verständnis gibt es nur eine überlagerte Variable.

 

[Heinileini]

Für mein Verständnis gibt es nur eine überlagerte Variable.

D.h. die überlagernde Variable könnte doch für Slice-Zugriffe zugänglich sein!?

 

[Markus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Markus, wie wird denn das ARRAY an den RFID-Reader übergeben? Kannst du nicht direkt den UDT übergeben und das ARRAY ganz weglassen?
Je länger ich darüber nachdenke, ist das Pferd vermutlich von hinten aufgezäumt.

Müsste ich mir nochmal anschauen, ich meine es ging nicht.
Am Anfang wollte ich es so haben, aber es ging irgendwie nicht.

Ggf. habe ich es nur falsch angebunden.
Auszug aus der Hilfe des Identbausteins "Write":

Datenpuffer mit den zu schreibenden Daten.

Bei MV: Erstes Byte codiert den entsprechenden MV-Befehl.1)

Hinweis:
Bei Variant ist derzeit nur ein "Array_of_Byte" mit variabler Länge anlegbar. Bei Any können zusätzlich auch andere Datentypen/UDTs angelegt werden.

Grundsätzlich geht bei mir Dank Haralds Tipp auch alles.
Bin nur am grübeln ob es nicht noch schöner geht - also alles gut soweit.

Danke euch!

 

[PN/DP]

Wird da, wo der String[20] deklariert ist, der String nicht initialisiert (am universellsten mit einem leeren String '' )? Da sollten doch auch die String-Headerbytes initialisiert werden. Oder hilft vielleicht eine explizite Zuweisung MyString := ''; ?

Harald

 

[Onkel Dagobert]

Der String wird dort wo er deklaiert ist (im UDT), nicht initialisiert, weil dort gar keine Daten existieren. Es ist an dieser Stelle nur eine Sicht auf die "dummen" Bytes im Array. Wo kämen wir denn hin, wenn alleinig eine Sicht auf eine Variable deren Inhalt verändern würde? Das darf doch gar nicht gehen!

Markus, mit "Serialize" und "Deserialize" kannst du einen UDT recht einfach in ein ARRAY of Byte verschieben, bzw. umgekehrt. Vielleicht vereinfacht es ja die Sache, wenn du mit dem UDT arbeitest, und erst zur Übergabe zu dem Identbaustein die Daten in das ARRAY verschiebst? Das wäre aus meiner "Sicht" die richtige Richtung.

Der Baustein "Write" ist bestimmt optimiert?