WinCC flexible Skript Daten archivieren: Aktualisierungszeit der Variablen

Fluffi

Level-2
Beiträge
449
Reaktionspunkte
69
Zuviel Werbung?
-> Hier kostenlos registrieren
hi

ich sichere mit Hilfe eines Skriptes in WinCC flexible ca. 100 Werte aus der SPS in eine .CSV-Datei . Allerdings habe ich leider feststellen müssen, dass bzgl. der Aktualität der gesicherten Werte Inkonsistenzen auftreten, dh. Werte gesichert werden, die eigentlich der vorherigen Sicherung zuzuordnen sind. Das passiert ca. alle 10 Sicherungen.

Das Skript selber startet bei einer Wertänderung einer Triggervariablen und setzt diese wieder zurück am Ende. Fehler im Skript werden mit Exceptions ausgelesen. So weit so gut, das Skript selber läuft immer ohne Probleme durch, startet auch sofort wenn es angetriggert wird und wirft keine Fehlermeldungen aus.

Die zu archivierenden Variablen werden folgendermaßen ausgelesen : Zeile_1 = SmartTags(Var_x) usw.
Var_x steht in einem DB, welcher vor dem Start des Skripts befüllt wird.

Die "Abtastrate" der Triggervariable ist auf Zyklisch fortlaufend und 100ms gestellt. Die zu archivierenden Daten allerdings nicht. Die stehen auf der Standardeinstellung "Zyklisch bei Verwendung".

Jetzt meine Frage:

Schieß ich mir selber ins Knie wenn die 100 zu sichernende Variablen auf "Zyklisch bei Verwendung" stehen? Ich habe immer gedacht, dass beim SmartTags-Befehl im Skript eine einzelne "aktuelle" (und somit auch langsame) Anforderung an die SPS bzgl. der Aktualisierung der Variablen stattfindet?
Wo ist das Problem? Ist es die Einstellung "Zyklisch bei Verwendung" oder das Befüllen des DBs kurz vor Start des Skripts oder sogar beides ?

Sollte es reichen wenn ich nach dem Befüllen des DB 5 Sekunden warte bis das Skript startet? Muss dann noch Zyklisch fortlaufend bei y ms eingestellt werden? Gerade bei letzterem hab ich die Befürchtung, dass WinCC flex das gar nicht mag bei so vielen Variablen.
 
Zuletzt bearbeitet:
Konsistenz geht nur mit einer Rezeptur, also eine Rezepture mit deinen Variablen erstellen.
Rezeptur exportieren, Status auswerten und dann wie auch immer weiterverarbeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Rezepturen wären sicher eine Möglichkeit. Aber leider für meinen Zweck zu unhandlich.
Wenns nicht anders geht muss ich die Sache dennoch von der Rezeptur-Seite anpacken.

Mir geht es aber (zum Glück) nicht um Geschwindigkeit. Ich könnte durchaus 15 Sekunden warten mit der Archivierung wenn ich davon ausgehen kann
dass die Daten konsistent sind. Und ich meine jetzt keine 100% bombensichere Konsitenz. Skripte in WinCC flex können das in der Form nie zu 100% sicherstellen. Das ist
mir schon klar.
Mir geht es nur um eine Verbesserung des beschriebenen Problems. Da muss sich doch was zum Positiven hin machen lassen, gerade wenn ich dem ganzen mehr Zeit gebe
oder sehe ich das falsch?
 
Mit längere Zeit in mehreren Sekunden geht es sicherlich, aber ich finde es mit den Rezepturen
alles andere als unhandlich. Wenn ich es mir überlege brauchst du ja nur einen Datensatz, diesen
kannst du ereignisgesteuert mit einen Befehl Konsitent mit Rückmeldung aktualisieren.

Besser geht es doch garnicht!

Um die Sache noch verbessern, kannst du diesen Datensatz mit Systemfunktionen exportieren.
Wenn diese Exportierte CSV Datei nicht deiner gewünschten Formatierung entspricht, kannst du
die Datei mit ein Befehl wieder einlesen und entsprechend den Vorgaben umladen.

