TIA Zugriff auf eine variable Anzahl gleicher UDTs in einem UDT aus einem FB heraus

[AVPEng]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Ich habe einen UDT_Button. Dieser repräsentiert einen Button in der HMI. In jeder Einheit (Station) gibt es mehrere dieser Buttons. Diese UDT_Button sind jetzt in einem UDT zusammengefasst, d.h.
UDT_Buttons_Stationx
- Button_Fkt1 : UDT_Button
- Button_Fkt2 : UDT_Button
- Button_Test : UDT_Button
- Button_Reset : UDT_Button
usw.
Die Anzahl der UDT_Buttons kann von Station zu Station unterschiedlich sein.
Jetzt muss aber jeder UDT_Button von einem FB vorverarbeitet (Flankengenerierung etc.). ich möchte aber nicht jeden einzelnen UDT_Button aufrufen, sondern z.B. den UDT_Buttons_Stationx als Variant übergeben und dann im FB die Anzahl der UDT_Buttons bestimmen und durch diese iterieren und vorverarbeiten.
In der HMI habe ich jetzt schöne namen um auf die UDTs zuzugreifen.

Was ich nicht hinbekomme ist der Zugriff in dem FB für die Vorverarbeitung. ich kann den UDT_Buttons_Stationx als Variant übergeben aber komme nicht auf die darin liegenden Elemente zurück. Ich bekomme immer nur das erste Element im UDT_Buttons_Stationx aber nicht die weiteren, da es kein Array ist. ich möchte aber als Variant übergeben, da ich wegen unterschiedlicher Länge nur einen FB Vorverarbeitung haben möchte
Mit einer S7-300 wurde das mit Pointer gemacht (Länge eines Elements war ja bekannt.
Normaler weise würde ich in TIA keinen UDT_Buttons_Stationx machen sondern ein Array of UDT_Buttons, dann kann ich einfach im FB die Länge des Arrays bestimmen und durch iterieren. Im Programm greife ich über vordefinierte Konstanten als Index auf die UDT_Buttons zu.

Das Problem bzw. die Unübersichtlichkeit ist dann auf der HMI (WinCC Prof V16) Seite. Hier kann ich nicht mit Konstanten als Index auf die Arrays zugreifen. ich muss wissen, dass UDT_Buttons_Station[1] die Taste für die Fkt1 ist usw. Da enstehen schnell Fehler und es leidet die Lesbarkeit


noch zur Info es sollen optimierte Bausteine sein, d.h. eine AT Lösung geht auch nicht.

Hat hier einer eine Idee, wie dies gemacht werden kann?

Danke im Voraus

Wolfgang

 

[TP-Inc]

Hallo, du könntest deinen FB mit einen "Sternchen-UDT" in der Schnittstelle deklarieren. In etwa so: InOut_Buttons: Array
[*] of UDT_Buttons. Dann kannst du zur Laufzeit bestimmen wieviel Elemente aufgeschalten wurden (Anweisung LOWER_BOUND/UPPER_BOUND) und bestimmte Programmteile ausführen. Die Reihenfolge der Buttons muss für dein Vorhaben ja sowieso fix sein. Du kannst dann halt nicht UDT_Buttons_StationX verwenden, sondern für jede Station ein ARRAY UDT_Button deklarieren.

Oder du kopierst deinen FB halt, und änderst ihn. Wieviele verschidene Varianten von Stationen gibts den?

Edit: Ich hab wohl bei der Hälfte der Frage zu lesen aufgehört...

Du könntest dich mal zum Thema Referenzen einlesen. Du kannst in deinem FB alle möglichen UDT_Button_StationX deklarieren und per Zuweisungsversuch (oder TYPE_OF) den tatsächlich aufgeschaltenen Datentyp finden, und mit dem weiterarbeiten.

https://www.spshaus.ch/files/inc/Do...tware/Technische_Folien_TIA_Portal_V15_de.pdf

Such mal in der Hilfe nach REF_TO

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

noch zur Info es sollen optimierte Bausteine sein, d.h. eine AT Lösung geht auch nicht.

noch zur Info:
AT geht auch im optimiertem FB, wenn man die Remanenz auf "Im IDB setzen" einstellt!

 

[hucki]

Hallo, du könntest deinen FB mit einen "Sternchen-UDT" in der Schnittstelle deklarieren. In etwa so: InOut_Buttons: Array[*] of UDT_Buttons. Dann kannst du zur Laufzeit bestimmen wieviel Elemente aufgeschalten wurden (Anweisung LOWER_BOUND/UPPER_BOUND) und bestimmte Programmteile ausführen. Die Reihenfolge der Buttons muss für dein Vorhaben ja sowieso fix sein.

AT geht auch im optimiertem FB, wenn man die Remanenz auf "Im IDB setzen" einstellt!

Ich mache das mit einem Mix aus beiden:

Ich habe ein Struct mit immer gleichen udt, um die aussagekräftigen Symbole zu haben.
Dieses Struct sichte ich im FB per AT in ein Array of udt.
Dieses Array kannst Du z.B. an einen Baustein InOut vom Typ Array[*] of udt übergeben.
In diesem Baustein kannst Du die Arraygrenzen mittels LOWER_BOUND und UPPER_BOUND bestimmen und diese an eine FOR-Schleife zum Abarbeiten der Arraymember übergeben.

Also:
UDT_Buttons_Stationx (Struct mit x UDT_Button)
AT Array[1..x] of UDT_Button
Übergabe an Array[*] of UDT_Button = verschieden große Arrays je nach Station
FOR #i := LOWER_BOUND TO UPPER_BOUND ...


Ein Beispiel für einen Baustein mit solch verschiedenen Arraygrößen findest Du hier: Alternierungsbaustein beliebig vieler pumpen

 

[Ralle]

Ich mache das mit einem Mix aus beiden:

Ich habe ein Struct mit immer gleichen udt, um die aussagekräftigen Symbole zu haben.
Dieses Struct sichte ich im FB per AT in ein Array of udt.
Dieses Array kannst Du z.B. an einen Baustein InOut vom Typ Array
[*] of udt übergeben.
In diesem Baustein kannst Du die Arraygrenzen mittels LOWER_BOUND und UPPER_BOUND bestimmen und diese an eine FOR-Schleife zum Abarbeiten der Arraymember übergeben.

Also:
UDT_Buttons_Stationx (Struct mit x UDT_Button)
AT Array[1..x] of UDT_Button
Übergabe an Array
[*] of UDT_Button = verschieden große Arrays je nach Station
FOR #i := LOWER_BOUND TO UPPER_BOUND ...


Ein Beispiel für einen Baustein mit solch verschiedenen Arraygrößen findest Du hier: Alternierungsbaustein beliebig vieler pumpen

Lohnt sich das eigentlich, blicken das "Fremd"-Programmierer und geht das Array
[*] eigentlich zu Lasten der Zykluszeit?
Wie sieht es mit der Fehlersuche aus? Ist das online beobachtbar?

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lohnt sich das eigentlich

Jein.
Lesbarkeit vs. Variablität.

Mir fehlt für diese Structs auch immer das FOR EACH von anderen Sprachen, um mir wenigstens die AT-Array-Geschichte zu sparen.

blicken das "Fremd"-Programmierer

werde ich sehen, wenn es demnächst in die Schweiz geht.

und geht das Array
[*] eigentlich zu Lasten der Zykluszeit?

Konnte nix Großartiges feststellen.
Hab' aber auch nicht explizit danach geschaut.

Wie sieht es mit der Fehlersuche aus? Ist das online beobachtbar?

So gut und schlecht wie jede andere FOR-Schleife.

 

[AVPEng]

Danke für die Antwort.

Die Lösung ist sehr interessant. Aber entweder habe ich sie nicht richtig verstanden oder sie passt nicht genau.
Ich muss aber dazu den UDT-Buttons_Stationx in dem statischen Bereich eines FB deklarieren ansonsten funktioniert das Mapping mit dem AT Befehl nicht. Normalerweise verwende ich für HMI-Zugriffe globale DBs.
Aber ich kann den UDT_Buttons_Stationx nur mit Variant an einen FB übergeben und dann komme ich nicht weiter diesen Variant an die STAT Variable zu kopieren.
Ich möchte nicht für jede Station (ca. 30) mit unterschiedlichen Buttons einen eigenen FB erstellen.
Oder habe ich was falsch verstanden.

Gruß

 

[hucki]

Oder habe ich was falsch verstanden.

Ja, hast Du.

Den UDT-Buttons_Stationx erstellst Du ganz normal im GDB. Der ist ja vor allem für das HMI.

Ja, Du benötigst einen (einzigen Zwischen-) FB zum Verarbeiten sämtlicher UDT-Buttons_Station. Wo willst Du die auch sonst verarbeiten?

AT kann nicht nur im STAT sondern auch im IN, OUT und/oder INOUT erstellt werden. Halt alles was im IDB zu finden ist.

In diesem Zwischen-FB musst Du für jeden Deiner UDT-Buttons_Station eine Variable von diesem udt und eine Sicht AT vom Typ Array darauf erstellen.
Den UDT-Buttons_Stationx aus dem GDB übergibst Du an die Variable und deren Sicht dann an Deinen eigentlichen Verarbeitungsbaustein.




Stell doch mal eine Quelle des UDT_Buttons_Stationx und des FBs zur Verarbeitung zur Verfügung, dann schau ich mal, ob ich Dir ein Beispiel dazu machen kann.

 

[AVPEng]

Zuviel Werbung?
-> Hier kostenlos registrieren

AT kann nicht nur im STAT sondern auch im IN, OUT und/oder INOUT erstellt werden. Halt alles was im IDB zu finden ist.

Ein AT Befehl kann bei einer INOUT Variable die als UDT oder Struct definiert ist nicht verwendet werden. Es gibt dort kein "Im IDB setzen". TIA betrachtet dies auch als Pointer.
Nur bei Elemtarvariablen können als INOUT mit AT eine neue Sicht erstellt werden.

Da ich die HMI Variablen sowohl Lesen als auch Schreiben muss bleibt nur ein InOut

Das ist mein Problem.
Ich habe noch keine Möglichkeit entdeckt um in UDT_Button Schrittweite durch eine Ansammlung von UDT_Buttons zu iterieren.

 

[hucki]

Ok, das Problem habe ich so nicht.

Bei mir sind die Sachen vom HMI bzw. Hardware für den FB reine INs und die verarbeiteten Ergebnisse OUTs. Die sind in meinen udts nicht gemixt.
Daher kann ich das bei mir per MOVE an/von gesichteten STAT-Variablen übergeben.

 

[Onkel Dagobert]

Sehr schade, dass es hierfür noch immer keine Lösung gibt. Wolfgang, was dir im Wege steht, ist der Zwang nach optimierter Programmierung und nach UDT of UDT bzw. no ARRAYs. ​

.. Das Problem bzw. die Unübersichtlichkeit ist dann auf der HMI (WinCC Prof V16) Seite. Hier kann ich nicht mit Konstanten als Index auf die Arrays zugreifen. ich muss wissen, dass UDT_Buttons_Station[1] die Taste für die Fkt1 ist usw...

Dass man jedem ARRAY-Eintrag einen eigenen Kommentar verpassen kann, der auch bei Änderungen des ARRAYs erhalten bleibt. ist dir bekannt? Dieser Kommentar wird auch an die HMI-Variablen vererbt. Man kann damit ganz gut klar kommen. Ich kenne allerdings nur Advanced, hoffe bei Prof ist es nicht anders.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dieser Kommentar wird auch an die HMI-Variablen vererbt. Man kann damit ganz gut klar kommen. Ich kenne allerdings nur Advanced, hoffe bei Prof ist es nicht anders.​

Da melde ich mal pauschal ZWeifel an! Wäre nicht gerade typisch für Siemens.
Werde ich nächste Woche mal testen.​

 

[Onkel Dagobert]

Ralle, woran zweifelst du? "Verebung" meine ich im einfachstem Sinne des Wortes. Und ich rede vom Kommentar. Der Kommentar der SPS-Variable wird in den Kommentar der HMI-Variable übernommen. Das ist auch bei Arrays so. Das ist doch voll normal, oder nicht?

Was nicht selbstverständlich, aber überaus nützlich ist, ist die Tatsache, dass man für jeden ARRAY-Eintrag einen separaten Kommentar vergeben kann, und dass dieser auch bei Änderungen des Arrays erhalten bleibt. Das war nicht immer so, glaube erst ab V14 oder V15. Meinst du das?

 

[Ralle]

Ralle, woran zweifelst du? "Verebung" meine ich im einfachstem Sinne des Wortes. Und ich rede vom Kommentar. Der Kommentar der SPS-Variable wird in den Kommentar der HMI-Variable übernommen. Das ist auch bei Arrays so. Das ist doch voll normal, oder nicht?

Was nicht selbstverständlich, aber überaus nützlich ist, ist die Tatsache, dass man für jeden ARRAY-Eintrag einen separaten Kommentar vergeben kann, und dass dieser auch bei Änderungen des Arrays erhalten bleibt. Das war nicht immer so, glaube erst ab V14 oder V15. Meinst du das?

Nein, ich zweifle nur daran, dass Siemens es hinbekommen hat, das WinCC Advanced und WinCC Prof. hier "das Selbe" tun und können. Wäre toll, ist aber extrem selten. Ich schamir das nächste Woche mal bei meinem WinCC Prof. an, bin selbst mal gespannt.