TIA Array of "Eigener Datentyp" im HMI Verknüpfen

ManAtWork!

Level-1
Beiträge
89
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich probiere gerade ein Array of "eigenerDatentyp" mit der HMI zu verknüpfen. Leider funktioniert das nur bedingt.
Ich habe einen PLC-Datentyp mit zwei UDINT werten erstellt. Den habe ich in einen Globalen DB als Array angelegt.

Wenn ich durch Drag&Drop die PLC-Variable nun aus dem DB in die HMI-Variablentabelle einfüge, werden 30 (Größe des Arrays) einzelne HMI-Variablen angelegt.
Bei normalen Datentypen (zb. Bool) ist das nicht so?

Was mache ich falsch?
Habe auch schon einmal einen HMI UDT Typ in der Bib erstellt und freigegeben...aber irgendwie kann ich den trotzdem nicht auswählen oder finde ich nicht.

Grüße
Dominik
 
Zuletzt bearbeitet:
Ich habe einen PLC-Datentyp mit zwei UDINT werten erstellt. Den habe ich in einen Globalen DB als Array angelegt.
Den globalen DB auch als UDT erstellen und den DB direkt aus diesem UDT erstellen (bei Typ anstatt Global-DB den UDT auswählen).
Dann bekommst Du Dein Array (bzw. den kompletten DB) als eine Variable ins HMI, wenn Du als Datentyp dort auch den neuen UDT nimmst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Hucki,

also irgendwie klappt das noch nicht wirklich...und es ist irgendwie auch ziemlich verwirrend das man erst einen Datentyp anlegen muss und dann einen DB aus diesem Datentyp erstellen kann....wieso nicht einfach den Datentyp in einem normalen DB anlegen ???!! :O :D

Also ich habe jetzt einen Datentyp angelegt. Darin ist eine Array of Struct....danach habe ich einen DB aus dem angelegten Datentyp erzeugt (warum auch immer)....jetzt konnte ich in der HMI-Variablentabelle diese angelegte Arraystrutkur tatsächlich aus dem DB als eine HMI-Variable Verknüpfen...nur kann ich ihm nun keinen "HMI-Datentyp" zuweisen...

Unbenannt.JPG
warum ist das denn so umständlich ? :confused::confused::confused: Sorry ich programmiere zum ersten mal und kapier die zusammenhänge noch nicht genau..

Grüße
Dominik
 
Vorweg: Arrays selber sind im HMI nicht als Gesamtvariable verknüpfbar, wie Du ja selbst festgestellt hast. Daher der Umweg über den UDT.

Der Unterschied beim Anlegen besteht nur im erzeugten DB in der SPS mit einer zusätzlichen führenden Variable vor dem Array, die man nicht immer unbedingt haben möchte, weil man dann z.B. längere Variablen-Pfad-Angaben bei der SPS-Programmierung hat.

udt-Variable im Global-DB:
attachment.php


DB aus dem gleichen UDT:
attachment.php



Für das HMI selbst macht das jedoch keinen wirklichen Unterschied:
attachment.php





...nur kann ich ihm nun keinen "HMI-Datentyp" zuweisen...
Den HMI-Datentyp weist TIA automatisch zu, wenn Du 3 Spalten weiter als PLC-Variable den DB aus dem udt oder die udt-Variable (je nachdem, für welche Variante in der SPS Du Dich entschieden hast) auswählst, wie man auf meinem letzten Screenshot sehen kann.


PS:
Mit so einer Gesamtvariable hat man aber nicht alle Möglichkeiten wie bei Einzelvariablen.
Z.B. fehlen Ereignisse bei Wertänderung.
Warum auch immer?!
 

Anhänge

  • udt - hmi.jpg
    udt - hmi.jpg
    23,1 KB · Aufrufe: 242
  • udt - UDB.jpg
    udt - UDB.jpg
    47,7 KB · Aufrufe: 241
  • udt - GDB.jpg
    udt - GDB.jpg
    52,3 KB · Aufrufe: 240
Zuletzt bearbeitet:
Hallo Dominik,

.. Wenn ich durch Drag&Drop die PLC-Variable nun aus dem DB in die HMI-Variablentabelle einfüge, werden 30 (Größe des Arrays) einzelne HMI-Variablen angelegt...
Für mich wäre das absolut ok, nutze ich genau so. Was nützt dir denn am HMI eine Variable, welche das ganze Array oder einen ganzen DB enthält? Statt dessen solltest du die HMI-Variablen besser in verschiedenen Variablentabellen organisieren.

