UDT SizeOf (optimierter Baustein)

Hallo zusammen,

ich würde gerne, wie es in vielen anderen Entwicklungsumgebungen möglich ist. wissen wie groß mein UDT ist.

Die so genannte mögliche Kopierfunktion soll im "optimierten Zugriff" möglich sein.

Meine Ansatz ist das ich von einem Empfangspuffer N-Bytes in diesen UDT kopieren möchte.

Das scheint ja in der Siemens Welt wohl ein riesen Thema zu sein, zumindest habe ich bis dato nichts passendes dazu gefunden was anwendbar wäre.

Hat da jemand einen Ansatz bzw. eine Vorgehensweise für mich?

Oder wie geht ihr mit diesem Thema generell um? Wie kopiert ihr solche Daten grundlegend um.

Interessant ist das ganze wenn man unterschiedliche UDTs hat weil z.B. der Empangsstream unterschiedlich ist.

Gruß

MacToolz

Hallo MacToolz,

wenn Dein UDT den gleichen Aufbau wie Deine zu kopierende hat ist dies mit MOVE kein Problem.

Wozu benötigst Du die genaue Größe des UDT?
Wenn Du mit optimierten DB's arbeitest ist z.B. ein Bool gleich ein Byte.
Du kannst auch verschachtelte UDT's aufbauen (ein UDT ist Bestandteil eines weiteren).

Wenn Du uns mitteilen kannst was Du genau machen möchtest ist es einfacher einen "guten" Lösungsvorschlag/Antwort zu geben.

Grüße'
CaOd

Hi,

ok, ich beschreibe mal das grundlegende Problem. 

Ich habe ein Gerät was über TcpIP kommuniziert. Das Thema TcpIP ist nicht das Problem.

Die Daten die ich erhalte sind entsprechend über den Empfangs Puffer (ArrayOfBytes)

zu verwenden und zu deserialisieren.

Ab dem Punkt beginnt das Thema. 

Wie bekomme ich den Empfang deserialisiert, nicht jetzt unbedingt die Siemens Funktion damit gemeint. Ich habe schon sehr viele versuche gestartet was das angeht.

Über diverse Funktionalitäten wie ich mit dem Gerät kommuniziere, bekomme ich entsprechend unterschiedliche Antworten.

Die Antworten sind auch von unterschiedlicher Reihenfolge Datentypen übermittelt. Natürlich ist jede Funktionalität fest in ihrer Datentyp Reihenfolge definiert.

Beispiel : FunktionCodes 10 

Antwort der Bytes/ Datentypen

100 x LReals, die ersten 800Byte

2 x Strings[200], die nächsten 400Byte

4x DWord, die nächsten 16Byte 

etc.

Eine andere Antwort liefert halt eine andere Reihenfolge von Datentypen.

Das ganze läuft auch im optimierten Speicherzugriff. Zumindest ist das Kundenvorgabe,

wo ich mich gerade schwer entgegen stellen kann diese Anforderung zu ändern

1. Problem, Siemens String Datentypen kennt das Gerät nicht.

Heißt, die maximale Länge und tatsächliche Länge ist dem Gerät völlig Fremd.

Natürlich ist definiert das die String Länge z.B. 200 maximal haben darf

2. wie konvertiere ich denn einen String ohne diese Angaben der ersten beiden bytes

obwohl im optimierten Zugriff diese beiden Bytes nicht mehr gibt.

In anderen Entwicklungsumgebungen oder auch in der Hochsprache benötige ich nicht viel um Speicherbereiche einfach zu kopieren.

Quelle, Ziel, Größe des Ziels.

Der Aufwand dafür ist eine Zeile. Damit habe ich alles kopiert.

Wir brauchen uns nicht darüber zu unterhalten was das zur Folge hat wenn Quelle Ziel etc nicht stimmen.

Ist das Thema soweit von meiner Seite klar beschrieben.

Gruß

Hallo MacToolz,

danke für die gute Erklärung Deiner "Herausforderung".

Hast Du in dem Empfangspuffer eine Kennung um welche Antwort es sich handelt? z.B. den Funktionscode
Wenn ja könntest Du auf Basis dieser Kennung die Daten in einen DB schieben, da Du hier die notwendigen Grenzen kennst. Du hast natürlich die Herausforderung für jede unterschiedliche Antwort eine dem entsprechenden UDT etc. zu schreiben.