Das gute daran ist das dieses vom Scripten schneller und sauberer geht, als wenn du jedes Smart Tag
Händisch in das Script reinziehst. Erweiterung oder Variablenänderungen kannst du dann auch schön
übersichtlich für Dritte einfach in der Rezeptur durchführen.
 
Also beim nächsten mal werde ich es sicherlich über Rezepturen lösen und das ganze
System dafür von vorne herein auslegen. Das scheint die zuverlässigste Methode zu sein.
Danke für den Tipp.

Leider hat aktuell der DB mit den zu archivierenden Daten ca 1k Einträge, von denen ich nur ca. 100 sichere.
Den als csv zu exportieren um ihn dann wieder Zellenweise auseinanderzunhemen um wieder eine
.csv Datei zu erzeugen ist machbar aber unglaublich grausam zu realisieren. Vor allem wenn neue Werte
später dazukommen.
Klar die jetztige Skript Lösung ist auch schreibintensiv und alles andere als super elegant, aber hier habe ich schon Excel-Makros geschrieben,
welche mir den Skript-Code erzeugen, inkl. Überschriften, Formatierung usw.

Was ich zunächst probiere ist eine Wartezeit von 5 oder mehr Sekunden bis Skriptbeginn. Unabhängig davon ist mir aber noch unklar,
wie die Skript-Variablen am besten aktualisiert werden müssen? Fortlaufend oder bei Verwendung? Die Runtime läuft auf einem PC, kein Siemens Panel.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Trotzdem nur mal ein Beispiel wie du eine Rezeptur exportieren könntest.
Achtung es darf nur ein Datensatz enthalten sein.

Code:
Dim Status, StartTime, StopTime, ActTime
Dim f
Dim Daten(100), Nr
Const lesen = 1, schreiben = 2, anhaengen = 8
 
'--- Expotieren der Rezepturdaten -------------------------
Status = 0
ExportDataRecords Rezeptur, 0, Datei_Export, hmiOverwriteWithConfirmation, hmiOn, "Status"
 
'wartem bis Datei geschrieben
Do
                Status = SmartTags("Status")
                If Status = 12 Then Exit Sub
Loop While(Status And 4) = 0
 
'--- fehlerbehandlung aktivieren --------------------------
On Error Resume Next
 
'--- Filesystem vorbereiten -------------------------------
Set f = CreateObject("filectl.file")
 
 
'--- Exportierten Daten Filtern ---------------------------
'Datei zum lesen öffnen
Do
                Err.Clear                                                                                                                                           'Fehler löschen
                f.open Datei_Export, lesen                                                                       'Datei öffnen
                If Err.Number <> 0 Then                                                                                            'Bei Fehler 1sec. warten
                               StartTime = Now
                               StopTime = StartTime + 1 / 24 / 3600
                               Do
                               Loop While Now < StopTime
                End If
Loop While Err.Number <> 0
 

'--- Auslesen und Filtern ---------------------------------
Nr = 1
Do While f.EOF = False

	If Nr > 2 Then Daten(Nr) = f.LineInputString
    Nr = Nr + 1
Loop
f.close
 
 
End Sub
 
Unabhängig davon ist mir aber noch unklar,
wie die Skript-Variablen am besten aktualisiert werden müssen? Fortlaufend oder bei Verwendung?
Hmm, ich sage mal: 100 Variablen dauerhaft "zyklisch fortlaufend" zu lesen, nur weil sie einmal am Tag gesichert werden sollen, ist echt keine gute Idee... selbst wenn Du wahrscheinlich keine Kommunikations-Überlast-Warnung erhältst, so wird wohl ein gewisses "zähes" Verhalten der Visu zu merken sein.

WinCC flexible Hilfe - Zugriff auf Variablen schrieb:
Wenn Sie die Variable mit der Erfassungsart "Zyklisch bei Verwendung" projektieren, dann müssen Sie sicherstellen, dass das Skript nur im Bild aufgerufen wird, wo die Variable auch an anderer Stelle verwendet wird, z.B. in einem EA-Feld.