.. Bei normalen Datentypen (zb. Bool) ist das nicht so?...
30 boolsche Variablen sind und bleiben 30 boolsche Variablen, auch am HMI. Oder verstehe ich deine Frage nicht?

.. Was mache ich falsch?...
So wie ich das sehe, hast du gar nichts falsch gemacht.

.. Habe auch schon einmal einen HMI UDT Typ in der Bib erstellt und freigegeben...aber irgendwie kann ich den trotzdem nicht auswählen oder finde ich nicht...
In der Projektnavigation stehen die Datentypen gewöhnlich unter "PLC-Datentypen". Wenn du in der Projektnavigation etwas selektiert hast, dann verwende mal unter "Ansicht" die "Übersicht" (<Crt>+<2>), dann hat man einen besseren Überblick, besonders wenn man Unterordner für Bausteine oder Datentypen nutzt.

Der von hucki vorgeschlagene ARRAY-DB unterscheidet sich von einem GLOBAL-DB u.a. dadurch, dass keine Remanenz möglich ist. Das sollte man beachten!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was nützt dir denn am HMI eine Variable, welche das ganze Array oder einen ganzen DB enthält? Statt dessen solltest du die HMI-Variablen besser in verschiedenen Variablentabellen organisieren.
Die darin enthaltenen Variablen sind im Wesentlichen genauso einzeln nutzbar, wie einzeln angelegte Variablen (Ausnahmen bestätigen wie immer die Regel :roll:).
Nur die Übersicht ist IMHO deutlich besser, da die PLC-Struktur des UDT auch im HMI erhalten bleibt.

Ob ich Variablen in einen DB direkt oder als UDT erstelle, ist die gleiche Arbeit. Der DB muss auch so oder so angelegt werden, nur dass er eine andere Basis hat. Einzig das Anlegen an sich des UDT ist zusätzlich, aber zeitlich unbedeutend.
Dafür habe ich aber für den ganzen DB nur noch eine einzige Variable im HMI anzulegen, anstatt x Hundert. Und das spart für mich wirklich Zeit.
Außerdem führt TIA Änderungen am UDT beim Übersetzen automatisch sofort auch in der HMI-Projektierung in der so angelegten Variable nach.
Ich empfinde das als äußerst angenehm, da nicht per Hand rumfrickeln zu müssen. Auch das spart wieder einiges an Zeit.
Daher setze ich gerade des HMIs wegen DBs auf UDT-Basis ein.



Der von hucki vorgeschlagene ARRAY-DB unterscheidet sich von einem GLOBAL-DB u.a. dadurch, dass keine Remanenz möglich ist. Das sollte man beachten!
Das halte ich für ein Gerücht, welches Du noch einmal überprüfen solltest ;):

attachment.php



Vielleicht meintest Du, dass die Remanenz nur für den gesamten UDT/DB und nicht für die enthaltenen Variablen einzeln auswählbar ist?
Dem ist allerdings wirklich so.
 

Anhänge

  • udt - UDB remanent.jpg
    udt - UDB remanent.jpg
    45,1 KB · Aufrufe: 192
Zuletzt bearbeitet:
Hallo Hucki,

vorneweg schon einmal vielen vielen Dank für deine Ausführliche Erklärung! Es hat jetzt funktioniert und ich bin Happy wie sau :D
Wie du geschrieben hast, ist die Struktur des Arrays nun nicht verloren gegangen und ich habe schön ein HMI-Array wie in deinen Beispielbilder. Auch funktioniert das vergrößern bzw. das verkleinern des Arrays wunderbar und die HMI-Variable wird automatisch mitgezogen. Das ist wirklich sehr praktisch für weitere Projekte...bzw. das erhoffe ich mir davon.

Das mit dem Ereigniss bei Wertänderung habe ich bei diesen Variablen zum Glück nicht aber werde ich im Hinterkopf behalten dank!

ABER ich muss ehrlich sagen, leider bin ich trotzdem irgendwie in dem Stadium "Funktioniert zwar, aber weiß nicht genau warum" und sowas finde ich persönlich immer nervig :D
Auch finde ich es unschön, dass ich für diese Methode zwei Datentypen brauche? Einen mit der eigentlichen Struktur und einen Zweiten indem ich die Struktur als Array anlege?