Ich würde versuchen je nach Kennung in einem DB die Daten abzulegen und dann in den "Ziel-DB" (z.B. Istwerte etc.) zu schreiben/kopieren.
Dies ist zwar ein erhöhter Aufwand, doch dann hast Du die Daten gleich da wo Du sie hinhaben möchtest.

Bei dem String würde ich die einzelnen Character verketten.
Vorher natürlich schauen ab wann in dem Array kein sinnvolles eichen mehr steht.
Oftmals gibt es bei Geräten eine "Ende-Kennung" (z.B. EOL o-ä.)

Das ist jetzt nicht der optimale Rat, aber vielleicht ein Ansatz für Dich.

Bei weiteren Fragen.. gern.

Grüße
CaOd

Hi,

es gibt in der Kommunikation einen Header an dem man sich halten muss.

Es ist zu erkennen welche Antwort gekommen ist. Steuerzeichen bzw. definierte Präfix/Sufix sind auch vorhanden. Den Stream zu erkennen wo er anfängt und aufhört auch kein Problem.

Hier kann ich anhand einem UDINT die Funktionsantwort erkennen. Daraus kann ich ableiten um welchen Datenblock es sich handeln würde.

Die Kommunikation TcpIP und die Logik vom Gerät ist innerhalb einer Instanz zu implementieren.

Ich habe da keine Möglichkeit weitere DBs im Projekt außerhalb der Instanz anzulegen um generell auch darauf direkt zu zugreifen. Das ist leider durch eine Programmierrichtlinie verboten

Ist es trotzdem möglich innerhalb dieser Instanz die "Deserialisierung" in einer gewissen Art und weise umzusetzen? Der Aufwand wäre mir egal. Es geht mir hier um eine Sinnvolle und verständliche Umsetzung wie ich anhand einer Größe jeglichen Datentyp aus einem ArrayBuffer deserialisieren/Konvertieren kann.

Am besten natürlich direkt in Bezug zum UDT. Wenn es sogar so wäre das ein UDT rein theoretisch unter Umständen nur ein BOOL hätte wäre das von Prinzip egal. Das wäre so zu sagen mein Pseudo DB, auch wenn er nicht der Speicherhaltung des DBs entspricht. Aber dieser UDT wird ja auch irgendwo deklariert. Hier in dem Fall in einer Instanz.

Aber gesprochen könnte man auch sagen das entspricht einer Teil Antwort meiner Schnittstelle, oder auch indirekt es ist in dem Moment die Schnittstelle.

Gibt es da noch weitere Ansätze wo man sowas realisieren kann.

Ich kann mir gerade nicht vorstellen das ich der einzige auf der Welt bin der jemals solch eine Anforderung hat.

Ich finde es eh sehr befremdlich wie der Umgang der Speicherbereiche in der Siemens Welt umgegangen wird. Aber gut das ist ein anderes Thema, was sonst hier sehr weit ausufern würde.

Gruß

Hallo MacToolz,

wenn Du keine weiteren DB's erstellen darfst, dann packe alle Möglichkeiten in die Instanz Deines FB's.

Ich würde für jede Funktionalität einen UDT anlegen.
Damit verringerst Du Dir bei Änderungen den Aufwand.

Ich würde es folgendermaßen aufbauen

• Array als Empfangspuffer
• UDT Funktionalität 1
• UDT Funktionalität 2
  
• ....

Das it wirklich richtig Aufwand, aber am Ende lohnt es sich, da alles in  einem FB ist.
Vielleicht kannst Du für die Kopierfunktion etc. noch "Unterfunktionen" erstellen.

Viel Erfolg beim Programmieren

Grüße
CaOd

Hi und guten Morgen,

den Weg das jede Funktionalität ein UDT entspricht bin ich schon gegangen.

Wo ich gerade das Problem habe dann die Daten entsprechend richtig in den UDT zu deserialisieren.

Den Header aus den ersten Byte Informationen zu zerlegen und bestimmen ist nicht das Problem, da hier keine String Datentypen vorkommen.

