WinCC Tia PC Runtime Advanced V17 HMI UDT Array per VBA Skript über Index Variable zugreifen.

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Siemens:
für den Zugriff auf den Wert eines Array-Elements können Sie in VB folgende Syntax verwenden:

SmartTags("ExportData")(0)
oder
SmartTags("ExportData<0>")

leider nicht ganz richtig...
SmartTags("ExportData")(0) ist der Zugriff auf ein Element eines Arrays (dabei wird das gesamte Array gelesen/aktualisiert)
SmartTags("ExportData<0>") da wird der Name einer einzelnen existierenden HMI-Variable zusammengebastelt

Das Problem ist dann eben die Aktualisierung der Variablen Einstellung auf 100ms zyklisch fortlaufend,

ja, prima Lösung. 23000 Variablen alle 100ms aktualisieren, nur weil sie vielleicht einmal am Tag gebraucht werden...

im Script muss man in der For schleife noch einen Wartebefehl einbauen um sicherzustellen das die Variablen mit dem Index aktualisiert werden bevor man sie in die CSV schreiben kann.

das macht zwar das Skript langsamer (und die Anlage womöglich solange unbedienbar), stellt aber eben nicht sicher, dass alle Variablen aktualisiert wurden. Wann WinCC Adv. RT die Variablen aktualisiert, kann man nicht kontrollieren und man erhält auch keine Rückmeldung ob/wann die Variablen aktualisiert wurden. Das geht nur mit Rezeptur-Variablen.

Ich würde in dem Fall den Weg gehen und die Daten "live"schreiben, also die Aktuellen Werte in einen HMI Puffer schreiben, danach 150ms später ein Bit Setzen das Daten bereit sind und damit ein script triggern

Wie willst du Variablen-Werte aktiv ins HMI schreiben? Und wie kannst du sicher sein, dass die Werte 150ms später "im HMI bereit sind"?

Insgesamt mag deine Lösung vielleicht oft funktionieren, aber eben nicht garantiert sicher. Und als Profi für Industrie-Anlagen sollte man doch den Anspruch haben, eine Lösung zu programmieren, die immer funktioniert und nicht nur meistens ... aber immer so tut als ob es einwandfrei geklappt hätte ...

 

[Sir Steel]

Wenn die HMI alle 100ms die Variablen aktualisiert gehe ich davon aus das nach 150-200ms die Variablen aktualisiert wurden.
200ms passte aber nicht ganz zur Anforderung.

Das Problem ist dann eben die Aktualisierung der Variablen Einstellung auf 100ms zyklisch fortlaufen

ja, prima Lösung. 23000 Variablen alle 100ms aktualisieren, nur weil sie vielleicht einmal am Tag gebraucht werden...

Deswegen habe ich davor geschrieben das das gesamte Array gar nicht als HMI variable angelegt werden sollte, sondern nur jeweils eine Struktur als Multiplex Variable. Dies bezieht sich auf die Überschrift (TIA V17) weil die Möglichkeit in der HMI Arrays mit variablen Index zu erstellen erst ab TIA V15.1 möglich ist. Damit sind 20-30 Variablen 100ms zyklisch fortlaufend völlig in Ordnung und im Rahmen.
In meinem Beispielcode ist das so gemacht, weil man es 1mal manuell startet, da weiß man vorher das es lange dauert und es wird noch angezeigt.
Wenn man sowas automatisiert startet kann man ja noch ein PopUp aufrufen und die Restdauer anzeigen und die Ausführung in eine Produktionsfreie Zeit legen, wenn möglich.

Im Beispiel Script wird 200ms gewartet, da muss bei 100ms Aktualisierung der neue Wert da sein. Zur Überprüfung und zum Testen habe ich den Index der For schleife i und im Array eine Vorgangsnummer in die CSV geschrieben. Da kann man auch nachträglich prüfen das die Nummern gleich sind und weiß das auch das richtige Array Element gelesen wurde.

Der Vorteil ist das die größe des Arrays keine Rolle spielt, der nachteil ist die lange Dauer zum Eintragen

Schade ich dachte halt echt mit meinem Skript per Schleife die arrays hochgezählt und fertig. Komisch dass so eine Aufgabe in der heutigen Zeit noch ein Problem darstellt.

Prinzipiell geht es schon, nur nicht optimal.

Alternativ wäre Live direkt beim Prozess einen Eintrag in die csv, das passt aber nicht ganz mit den 200ms weil die Aktualisierung in der HMI länger dauert.
Man könnte auch die Verwaltung in die SPS übergeben und dort die Array Elemente nach und nach an die HMI übergeben zum Eintragen, wäre nur etwas aufwendiger.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Beispiel Script wird 200ms gewartet, da muss bei 100ms Aktualisierung der neue Wert da sein.