@Onkel Dabobert: Auch dir vielen Dank. Das mit den verschiedenen Variablentabellen wäre mein nächster Schritt gewesen. Jedoch möchte ich so wenig Variablen-Tabellen wie möglich benutzen. Die Idee war, eine "Globale" Tabelle für die PLC-Verknüpfungen und eine für "Locale" Hmi-Variablentabelle für Variablen die nur von der HMI verwendet werden. So braucht man nicht lange überlegen, wo man anpacken muss. Aber wie gesagt, dies ist mein erstes Projekt und Erfahrungen in der Fehlersuche bzw. mit dem aktiven arbeiten habe ich noch keine.

Mit meiner Aussage "Bei normalen Datentypen (zb. Bool) ist das nicht so?" meinte ich, dass ein ARRAY of Bool auch "zusammenhängend" im HMI verknüpft wird. Also es werden keine 30 HMI-Variablen vom TYP Bool beim reinziehen erstellt (wenn die Arraygröße 30 wäre) sonder eine zusammenhängende Struktur.

Grüße
Dominik
 
Zuletzt bearbeitet:
Auch finde ich es unschön, dass ich für diese Methode zwei Datentypen brauche? Einen mit der eigentlichen Struktur und einen Zweiten indem ich die Struktur als Array anlege?
Das braucht man doch immer, wenn man ein "ARRAY [...] OF Datentyp" verwenden will. :confused: ("ARRAY" ist kein Datentyp)
Bei Arrays von Standard-Datentypen (z.B. ARRAY [...] OF INT) braucht man die Datentypen nicht erklären, die sind schon bekannt. Bei eigenen "benutzerdefinierten" Datentypen muß man auf jeden Fall einmal die Struktur des Datentyps erklären - und das macht am elegantesten als UDP, weil dann kann man den Datentyp mehrfach verwenden ohne jedesmal neu die Struktur erklären zu müssen. Auch falls man den Datentyp tatsächlich nur ein einziges mal verwenden will, so macht der Weg über einen UDT nicht wirklich mehr Arbeit.


Eine Frage @all:
Wenn man so einen Array-DB oder z.B. ein BOOL-Array als ganzes in die HMI-Variablen zieht - behandelt die TIA-Runtime dann das ganze als Array und liest/schreibt bei jedem Zugriff auf ein Element des Array das ganze Array? Bekommt man da nicht zur Laufzeit bei jeder Verwendung total hohe unnötige Kommunikationslast im Tausch gegen einmalige Arbeitszeit-Ersparnis beim Projektieren?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
.. Das halte ich für ein Gerücht, welches Du noch einmal überprüfen solltest ;) ..
Ok, ich war auf den falschen Pfad. Bei ARRAY-DB dachte ich sofort an den Typ "ARRAY-DB". Aber der sieht in der Deklaration auch wieder ganz anders aus. In diesem DB gibt es nichts anderes als ein ARRAY, ohne ein STRUCT davor, fest beginnend mit Index 0 und definitiv ohne Remanenz. Über den Sinn und Zweck schweigt man sich aus. So weit ich weiß, wurde dieser Typ von DB auch hier im weltbesten SPS-Forum nur selten erwähnt. Vielleicht ist so ein DB genau für diesen Anwendungsfall geschaffen worden? Ich meine als Abbild für HMI-Variablen.
 

Anhänge

  • 2018-03-01_112306.png
    2018-03-01_112306.png
    5,8 KB · Aufrufe: 28
Eine Frage @all:
Wenn man so einen Array-DB oder z.B. ein BOOL-Array als ganzes in die HMI-Variablen zieht - behandelt die TIA-Runtime dann das ganze als Array und liest/schreibt bei jedem Zugriff auf ein Element des Array das ganze Array? Bekommt man da nicht zur Laufzeit bei jeder Verwendung total hohe unnötige Kommunikationslast im Tausch gegen einmalige Arbeitszeit-Ersparnis beim Projektieren?
Ich konnte da bisher nichts Negatives feststellen.

Allerdings hab' ich zum Einen auch ein vermutlich eher kleines Projekt und zum Anderen auch nicht gezielt darauf geprüft.


