ManAtWork!
Level-1
- Beiträge
- 89
- Reaktionspunkte
- 1
Den globalen DB auch als UDT erstellen und den DB direkt aus diesem UDT erstellen (bei Typ anstatt Global-DB den UDT auswählen).Ich habe einen PLC-Datentyp mit zwei UDINT werten erstellt. Den habe ich in einen Globalen DB als Array angelegt.
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....nur kann ich ihm nun keinen "HMI-Datentyp" zuweisen...
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... 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...
30 boolsche Variablen sind und bleiben 30 boolsche Variablen, auch am HMI. Oder verstehe ich deine Frage nicht?.. Bei normalen Datentypen (zb. Bool) ist das nicht so?...
So wie ich das sehe, hast du gar nichts falsch gemacht... Was mache ich falsch?...
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... 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...
Die darin enthaltenen Variablen sind im Wesentlichen genauso einzeln nutzbar, wie einzeln angelegte Variablen (Ausnahmen bestätigen wie immer die Regel :rollWas 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.
Das halte ich für ein Gerücht, welches Du noch einmal überprüfen solltestDer 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 braucht man doch immer, wenn man ein "ARRAY [...] OF Datentyp" verwenden will.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?
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... Das halte ich für ein Gerücht, welches Du noch einmal überprüfen solltest..
Ich konnte da bisher nichts Negatives feststellen.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 benutze dafür verschiedene UDTs in diesem Koppel-DB, je nach Zweck.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.
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.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).
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.. 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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?