Nein, eben nicht, das kann auch mehrere Sekunden dauern oder mit viel Pech auch nie aktualisiert werden. Die RT informiert nicht einfach auswertbar, wenn Variablenwerte nicht aktualisiert wurden. Da hast du das Prinzip der Variablenaktualisierung von WinCC flexible/Comfort/Advanced nicht verstanden.

 

[Sir Steel]

Laut der Siemensbeschreibung


Deswegen habe ich darauf hingewiesen das man die Erfassungsart auf Zyklisch fortlaufend und den Erfassungszyklus auf 100ms in den Einstellungen anpassen muss, weil Standardmäßig Zyklisch im Betrieb 1s angelegt wird.

Ich habe das ja getestet und meine Variante funktioniert, dabei bin ich eben über die Probleme die du beschreibst gestolpert.
Standard Einstellung (Zyklisch im Betrieb 1s) in der csv steht nur 0 weil die die Variablen nie im Bild aufgerufen werden und dementsprechend nicht aktualisiert wurden
Standard Einstellung (Zyklisch fortlaufend 100ms) ohne Wartezeit, hat man in 10-50 Schleifeneinträgen die gleichen Werte drin stehen weil eben die Variablen zwischen drin noch nicht aktualisiert wurden.
Bei "Auf Anforderung" bin ich mir nicht mehr sicher, aber ich glaube es fehlte die Rückmeldung wenn Aktualisierung abgeschlossen ist sodass man im Prinzip das gleiche Problem hatte mit den alten Daten.

In Unified bin ich dann wieder darüber gestolpert weil es die Einstellung "Zyklisch fortlaufend" nicht mehr gibt, dafür kann man mit dem .Read(1) Befehl eine Aktualisierung anstoßen und es wird auf die Rückmeldung gewartet

 

[DeltaMikeAir]

Laut der Siemensbeschreibung

Da steht aber nur, dass sie aktualisiert wird aber nicht, wann die Aktualisierung abgeschlossen ist. Aktualisierungsrate auf 100ms bedeutet noch lange nicht, dass diese in 100ms oder weniger abgeschlossen wurde.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe das ja getestet und meine Variante funktioniert

Wie gesagt, es kann sehr sehr oft funktionieren aber auch mal nicht. Dann wäre es nicht konsistent.

 

[Sir Steel]

Wenn alle 100ms eine Aktualisierung von der HMI angestoßen wird dann muss ja logischerweise dazwischen eine Aktualisierung abgeschlossen werden, sonst macht das ganze Konzept keinen Sinn.

Ich sage auch nicht das es meine bevorzugete Variante ist, sondern gebe es nur als Möglichkeit mit an, weil ich verstehen kann das man meistens keine extra Tools einrichten möchte für die Inbetriebnahme oder Fehler Analyse.

 

[Larry Laffer]

Das Problem dabei ist, wie schon mehrfach genannt, dass du die Aktualisierung der Variablen nicht sicherstellen kannst - jedenfalls nicht mit den Siemens-Visu's. Deshalb würde ich hier einen anderen Weg gehen. Das Aktualisieren von einem Riesenhaufen von Varaiblen in kurzem Zeitraster (100 ms ?) bewirkt dann wahrscheinlich sogar, dass es noch unkontrollierbarer wird - erstens hat die CPU auch noch andere Dinge zu tun und zweitens ist diese Kommunikation ja auch nicht die Einzige die stattfindet - die 100 MBit müssen es ja auch irgendwie hergeben ...

Mein Fazit also : ein PC-Programm, das kontrolliert die Variablen einliest und zwar nur dann wenn es sie auch wirklich haben will ...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe das ja getestet und meine Variante funktioniert,

Nur scheinbar. Nur meistens. Nicht genug getestet.
Z.B. Was macht dein Skript, wenn du die Netzwerkverbindung zur PLC unterbrichst oder wenn der DB mit den Variablen in der PLC gelöscht wird und die Variablen gar nicht mehr existieren? Dann erstellt es die csv-Datei mit irgendwelchen alten oder Initial-Werten und tut so, als wäre alles okay. Vielleicht Monate später braucht der Anwender die Daten und stellt dann fest, dass da nur unbrauchbarer Datenmüll drinsteht.

In Unified bin ich dann wieder darüber gestolpert weil es die Einstellung "Zyklisch fortlaufend" nicht mehr gibt, dafür kann man mit dem .Read(1) Befehl eine Aktualisierung anstoßen und es wird auf die Rückmeldung gewartet

flexible/Basic/Comfort/Advanced ist aber nicht wie Unified (oder Professional oder wie das "richtige" WinCC). In flexible/Basic/Comfort/Advanced kann man nicht direkt auf die Aktualisierung warten, sondern müsste sich ein Handshake und CRC basteln, oder man verwendet Rezepturvariablen und GetDataRecordTagsFromPLC

 