Auch benutze ich nicht einen gesamten HMI-Koppel-DB bzw. -UDT, sondern mehrere nach Funktionen getrennte UDTs (wie in der SPS halt auch), so dass bei Zugriffen darauf meist eh' das Gro (wenn nicht gar alles) des UDT auf der jeweiligen HMI-Seite benötigt wird.
Halt eine IMHO gesunde Mischung aus getrennt und Struktur.
:cool:
 
@PN/DP:
Hi Harald, habe auf deine Frage leider momentan keine Antwort...mein Projekt ist auch gerade noch nicht all zu groß und bin auch erst daran mein Grundgerüst aufzubauen.

Auf deine Frage ist mir jedoch eine gegenfrage aufgekommen:

In einem anderen Beitrag von mir, hast du mir geraten, sogenannte "Koppel DB's" für die Kommunikation zwischen HMI und PLC zu erstellen.
Nun wollte ich jedoch nicht ständig diese Koppel-DB's anfassen und dessen Mapping von Hand erweitern, wenn z.B. neue Variablen benötigt werden.
Deshalb dachte ich mir, ich benutze z.B. ein ARRAY of Bool mit dem namen "einstellungen", der alle Einstellungen der Anlage beinhaltet. Diesen Lege ich im Koppel-DB und identisch in einem FC für das Mapping (Koppel-DB -> DB's) an. Die Größe der jeweiligen "identischen" Arrays würde über eine Konstante erfolgen und die Verknüpfungen der HMI zeigen immer auf den Koppel-DB.
Kommt nun eine Einstellung dazu und das Array wäre z.B. zu klein, könnte man einfach das Array durch die Konstante erweitern und jegliches "angelegen" und "mappen" würde automatisch erfolgen...um es auf die Spitze zu treiben, könnte man sogar noch die HMI-Variable direkt auf das komplette Array des Koppel-DB's (einstellungen) verknüpfen und auch diese würde automatisch angepasst werden.
Nachteil: Man müsste dabei dann mit Variablen arbeiten die immer nur einstellungen[x] heißen würden. (bräuchte man eine Liste in der man schauen kann, welche Einstellung welche Aufgabe hat).

Birgt dieses Vorgehen irgendwelche sonstigen Nachteile? Da du gerade von der Kommunikationslast gesprochen hast?

Grüße
Dominik
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Deshalb dachte ich mir, ich benutze z.B. ein ARRAY of Bool mit dem namen "einstellungen", der alle Einstellungen der Anlage beinhaltet. Diesen Lege ich im Koppel-DB und identisch in einem FC für das Mapping (Koppel-DB -> DB's) an. Die Größe der jeweiligen "identischen" Arrays würde über eine Konstante erfolgen und die Verknüpfungen der HMI zeigen immer auf den Koppel-DB.
Kommt nun eine Einstellung dazu und das Array wäre z.B. zu klein, könnte man einfach das Array durch die Konstante erweitern und jegliches "angelegen" und "mappen" würde automatisch erfolgen...um es auf die Spitze zu treiben, könnte man sogar noch die HMI-Variable direkt auf das komplette Array des Koppel-DB's (einstellungen) verknüpfen und auch diese würde automatisch angepasst werden.
Ich benutze dafür verschiedene UDTs in diesem Koppel-DB, je nach Zweck.
Und dann keine Arrays of Bool, wenn es sich nicht um gleichartige Daten handelt, sondern z.B. eine Bool-Struktur mit sprechenden Variablen-Namen/Symbolen.

So sehen z.B. die beiden UDTs für Standard-Einstellung einer Anlage am HMI verknüpft aus:

attachment.php


Ein UDT für Standard-Einstellungen durch unsere Firma, einer für Benutzereinstellungen. Beide im gleichen DB.
Ob eine Zone vorhanden ist oder nicht, kann ich in einem Array eintragen, da der Arrayindex die Zone angibt. Die Betriebsrichtungen werden dagegen für unterschiedliche Elemente festgelegt, also eine Struktur aus Bools.
Auch Einzelvariablen, die im UDT nachträglich, z.B. in die Struktur "DIR", eingefügt werden, werden von TIA in der HMI-Variablentabelle automatisch nachgepflegt.


Die Verarbeitung der neuen Variablen in der Visulalisierung muss dann meist so oder so per Hand gestaltet werden.


Wichtig ist immer ein anschließendes Gesamtübersetzen des HMI.
Und wenn DBs direkt oder durch UDT-Anpassung geändert werden, werden diese in der Regel beim nächsten Übertragen neu initialisiert!
 

Anhänge

  • UDT - HMI.jpg
    UDT - HMI.jpg
    92,7 KB · Aufrufe: 110
Kommt nun eine Einstellung dazu und das Array wäre z.B. zu klein, könnte man einfach das Array durch die Konstante erweitern und jegliches "angelegen" und "mappen" würde automatisch erfolgen... [...]
Nachteil: Man müsste dabei dann mit Variablen arbeiten die immer nur einstellungen[x] heißen würden. (bräuchte man eine Liste in der man schauen kann, welche Einstellung welche Aufgabe hat).
Genau deshalb verwende ich keine künstlichen Arrays zum "Arbeit sparen", "einfach/automatisch anpassen..." und "PowerTags sparen" in der HMI-Kommunikation (wenn es nicht wirklich Arrays sind), weil durch solche faulen Maßnahmen geht jede symbolische Dokumentation der HMI-Schnittstelle verloren. Man bekommt zusätzlich im SPS-Programm Probleme beim symbolischen Verwenden bzw. Kopieren von Daten in/aus den HMI-Arrays, und das im anderen Thread von Thomas für die Zukunft angedachte direkte Zugreifen auf IDB passt auch nicht zum Array-Ansatz. Meine Meinung: Man sollte immer versuchen, sein Programm hauptsächlich verständlich zu realisieren und nicht hauptsächlich arbeitssparend.

Harald
 
Da stimme ich dir natürlich wieder einmal zu.
Jedoch finde ich auch, dass man bei bestimmten Tätigkeiten nicht all zu streng mit der symbolische Dokumentation sein muss. (bezogen auf meine eigentliche Frage in diesem Thema).

Ich kenne jedoch auch meine Firma und dort ist die Zeit für die Programmierung + Inbetriebnahme immer sehr knapp. Schlussendlich bleibt alles am Programmierer hängen und jeder hat sich davor Zeit gelassen ( Konstruktion - Fertigung - Montage ).
Deshalb setze ich leider auch ein großes Augenmerk auf das Thema "Arbeitssparend" Programmieren.
Ansatz: So viel wie möglich über "Standard"-Listen ins "Grundgerüst" Importieren...Abläufe anpassen...Aufspielen...Inbetriebnehmen...nächste Anlage...:rolleyes::rolleyes:

Grüße
Dominik
 
Zuviel Werbung?
-> Hier kostenlos registrieren
.. Ich kenne jedoch auch meine Firma und dort ist die Zeit für die Programmierung + Inbetriebnahme immer sehr knapp. Schlussendlich bleibt alles am Programmierer hängen und jeder hat sich davor Zeit gelassen ( Konstruktion - Fertigung - Montage ).
Deshalb setze ich leider auch ein großes Augenmerk auf das Thema "Arbeitssparend" Programmieren. ..
Wenn du aber so ganz nebenbei noch dutzende Excel-Listen nachpflegen musst, und in diesen ständig nach irgend welchen Variablen suchsen musst, dann hast du nicht viel gekonnt. Und wehe, die Listen gehen mal ihrer eigenen Wege :ROFLMAO: .
 
Wenn du aber so ganz nebenbei noch dutzende Excel-Listen nachpflegen musst, und in diesen ständig nach irgend welchen Variablen suchsen musst, dann hast du nicht viel gekonnt. Und wehe, die Listen gehen mal ihrer eigenen Wege :ROFLMAO: .

:ROFLMAO::ROFLMAO: Vill hab ich da jetzt auch bisschen übertrieben aber ich denke du weißt ungefähr was ich damit ausdrücken wollte :ROFLMAO::ROFLMAO:

Es werden eben viele Anlagen folgen, die ähnlich Aufgebaut und ähnliche Abläufe/Funktionen besitzen.
Da wäre eben ein gutes "Standard-Gerüst" das man mit wenigen Handgriffen modifizieren kann sehr praktisch.


Naja wie gesagt, ist dass auch mein erstes Programm und das sind alles bis jetzt "Gedankenexperimente"...wie das dann später zum handhaben ist wird sich dann herausstellen.
Da erwartet mich und das Programm noch viel Entwicklung :roll::grin:

Danke an alle !
 
Zurück
Oben