Du hast zufällig erstaunlich viel Glück, wenn bei Dir tatsächlich nur 1 von 10 Sicherungen nicht konsistent ist. Vermutlich verwendest Du alle Variablen irgendwo und die Variablen wurden seit der letzten Verwendung meistens zufällig nicht verändert.

Du solltest wissen: WinCC flexible liest Variablenwerte aus der Steuerung nur dann, wenn es von deren Verwendung für aktuell angezeigte Objekte weiß oder extra zum Aktualisieren aufgefordert wird oder wenn die Aktualisierung der Variable auf "zyklisch fortlaufend" steht. Wird der Variablenname erst im Skript zusammengesetzt oder kann WinCC flexible den Trigger des Skriptes nicht vorhersehen, dann werden die Variablenwerte erst NACH Ausführung der entsprechenden Skriptzeile gelesen, egal wie kurz die Aktualisierungszeit der Variable eingestellt ist. Das Skript wartet NICHT auf das Lesen der Variablen. Es gibt auch keine Rückmeldung, wann eine "normale" PLC-Variable gelesen wurde. Nur Rezepturvariablen kann man so lesen, daß man eine Rückmeldung erhält, wenn alle Variablen gelesen wurden. Wie Helmut schon schrieb: konsistentes Lesen von PLC-Variablen ins HMI geht nur mit Rezepturen. Alles Andere ist mehr oder weniger Zufall.

Wenn Du Dich mit "hochwahrscheinlichem" Zufall zufrieden geben willst, dann müsstest Du zumindest jede zu sichernde Variable zweimal lesen. Einmal ein Skript durchlaufen lassen, was auf alle zu sichernden Variablen einen (Dummy-)Lesezugriff ausführt. Dadurch werden Leseaufträge für die Variablen angestoßen. Vielleicht 30..60 Sekunden später das eigentliche Sicherungsskript, was den Wert der zwischenzeitlich gelesenen Variablen in die csv-Datei schreibt. Doch auch so ist nicht garantiert, daß wirklich alle Variablen aus der SPS gelesen wurden.

Leider hat aktuell der DB mit den zu archivierenden Daten ca 1k Einträge, von denen ich nur ca. 100 sichere.
Den als csv zu exportieren um ihn dann wieder Zellenweise auseinanderzunhemen um wieder eine
.csv Datei zu erzeugen ist machbar aber unglaublich grausam zu realisieren. Vor allem wenn neue Werte
später dazukommen.
Klar die jetztige Skript Lösung ist auch schreibintensiv und alles andere als super elegant, aber hier habe ich schon Excel-Makros geschrieben,
welche mir den Skript-Code erzeugen, inkl. Überschriften, Formatierung usw.
Das kann doch nicht sooo aufwendig sein, in WinCC flexible eine Rezeptur anzulegen und 100 Variablen da reinzuziehen.
Bedenke: Du programmierst eine Industrieanlage und nicht irgendeine Smartphone-App für Dummies... vermutlich erwartet Dein Auftraggeber zuverlässig funktionierenden Code und nicht Vorführ-Code, der mit minimalst möglichem Aufwand erzeugt wurde... wie aufwändig wird es wohl für Dich werden, wenn Du den Code später in der Garantiezeit nachbessern mußt? Womöglich weit weg von Deiner Firma? Der Zufall wird ganz sicher irgendwann zu Deinen Ungunsten zuschlagen ;)

Genau Dein Problem wird hier im Forum mehrmals im Jahr nachgefragt. Schau z.B. mal hier:
http://www.sps-forum.de/hmi/72180-w...rialblen-sind-im-vb-script-nicht-aktuell.html
und Links zu Besser-machen-Beispielcode da ab Beitrag #4

Harald
 
Ich hab nun ein Konstrukt aus Warten und Dummy-Lesen implementiert und beobachte mal die Konsistenz der Werte. Wenn die nicht gegeben ist, dann wars das mit Skripte und direkte Variablen-Archivierung.