[DeltaMikeAir]

Wenn alle 100ms eine Aktualisierung von der HMI angestoßen wird dann muss ja logischerweise dazwischen eine Aktualisierung abgeschlossen werden, sonst macht das ganze Konzept keinen Sinn.

Das ist eben nur deine Vermutung, aber es ist nicht so.

Mal zum Nachdenken:

Du kannst eine WinCC Runtime mit einer CPU312 anlegen. Im WinCC flexible verknüpfst du nun 500 String Variablen mit je 100ms / zyklisch fortlaufend. Als Übertragungsart stellst du MPI mit 19,2K ein.

Glaubst du dann immer noch, dass die Variablen alle nach 100ms aktualisiert wurden?

 

[Sir Steel]

Ich frage mich gerade wo bei euch ein "Riesenhaufen" Variablen anfängt, ich rede von 20-30 aus dem Beispiel oder vielleicht 100, in diesem Rahmen sehe ich noch keine Performane Überlastung von der HMI.

Was macht dein Skript, wenn du die Netzwerkverbindung zur PLC unterbrichst

Dann gibt das HMI eine Systemmeldung aus das auf die Variable nicht zugegriffen werden kann.

wenn der DB mit den Variablen in der PLC gelöscht wird und die Variablen gar nicht mehr existieren?

Dann gibt das HMI eine Systemmeldung aus das auf die Variable nicht zugegriffen werden kann.
Beim VISU übersetzen werden die HMI Variablen als ungültig gemeldet das sie nicht mehr existieren

Vielleicht Monate später braucht der Anwender die Daten und stellt dann fest, dass da nur unbrauchbarer Datenmüll drinsteht.

Dann hat er davor jede Menge Fehlermeldungen ignoriert und leider pech gehabt, außerdem war Fehlerbehandlung nicht Teil des Themas, da kann man natürlich noch explizit darauf hin weisen

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich frage mich gerade wo bei euch ein "Riesenhaufen" Variablen anfängt, ich rede von 20-30 aus dem Beispiel oder vielleicht 100, in diesem Rahmen sehe ich noch keine Performane Überlastung von der HMI.

Und ich rede hier von Erfahrungen, die ich schon gemacht habe ... na ... wie auch immer ...

 

[Sir Steel]

Die Rede war von TIA V17 und 1500er CPU da brauch ich kein Beispiel aus Classic WinCC flecxible, sorry.
Es war auch nie die Rede von 500 Strings (129.000 Byte) sondern ca 100 Real/ Int (ca 400 Byte)

 

[DeltaMikeAir]

da brauch ich kein Beispiel aus Classic WinCC flecxible, sorry.

An der Systematik hat sich nichts geändert. Das Verfahren ist in Flex / TIA gleich.

Es war auch nie die Rede von 500 Strings (129.000 Byte) sondern ca 100 Real/ Int (ca 400 Byte)

Es war ein Versuch, dich zum Nachdenken anzuregen. Wie gesagt, 100ms zyklisch fortlaufend ist keine Garantie dass alle 100ms aktualisiert wurde.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

wie schon mehrmals vorher genannt - es geht nicht darum, ob es meißtens funktioniert - es muss sichergestellt immer funktionieren ...

 

[Sir Steel]

Dann muss an es eben noch mit Handshakes oder vergleichern erweitert werden, es ist doch erstmal nur eine von vielen Möglichkeiten

 

[PN/DP]

Ich frage mich gerade wo bei euch ein "Riesenhaufen" Variablen anfängt, ich rede von 20-30 aus dem Beispiel oder vielleicht 100, in diesem Rahmen sehe ich noch keine Performane Überlastung von der HMI.

der Fragesteller hat aber nach einer Lösung für 23400 (oder mehr) Variablen gefragt

Dann gibt das HMI eine Systemmeldung aus das auf die Variable nicht zugegriffen werden kann.

Wenn denn überhaupt Systemmeldungen angezeigt werden und im Meldepuffer nachlesbar sind. Und jemand (in dem Moment) auf den Bildschirm schaut.

Beim VISU übersetzen werden die HMI Variablen als ungültig gemeldet das sie nicht mehr existieren

das kann doch der Visu-Generator nicht wissen, wenn ein Programmierer danach das Programm in der PLC ändert

Dann hat er davor jede Menge Fehlermeldungen ignoriert und leider pech gehabt, außerdem war Fehlerbehandlung nicht Teil des Themas, da kann man natürlich noch explizit darauf hin weisen

Wenn wegen irgendwelcher (vielleicht temporärer) zu hoher Kommunikationslast Variablen nicht (rechtzeitig) aktualisiert werden, dann gibt es gar keine Fehlermeldungen und trotzdem kommt Müll hinten raus.

