TIA AT Konstrukt vs Slice-Zugriffe

[Gelöschtes Mitglied 117942]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Ich verwende zurzeit noch das AT Konstrukt, welche ich den DB der auf ein UDT referenziert, auf ein Array lege. So ist mir es möglich mit einer FOR-Schleifen jedes ElementUDT(Array-Nr.) routiniert und gleich zu bearbeiten.

Dafür darf der Bausteinzugriff nicht Optimiert sein. Darum bin ich auf der Suche nach einer schlaueren "Optimierte" Lösung.

Wenn ich nach alternativen suche, stosse ich auf die Begriffe: Slice-Zugriffe oder die Systemfunktionen "SCATTER" und "GATHER"

Komme allerdings einfach nicht auf den richtigen Weg oder gibt es keine bessere Möglichkeit ein DB mit UDTs auf ein Array aufzulösen?


Besten Dank & Gruss
_Rob

TIA 16 / CPU-1516F

 

[Thomas_v2.1]

Was ist denn der Grund, warum du über unstrukturiert angelegte Daten in einer Schleife iterieren musst. Könnten die Daten auch direkt als Array angelegt werden, oder besteht eine andere Möglichkeit, das was die Schleife ausführt auch anders zu realisieren?

 

[Gelöschtes Mitglied 117942]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im DB sind 1 bis Const_XXMotoren mit jeweils der gleichen UDT-Struktur aufgeführt, welche derMotorenzustand über OPC UA zur Verfügung stellen. Da der OPC UA Client Symbolischauf den DB zugreift und die Motoren unterschiedliche & eindeutige Namenhaben, ist es deshalb mir nicht möglich ein DB-Array anzulegen.

[FONT=&#10]Mit der Schleife möchte ichbewirken, unabhängig wie viele Motoren das ich habe, sie gleich zu bearbeitenohne dass ich sie verknüpfen muss.
[FONT=&#10][FONT=&#10]Dadurch bleibt derProgrammiergcode übersichtlicher.
[/FONT][SUB][SUP]
[/SUP][/SUB]
[/FONT][/FONT]

 

[Thomas_v2.1]

Und was für Informationen musst du von den Motoren nachträglich einsammeln? Vielleicht können die Funktionen für die Motoren welche diese UDTs beschreiben auch diese Informationen schon bereitstellen.

 

[Gelöschtes Mitglied 117942]

Klar, das wäre das schönste und einfachste. Allerdings wird es einem manchmal nicht einfachgemacht
Einenweiteren Anwendungsfall ist den DB nach dem Motorennamen zu durchsuchen und die Werte über MQTT zu versenden.

Diesalles geht mit AT, ist einfach nicht "Optimiert". Was wiederum vomKunde nicht gern gesehen wird.

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diesalles geht mit AT, ist einfach nicht "Optimiert". Was wiederum vomKunde nicht gern gesehen wird.

AT geht auch im optimierten FB, wenn die Remanenz der überlagerten Variablen auf "Im IDB einstellen" geändert wird.

Weil Temp-Variablen nicht im IDB sind und ein FC erst gar keinen IDB hat, fallen die raus.

 

[qwsayxqay]

Ich hatte vor geraumer Zeit dasselbe Problem.

 

[hucki]

Die beiden aufgelisteten Voraussetzungen für den optimierten Bausteinzugriff gelten ab TIA V16 nicht mehr. Das heißt, du kannst dieses Konstrukt in optimierten Bausteinen ohne Einschränkungen ab V16 verwenden.

Kannst Du das mit V16 näher erklären?

Ich kann in V16 keine Überlagerung AT auf Temp im optimierten FB anlegen...


Ohne "Im IDB setzen" kommen auch Übersetzungsfehler.
(TIA V16 Upd2)

 

[qwsayxqay]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vlt solltest du dir etwas mehr Zeit als 7 min dafür nehmen das Ganze zu implementieren. Man sollte schon wissen wie Serialize und Dezerialize genau funktionieren. Lies die Hilfe. Da steht alles wichtige drin...

 

[hucki]

Entschuldige bitte, wenn ich Deine Aussage zu den Variablen in optimierten Bausteinen falsch verstanden habe.
Ich dachte, die Aussage gilt generell, nicht nur für den optimierten Zugriff durch Serialize/Deserialize.
Daher habe ich um Erläuterung gebeten.

 

[qwsayxqay]

Passt schon. Meine Aussage bezieht sich nur auf Serialize/Deserialize. Bei AT weiß ich es nicht, da ich das noch nie verwendet habe.

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meine Aussage bezieht sich nur auf Serialize/Deserialize.

Hat es einen Grund, dass Du Deine Empfehlung zu den beiden Bausteinen wieder gelöscht hast?

 

[Gelöschtes Mitglied 117942]

Hat es einen Grund, dass Du Deine Empfehlung zu den beiden Bausteinen wieder gelöscht hast?

Würde mich auch interessieren. Hab es leider nicht gesehen, ist bestimmt ein guter Ansatz.

Weiter kann ich im FB die Remanenz für InOut nicht einstellen.

 

[hucki]

Weiter kann ich im FB die Remanenz für InOut nicht einstellen.

Komplexer Datenttyp? Wenn ja, dann CallByRef, also auch nicht im IDB.

InOut übertragen an gleichen STATIC-Datentyp, überlagerten Datentyp bearbeiten und originalen STATIC an InOut zurück übertragen:

statUdt := ioUdt;

// statAtUdt bearbeiten
...

ioUdt := statUdt;

Würde mich auch interessieren. Hab es leider nicht gesehen, ist bestimmt ein guter Ansatz.

Das war der Vorschlag, die optimierten Daten mit Serialize/Deserialize in den überlagerten Datentypen zu übertragen. Der Vorschlag enthielt den Link zum Siemens-Beispiel für Serialize/Deserialize.