TIA Variant auf Struct

[MaximilianBauer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich will einen Struct haben in dem mehrere gleiche UDTs verwendet werden.
Hierfür könnte ich zwar ein Array nehmen, ich will aber im Programm diesen Unterelementen fixe Namen geben können.

Nun will ich aber per Index auf Unterelement zugreifen, das optimalerweise über einen Baustein und als Variant übergeben.

Heißt:
Baustein kriegt Index, die Struktur und ein EinzelUDTElement als INOUt, Baustein schreibt mir den gewählten Index auf mein Einzelelement.

Wie setzt ich das um, ich hab nur Ideen die sich viel zu hacky anfühlen, wie z.B. als Variant zu Bytearray serializen, über UDT Länge und Index meine relevanten Bytes wieder deserializen und so das Einzelelement rauszukriegen.

 

[Botimperator]

Per Index direkt in einem Struct Elemente zu selektieren geht nicht direkt.
Du könntest per Case-Anweisung den Index auswerten und jeweils den gewählten UDT einer Refernz zuweisen ("?=" und "REF_TO datentyp"), welche du wiederrum an den verarbeitenden Code übergibst.

 

[MaximilianBauer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Per Index direkt in einem Struct Elemente zu selektieren geht nicht direkt.
Du könntest per Case-Anweisung den Index auswerten und jeweils den gewählten UDT einer Refernz zuweisen ("?=" und "REF_TO datentyp"), welche du wiederrum an den verarbeitenden Code übergibst.

Es geht eben recht sicher, ich hab einen Know How geschützten Baustein vor mir der eben genau das macht, nur ich weiß eben nicht wie

Meine Lösung funktioniert zwar ist aber etwas zu "lustig" für meinen Geschmack und die vom besagten Baustein wirkt sauberer.
Die übergibt die Variant auch als Input, wohingegen ich die als INOut übergebe da ich nach dem Deserialisieren wieder direkt reinschreibe.

 

[Oberchefe]

Oder doch ein Array nehmen und den Index per Konstante mit sprechendem Namen definieren.

 

[Larry Laffer]

Warum defi nierst du den IN-Parameter deines Bausteins nicht vom Typ (Unter-Typ) des UDT's den du übergeben willst ? Dann hast du ohne großem Hick-Hack Zugriff auf die Unterelemente davon ...

 

[MaximilianBauer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum defi nierst du den IN-Parameter deines Bausteins nicht vom Typ (Unter-Typ) des UDT's den du übergeben willst ? Dann hast du ohne großem Hick-Hack Zugriff auf die Unterelemente davon ...

Ich will die UDTs selbst direkt in der Struktur lassen ohne extra UDT der nochmal alles beinhaltet (Zugriff über Index wird so auch nicht sonderlich leichter)
Sollte eigentlich ein wiederverwendbarer FB werden der immer den selben UDT nutzt aber eben die Struktur anders und benannt ist, was den extrigen UDT wieder rauswirft

Folgender Code wäre mein Ansatz, aber das viele kopieren ist zu unsauber, idealerweise wäre es hier dann sowas wie einen Pointer auf die Einträge selbst setzen zu können, ohne das ich alles kopieren muss:

// laden
#ret_val := Serialize(SRC_VARIABLE := #Struct, DEST_ARRAY => #tempbytes, POS := #pos);
#current := #tempUdts[#Index]; // temp udts sind mit AT überlagert auf obrigen ByteArray

// platzhalter
// gewählter Eintrag kann frei manipuliert werden
// wird auch als INOUT rausgeschalten sodass er extern bearbeitet werden

// speichern
#tempUdts[#Index] := #current;
#ret_val:=Deserialize(SRC_ARRAY := #tempbytes, DEST_VARIABLE => #Struct, POS := #pos);

 

[Botimperator]

Es geht eben recht sicher, ich hab einen Know How geschützten Baustein vor mir der eben genau das macht, nur ich weiß eben nicht wie

Ist das ein FB oder FC?
Ist "Optimierter Bausteinzugriff" in den Bausteineigenschaften angehakt?
In Classic kenne ich solche Funktionen noch mit zusammengebastelten Pointern...

Wie setzt ich das um, ich hab nur Ideen die sich viel zu hacky anfühlen, wie z.B. als Variant zu Bytearray serializen, über UDT Länge und Index meine relevanten Bytes wieder deserializen und so das Einzelelement rauszukriegen.

Ich schätze mal genauso wird der das machen.

Folgender Code wäre mein Ansatz, aber das viele kopieren ist zu unsauber, idealerweise wäre es hier dann sowas wie einen Pointer auf die Einträge selbst setzen zu können, ohne das ich alles kopieren muss:

So schlimm finde ich deinen Ansatz jetzt gar nicht...
Wenn du nen Zugriff haben willst, ohne das Element deiner Begierde durch die Gegend zu kopieren, wirst du was mit REF_TO stricken müssen.
Ich überleg grade ob man mit GetSymbolName + REF_TO was machen könnte (。﹏。*)

 

[Larry Laffer]

Ich will die UDTs selbst direkt in der Struktur lassen ohne extra UDT der nochmal alles beinhaltet (Zugriff über Index wird so auch nicht sonderlich leichter)
Sollte eigentlich ein wiederverwendbarer FB werden der immer den selben UDT nutzt aber eben die Struktur anders und benannt ist, was den extrigen UDT wieder rauswirft

Du musst das doch auch nicht herausnehmen. Du kannst dem FB doch (wenn es immer derselbe UDT-Untertyp ist) dann das Array-Element am IN übergeben. Der IN ist dann vom Typ deines Unter-UDT und du übergibst dann dem Baustein entsprechend, wie von mir genannt.
Alternativ könntest du auch den kompletten UDT als IN nehmen und du übergibst dann zusätzlich noch den zu verwendenden Index. Beides hat den Vorteil, dass du ganz grundsätzlich eben nichts hin und her-stricken musst ... Das spart dann auch CPU-Leistung ...

 

[MaximilianBauer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du nen Zugriff haben willst, ohne das Element deiner Begierde durch die Gegend zu kopieren, wirst du was mit REF_TO stricken müssen.

Ref_TO wird leider wegen der AT-Überlagerung nicht funktionieren, da nicht optimiert.

 

[MaximilianBauer]

Ist das ein FB oder FC?
Ist "Optimierter Bausteinzugriff" in den Bausteineigenschaften angehakt?
In Classic kenne ich solche Funktionen noch mit zusammengebastelten Pointern...

Optimiert und nutzt auch Variant weswegen ich ja den gleichen Ansatz nehmen will weil mir das so eigentlich gefällt

 

[MaximilianBauer]

Du musst das doch auch nicht herausnehmen. Du kannst dem FB doch (wenn es immer derselbe UDT-Untertyp ist) dann das Array-Element am IN übergeben. Der IN ist dann vom Typ deines Unter-UDT und du übergibst dann dem Baustein entsprechend, wie von mir genannt.
Alternativ könntest du auch den kompletten UDT als IN nehmen und du übergibst dann zusätzlich noch den zu verwendenden Index. Beides hat den Vorteil, dass du ganz grundsätzlich eben nichts hin und her-stricken musst ... Das spart dann auch CPU-Leistung ...

Glaube wir missverstehen uns hier, ich will den IN als lose Struct übergeben und eben nicht als UDT

Unoptimiert wäre das ganze wahrscheinlich sauberer Lösbar weil ich dann immer direkt über die globale Adresse direkt auf das benötigte Element zugreifen kann.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe dich schon verstanden - ich würde es halt so nicht machen ... deshalb hatte ich dir meins vorgeschlagen ...

 

[Botimperator]

Ich habe dich schon verstanden - ich würde es halt so nicht machen ... deshalb hatte ich dir meins vorgeschlagen ...

Es geht eben recht sicher, ich hab einen Know How geschützten Baustein vor mir der eben genau das macht, nur ich weiß eben nicht wie

Unser Thema ist ja das Reverse-Engineering des KnowHow geschützten Bausteins.
Auch wenn der Vorschlag von @Larry Laffer gut funktionieren würde, wäre eine Änderung des Konzepts nicht Ziel der Fragestellung.

Mal zusammenfassend was wir bisher über den Baustein wissen:
Input-Parameter:
* Ein Variant, der eine STRUCT, welche eine beliebige (?) Menge an Variablen eines UDT enthalten kann, erwartet.
* Eine Index-Variable (INT/DINT?)
InOut-Parameter:
* Ein UDT des Typs welcher auch in der Struct vorhanden ist. Diese wird vom Baustein aber nur mit dem selektierten Element beschrieben, kein schreiben aus der Variable am InOut zurück auf das STRUCT-Element (richtig?).

Es ist ein optimierter Baustein.
Wäre noch die Frage ob es ein FB oder ein FC ist @MaximilianBauer
Un welche TIA Version bzw. auf welcher SPS (incl. Firmware) ist der KnowHow geschützte Baustein lauffähig?

Ref_TO wird leider wegen der AT-Überlagerung nicht funktionieren, da nicht optimiert.

AT würde auch in einem optimierten FB funktionieren, sobald man "im IDB setzen" parametriert.

Eine Sicht kann allerdings keinen Variant überlagern, also scheidet das wiederrum aus.

 

[MaximilianBauer]

Es ist ein optimierter Baustein.
Wäre noch die Frage ob es ein FB oder ein FC ist @MaximilianBauer
Un welche TIA Version bzw. auf welcher SPS (incl. Firmware) ist der KnowHow geschützte Baustein lauffähig?

Es ist ein FB.
Die Dokumentation zum Baustein sagt auch das er intern serialize/deserialize nutzt (kann diese leider nicht teilen)
Habe den in V17 genutzt, Firmware laut Doku ab 2.0

Unser Thema ist ja das Reverse-Engineering des KnowHow geschützten Bausteins.
Auch wenn der Vorschlag von @Larry Laffer gut funktionieren würde, wäre eine Änderung des Konzepts nicht Ziel der Fragestellung.

Mal zusammenfassend was wir bisher über den Baustein wissen:
Input-Parameter:
* Ein Variant, der eine STRUCT, welche eine beliebige (?) Menge an Variablen eines UDT enthalten kann, erwartet.
* Eine Index-Variable (INT/DINT?)
InOut-Parameter:
* Ein UDT des Typs welcher auch in der Struct vorhanden ist. Diese wird vom Baustein aber nur mit dem selektierten Element beschrieben, kein schreiben aus der Variable am InOut zurück auf das STRUCT-Element (richtig?).

Es ist ein optimierter Baustein.
Wäre noch die Frage ob es ein FB oder ein FC ist @MaximilianBauer
Un welche TIA Version bzw. auf welcher SPS (incl. Firmware) ist der KnowHow geschützte Baustein lauffähig?


AT würde auch in einem optimierten FB funktionieren, sobald man "im IDB setzen" parametriert.
Anhang anzeigen 89640
Eine Sicht kann allerdings keinen Variant überlagern, also scheidet das wiederrum aus.

Ja aber ich setze meiner Variante folgendes:

Ich kann dann auf das UDT-Array nichtmehr mit Ref_To zugreifen da ich hier überlagere.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

... Die Dokumentation zum Baustein sagt auch das er intern serialize/deserialize nutzt ...

Mehr braucht es auch nicht.

1. Größe des UDT ermitteln (SERIALIZE)
2. Daten komplett einlesen und in Puffer schreiben (SERIALIZE)
3. Datensatz INDEX ausgeben (DESERIALIZE)

Nachteilig ist halt der mehr oder weniger große Puffer und das Umschaufeln der ganzen Daten. Der Puffer kann übrigens im TEMP-Bereich liegen. Ein externer ARRAY-DB ginge sicherlich auch. Es funktioniert auch, wenn man für beide Parameter VARIANT verwendet, also ganz ohne UDT. Damit ist man noch flexibler. Die Aktualparameter können dann sonst was sein. Ein weiterer Nachteil ist eine nicht mögliche Typprüfung, welche mit ARRAY/UDT möglich wäre.