Aber wenn man sich so im Netz und auch hier umschaut, dann machen das ja viele Leute über Skripte und nicht nur für 3 Variablen. Ich glaube kaum, dass die erstens das Skript in einem Bild laufen lassen welches auch die entsprechenden Variablen refferenziert oder zweitens alle Werte wirklich Zyklisch fortlaufend einlesen. Entweder sehen die nicht, dass die Konsistenz flöten geht oder es geht warum auch immer.

Zudem stellt sich mir die Frage, was WinCC flex Skripte für einen Nutzen haben, wenn das Timing bzgl. den Variablen so eine undefinierte Sache ist. Und Skripte ohne Zugriff auf Variablen machen auch nur bedingt Sinn. Oder warum findet Alternativ nicht bei jedem Auslesen einer Variablen im Skript auch eine Abfrage an die SPS statt. Klar, das kann bei vielen Variablen dauern, aber das ist immer noch besser als wenn die Werte undefiniert sind. Ich hab schon mit Libnodave gearbeitet und da läuft das ähnlich ab wenn man die Variablen einzeln ausliest und keinen Bereich. Das dauert zwar, aber man kann sicher sein, dass die Werte stimmen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"Denn sie wissen nicht was sie tun"
und deswegen findet man auch noch nach Jahren die unglaublichsten Bugs in "professioneller" Software.

Das Variablen-Leseverhalten von WinCC flexible ist so schon in Ordnung - es ermöglicht eine viel höhere Kommunikationsperformance als immer ..zig Millisekunden auf das Lesen zu warten - man muß es halt nur wissen und beachten --> nochmal: unter WinCC flexible bekommt man nur Rezepturen sicher aus der CPU ins HMI gelesen.

Harald
 
Zuletzt bearbeitet:
Zudem stellt sich mir die Frage, was WinCC flex Skripte für einen Nutzen haben, wenn das Timing bzgl. den Variablen so eine undefinierte Sache ist. Und Skripte ohne Zugriff auf Variablen machen auch nur bedingt Sinn. Oder warum findet Alternativ nicht bei jedem Auslesen einer Variablen im Skript auch eine Abfrage an die SPS statt. Klar, das kann bei vielen Variablen dauern, aber das ist immer noch besser als wenn die Werte undefiniert sind. Ich hab schon mit Libnodave gearbeitet und da läuft das ähnlich ab wenn man die Variablen einzeln ausliest und keinen Bereich. Das dauert zwar, aber man kann sicher sein, dass die Werte stimmen.

Erklärt sich auch doch von selber, jetzt stell dir mal vor du hast auf einer HMI ca. 1000 PT projektiert und davon 2-x im Feld, da wird der verwendete Bus sich aber freuen.
Du musst das ganze nicht nur aus deiner eigenen Anwendung bzw. Sicht betrachten, es gibt viele Anwendungsfälle die ganz anders aussehen wie bei dir.
 
Erklärt sich auch doch von selber, jetzt stell dir mal vor du hast auf einer HMI ca. 1000 PT projektiert und davon 2-x im Feld, da wird der verwendete Bus sich aber freuen.

Genau deshalb wäre es ja gerade sinnvoll, wenn WinCC flex eben bei der Abarbeitung des Skripts die Variablen Zeile für Zeile ausliest und auch nur dann und nicht die ganze Zeit fortlaufend wenn man sie ja eh nicht braucht. Dann würde der Bus nur 1x belastet werden und sonst nicht. Das dies in genau diesem Moment eine gewisse Trägheit mit sich zieht und für sehr viele Variabelen dann ein paar Sekunden dauert wäre den meisten wohl ziemelich egal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Genau deshalb wäre es ja gerade sinnvoll, wenn WinCC flex eben bei der Abarbeitung des Skripts die Variablen Zeile für Zeile ausliest und auch nur dann und nicht die ganze Zeit fortlaufend wenn man sie ja eh nicht braucht. Dann würde der Bus nur 1x belastet werden und sonst nicht. Das dies in genau diesem Moment eine gewisse Trägheit mit sich zieht und für sehr viele Variabelen dann ein paar Sekunden dauert wäre den meisten wohl ziemelich egal.
Genau das erreicht man mit dem einmaligen Lesen als Rezeptur mit der Systemfunktion GetDataRecordTagsFromPLC.
Man muß nur die gewünschten Variablen in die Rezeptur packen.