Die Rede war von TIA V17 und 1500er CPU da brauch ich kein Beispiel aus Classic WinCC flecxible,

WinCC Advanced (TIA) funktioniert aber genauso wie flexible/Basic/Comfort - daher dasselbe Problem wie seit > 20 Jahren seit WinCC flexible, das sollte sich langsam rumgesprochen haben.

Irgendwie zeugen Deine Aussagen von wenig Praxiserfahrung.

 

[Sir Steel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe den Eindruck das ihr zu wenig Praxis Erfahrung habt wenn ihr immer wieder von Tausenenden Variablen redet. Es mag ja sein das das gesamte Array 20.000+ Variablen hat, spielt für mich aber keine Rolle wenn ich nur für ein einziges Array Element HMI Variablen (das UDT definiert die Anzahl Variablen die ich brauche, das sind im Beispiel 20- 30, m.M.n. könnten das auch 100 sein) anlege und der Array Index eine HMI lokale Variable ist der durch das Array schaltet.
Dazu habe ich geschrieben das das erst ab TIA V15.1 und somit auch in V17 möglich ist. Deswegen interessiert mich Flexible in dem Moment nicht, denn da gab es die Möglichkeit für diese Art Multiplexen noch nicht. Dort müsste man das selbstverständlich anders lösen, z. B. über Adress Multiplexen

Beim VISU übersetzen werden die HMI Variablen als ungültig gemeldet das sie nicht mehr existieren

das kann doch der Visu-Generator nicht wissen, wenn ein Programmierer danach das Programm in der PLC ändert

EDIT: Das Thema Fehlermeldungen oder Fehlanwendungen werde ich nicht weiter ausführen da das nicht Teil des Themas war. Solche Fehlanwendungen kann man bei Bedarf dann zusätzlich absichern wenn das für den eigenen Anwendungsfall erforderlich ist.
Ich für meinen Teil sehe keine Notwendigkeit darin zu überwachen ob alle meine HMI Variablen noch in der SPS existieren, wenn da jemand in der SPS etwas löscht dann ist der Punkt erreicht in dem das nicht mehr mein Problem ist...

 

[PN/DP]

Es mag ja sein das das gesamte Array 20.000+ Variablen hat, spielt für mich aber keine Rolle wenn ich nur für ein einziges Array Element HMI Variablen (das UDT definiert die Anzahl Variablen die ich brauche, das sind im Beispiel 20- 30, m.M.n. könnten das auch 100 sein) anlege und der Array Index eine HMI lokale Variable ist der durch das Array schaltet.
Dazu habe ich geschrieben das das erst ab TIA V15.1 und somit auch in V17 möglich ist. Deswegen interessiert mich Flexible in dem Moment nicht, denn da gab es die Möglichkeit für diese Art Multiplexen noch nicht.

Dann zeige uns doch mal im Detail, wie du diese wunderbare neue Art Multiplexen projektiert hast und im Skript verwendet hast, mit der man mit ein paar HMI-Variablen auf tausende Variablen (oder Adressen) in der PLC zugreifen kann. Und wie du die WinCC RT (TIA) dazu "zwingst", die 100ms Aktualisierungszeit garantiert einzuhalten.

Ich für meinen Teil sehe keine Notwendigkeit darin zu überwachen ob alle meine HMI Variablen noch in der SPS existieren, wenn da jemand in der SPS etwas löscht dann ist der Punkt erreicht in dem das nicht mehr mein Problem ist...

Das war ja nur ein Beispiel, dass deine "Lösung" selbst so ein schwerwiegendes Problem stillschweigend übergeht.

Wie jetzt zigmal dargelegt wurde, kann es aber auch aus anderen Gründen dazu führen, dass Variablenwerte nicht wie von dir erwartet aktualisiert wurden und deshalb falsche Werte in die csv-Datei geschrieben werden. Sind deine Kunden da auch der Meinung, dass das nicht dein Problem ist, wenn diese ignorierte Fehlermöglichkeit schon in deinem Konzept so angelegt ist?

 

[Larry Laffer]

Dann zeige uns doch mal im Detail, wie du diese wunderbare neue Art Multiplexen projektiert hast und im Skript verwendet hast, mit der man mit ein paar HMI-Variablen auf tausende Variablen (oder Adressen) in der PLC zugreifen kann. Und wie du die WinCC RT (TIA) dazu "zwingst", die 100ms Aktualisierungszeit garantiert einzuhalten.

... das würde mich auch mal interessieren - da mir ja auch noch erheblich an Praxis-Erfahrung, gerade in dem Thema, fehlt ... und so, wie ich das gerade verstehe geht es anscheinend dem Harald (@PN/DP ) ja genauso ...