Nehmen wir folgenden UDT an als Muster ...

Payload-Teil ......

4 x dwDWORD

10 x INT

4x String[200]

7000 x LReal

4 x String[200]

Ich habe das Problem wie ich jetzt z.B. in diesen UDT entsprechend aus meinem Byte Buffer kopiere.

Zu einem ja auch weil 7000 LReal Werte vorhanden sind, am besten soll in einem Kopieraufruf kopiert werden , ohne das am besten in einer Schleife vorzunehmen.

Des weiteren ist das Problem der Siemens String Datentyp. Wenn ich z.B. die Siemens Deserialize Funktion nehme, dann werden z.B. 202 Byte aus dem Deserialize als Rückgabe angegeben, nicht 200.

Der Siemens kopiert diese beiden Bytes mit obwohl wir im "optimierten Baustein Zugriff" die Einstellung ist.

Von der Logik her müsste ich in Bezug auf unseren Muster UDT 

16 Byte kopieren

20 Byte kopieren

800 Byte kopieren

56000 Byte koperen

800 Byte kopieren

Am schönsten wäre natürlich komplett den UDT zu deserialisieren, da ich ja aber die Funktionsantwort kennen, könnte ich auch jeden Datentyp seperat kopieren.

Also im eigentlichen liegt das Problem in der Anzahl der Daten und der String-Datentyp. Weil, wenn ich mit Deserialize arbeite und den Rückgabewert als Offset nutze, für die Position in meinem Byte Array, bin ich beim ersten String-Datentyp um 2Byte verschoben.

Kannst du mir da im groben folgen ?

Gruß

Hallo mactoolz,

danke für die ausführliche Erklärung Deines "Problems".

Ich teile Deine Meinung mit der Datenmenge. Diese ist sehr groß für die Kommunikation.
Werden hier immer alle Daten (z.B. 7000 LReals) benötigt?

Kann man diese Datenmenge irgendwie verkleinern?

Die andere Frage ist, welche CPU ist hier im Einsatz?
Bei einem Open-Controller könnte man hier die Datenbearbeitung in ein C-Programm "abgeben.

Gibt es hier für Dich Möglichkeiten?

Grüße
CaOd

mactoolz

Nehmen wir folgenden UDT an als Muster ...

Payload-Teil ......

4 x dwDWORD

10 x INT

4x String[200]

7000 x LReal

4 x String[200]

Ich habe das Problem wie ich jetzt z.B. in diesen UDT entsprechend aus meinem Byte Buffer kopiere.

Zu einem ja auch weil 7000 LReal Werte vorhanden sind, am besten soll in einem Kopieraufruf kopiert werden , ohne das am besten in einer Schleife vorzunehmen.

Des weiteren ist das Problem der Siemens String Datentyp. Wenn ich z.B. die Siemens Deserialize Funktion nehme, dann werden z.B. 202 Byte aus dem Deserialize als Rückgabe angegeben, nicht 200.

Der Siemens kopiert diese beiden Bytes mit obwohl wir im "optimierten Baustein Zugriff" die Einstellung ist.

Von der Logik her müsste ich in Bezug auf unseren Muster UDT 

16 Byte kopieren

20 Byte kopieren

800 Byte kopieren

56000 Byte koperen

800 Byte kopieren

Am schönsten wäre natürlich komplett den UDT zu deserialisieren, da ich ja aber die Funktionsantwort kennen, könnte ich auch jeden Datentyp seperat kopieren.

Also im eigentlichen liegt das Problem in der Anzahl der Daten und der String-Datentyp. Weil, wenn ich mit Deserialize arbeite und den Rückgabewert als Offset nutze, für die Position in meinem Byte Array, bin ich beim ersten String-Datentyp um 2Byte verschoben.

Gruß

Hi.

Für Strings würde ich die Funktion "Chars_TO_Strg" verwenden. Anbei ein Screenshot wie das eigentlich funktionieren sollte.

Mfg
mm76

P.S. Wenns hilft, würde ich mich über eine pos. Bewertung freuen :-)

Hier noch der SCL-Code...

Einfach *.txt in *.scl umbenennen und als externe Quelle einfügen.