Harald
 
Hallo,

ich habe auch schon öfters Skripte in WinCCflex zum Archivieren von Variablen eingesetzt,
nach folgendem Schema:

zeile = SmartTags("var1") & ";" & SmartTags("var2") & ";" SmartTags("var3")....
ts.WriteLine zeile

Was PN/DP schreibt, höre ich jetzt zum erstenmal und mir ist bis jetzt kein Problem mit Inkonsistenzen aufgefallen, aber man durchsucht ja auch nicht jede csv-Datei.
Siemens bringt ja selbst solche Beispielprogramme, wo die Skripte so aufgebaut sind. Wissen die nicht was die da unter die Leute bringen oder ist das nur als "Vorführ"-Code zu verstehen?

mfg
urlaub
 
Hallo,
mag sein, dass du das hier und heute das erste Mal liest oder hörst - es ändert aber nichts an der Sache an sich.
Aufgrund des Kommunikationsverhaltens von Flex (und nicht nur Flex) und des gedachten Einsatzes der Visu (in erster Linie erstmal Dinge anzeigen und Bedienfunktionen an die SPS geben) ist eine konsistente Datenübermittlung überhaupt nicht angedacht. Man kann dabei natürlich Glück haben - z.B. wenn man nicht so viele Variablen in der Visu hat oder wenn die gewünschten Variablen auch noch Bestandteil des aktuellen Bildes sind oder oder oder ... - aber bei größerer Menge von zu archvierenden Variablen (ich schätze mal alles größer 10) ist die Inkonsistenz schon vorprogrammiert - es sei den man bedient sich des genannten Tricks (oder man setzt dafür ein vollkommen anderes System ein).

Es werden nur Rezepte und Profilkurven konsistent gelesen.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wir stehen gerade vor der Aufgabe, bei einer Montageanlage Daten in einer SQL-Datenbank zu archivieren (aus einer S7 317-2PN/DP, 100 bis 200 Int- oder Real-Werte alle 25s). Wir haben uns dazu das Beispiel vom Siemens-Support Beitrag:24677043 angesehen und hatten vor, das Beispiel für unsere Zwecke anzupassen.
Jetzt hab ich das Gefühl, dass das vielleicht keine so gute Idee ist. Welche sicheren kennt ihr, um das Problem zu lösen.

mfg
urlaub
 
Hallo,
wenn es richtig sicher und ggf. auch noch sinnvoll überschaubar sein/werden soll dann würde ich damit aus der Visu komplett heraus gehen und es mit einem .Net-Programm umsetzen - entsprechende Programmier-Kenntnisse vorausgesetzt ...

Gruß
Larry
 
wir stehen gerade vor der Aufgabe, bei einer Montageanlage Daten in einer SQL-Datenbank zu archivieren (aus einer S7 317-2PN/DP, 100 bis 200 Int- oder Real-Werte alle 25s). Wir haben uns dazu das Beispiel vom Siemens-Support Beitrag:24677043 angesehen und hatten vor, das Beispiel für unsere Zwecke anzupassen.
Jetzt hab ich das Gefühl, dass das vielleicht keine so gute Idee ist. Welche sicheren kennt ihr, um das Problem zu lösen.
Ich habe ein Paar Vorschläge.
Aber zuerst ein neuen Thema starten, bitte.
 
falls es jmd interessiert: Seit ein paar Wochen ist nun die Skript-Lösung mit Wartezeit+"Dummy-Variablen einlesen" am Laufen und ich kann bis jetzt keine Inkonsistenzen mehr feststellen. Wie bereits geschrieben, die Variablen sind nicht auf "Zyklisch fortlaufend" gestellt, der Bus wird also nicht ständig belastet. Für meinen Teil ist die Archivierung so wie sie jetzt läuft absolut ok. Wer eine wirklich bombensichere Lösung haben will, sollte allerdings die von PN/DP bevorzugte Lösung mit Rezpeten verweden.
 
Zurück
Oben