WinCC WinCC 7.2 Performance bei Basic-Scripten

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe seit einigen Jahren in einer Anlage ein WinCC 7.2 am Laufen.
Darin werden rel. viele Aktionen mit Basic-Sripten ausgeführt. Teilweise rufen die Scripte externe DLL-Funktionen auf.
Ich sende dabei Anfragen an einen Server, der mit eine Antwort zurücksendet oder auch Aufträge an Drucker.
WinCC scheint nun nach mehrmaligem Erweitern der Anlage immer größere Performance-Probleme zu haben.
Zuerst dacht ich immer, der Daten-Server benötigt so lange für die Antwort (muß Daten suchen und die Antwort zusammenstellen).
Inzwischen haben wir rausbekommen, dass der Server in der Regel weniger als 0,2 Sekunden für die Antwort benötigt.
WinCC zeigt mir manchmal in der SPS aber erst nach 15 bis 30 Sekunden an, dass das Ergebnis vom Server eingegangen ist.
Bin ich mit meinem Laptop an der SPS online, wird es signifikant noch langsamer.

Es ist für die Mitarbeiter halt unschön, wenn ein Vorgang abgeschlossen ist, der Drucker dann aber erst nach 15 Sekunden ein Label auswirft.
Ich schicke den Druckauftrag sofort von der SPS, über eine Variablenänderung, ein Basic-Script ruft dann eine DLL, die den Druck ausführt.
In der Zwischenzeit gibt die DLL die Steuerung zurück, so dass WinCC weitere Scripte abarbeiten kann, ich frage nur das Druckergebnis ab und mache weiter, wenn es kommt.

Kann mir jemand sagen, ob es irgendwelche Wekzeuge im WinCC oder extern gibt, mit denen ich feststellen kann, wo wirklich der Flaschenhals an der ganzen Sache ist?
Ist es möglich, das zu viel Scripte gleichzeitig ausgeführt werden wollen? Wo genau kann ich das sehen?
Welche Möglichkeiten gibt es, um hier Lasten besser zu verteilen?

PS: Wir lesen z.Bsp. Fehlermeldungen nicht bitweise, sondern als Rohdatenvariable ein und zerlegen das Ganze dann mittels einer externen Funktion.
Das braucht sicher einiges an Performance, aber auch wenn die Anlage fehlerfrei läuft, also die Rohdaten zwar gelesen werden, sich aber nciht ändern, und so die Scripte nicht "feuern", ändert sich die Performance nicht zum Besseren.

 

[Thomas_v2.1]

Das Diagnosewerkzeug für solche Dinge in WinCC ist ApDiag aus dem Siemensordner WinCC\uTools.
Allerdings ist das nicht so detailliert dokumentiert, und ohne das Projekt im Detail zu kennen lässt sich auch schwer sagen ob und wie du damit etwas sinnvolles diagnostizieren kannst.

Wenn du den Verdacht hast dass bestimmte Skripte langsam laufen, kommst du vielleicht am einfachsten weiter, indem du dir in diesen Skripten per Debug Ausgabe den Zeitpunkt von Begin und Ende dieses Skripts ausgibst, oder direkt die Laufzeit berechnen und ausgeben.

Um einen groben Überblick über die Kommunikation zu erhalten, d.h. wie viele Telegramme werden da aufgebaut, gibt es die Kanal-Diagnose (Programm WinCCChnDiag.exe aus \bin).

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Über ApDiag kannst du auch einen Filter einstellen, der dir Skripte ausgibt die länger als Zeit x dauern. Das ist relativ einfach zu aktivieren. Eine Hilfe zu diesem Programm ist über die Hilfe von WinCC erreichbar.

 

[Ralle]

Wie sieht es aus, wenn zu viele Scripte auf Abarbeitung warten?
Ist das mit der Kanal-Diagnose zu sehen?

Ist eigentlich keine so große Anlage.
Ich frag mich immer wieder, wie das bei PCS7 geht, wo die Daten ganzer Werke auflaufen.

 

[Thomas_v2.1]

Skripte diagnostizieren geht auch über ApDiag (zumindest prinzipiell). Ich meine WinCC wirft dir eine Warnung wenn über 10.000 Skripte in der Abarbeitung warten.

In PCS7 steckt keine Magie, in der Runtime nutzt das nur die Standardfunktionalitäten von WinCC. Die Magie steckt in der automatischen Generierung von Variablen, Meldungen, Faceplate-Instanzen etc. Nur eben dass für die Alarmierung ausschließlich das Bausteinmeldeverfahren zum Einsatz kommt. Und das entlastet die Kommunikation schon sehr stark, gerade bei richtig vielen Meldungen.
Bei Bildern mit vielen Faceplate-Instanzen dauert es auch bei PCS7 ein paar Sekunden bis alle animiert sind, denn hinter jedem Faceplate stecken ein ganzer Haufen Skripte. Ich habe aktuell ein PCS7-Projekt bei dem ich z.B. 50 Meld8-Instanzen in einem Bild habe (d.h. ein Meldeobjekt für 8 Meldungen). Bis die nach einem Bildwechsel fertig animiert sind, dauert es sicher 6-7 Sekunden. Bei PCS7 fragt aber keiner danach, denn das ist dann eben so.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich das richtig sehe, arbeitet doch WinCC7.2 auch alle Scripte nacheinander ab oder?
D.h. dann, wenn ich eine Datenbank abfrage (per DLL, welche von einem VBS-Script in WinCC aufgerufen wird und auf Antwort warten muß) und die Antwort dauert 300ms, dann steht das System (zumindest die Scriptengine) in diesen 300ms und wartet oder? Keine weiteren Scripte können abgearbeitet werden.
Ist das bei den C-Scripten ebenfalls so?

 

[mystone]

Ja ich denke dass das auch für C gilt.

Wobei ich imho glaube, dass jeweils ein C und VBS Skript parallel abgearbeitet werden kann, jeweils in den Globalen Aktionen sowie in den Runtime Bildern.

Das das ganze Skript angehalten wird, wenn in einem Skript auf eine Antwort gewartet wird, das ist definitiv so.

 

[Thomas_v2.1]

Von den globalen Aktionen kann jeweils ein VBA und ein C-Skript aktiv sein.

Zu der Warteschlange, Beispiel:
Eine globale C-Aktion die 10 Sekunden dauert und mit einem Variablentrigger, und eine weitere C-Aktion zyklisch 1 Sekundentrigger.
Wird die mit Variablentrigger angestoßen, so laufen während der 10 Sekunden die Skripte mit dem Sekundentrigger in die Warteschlange auf. Ist dann das lange laufende Skript fertig, so werden die 10 Sekundentrigger-Aufrufe die in der stehen Warteschlange alle nacheinander nachgeholt, bedeutet, dass man dann in einer Sekunde 11 Aufrufe hat, und nicht nur einen.

Wenn man via ApDiag die Script Diagnose-Variablen aktiviert und sich diese in einem Bild anzeigen lässt, kann man schön beobachten wie der Wert für die Warteschlange hochgeht, und dann wieder runter.

Die Bild-Skripte haben wohl eine eigene Warteschlange, von denen kann aber auch immer nur eines aktiv sein.
Hast du beispielsweise eine globale Aktion die 10 Sekunden dauert, können weiterhin C-Skripte in den WinCC-Bildern ausgeführt werden. D.h. die Anlage bleibt trotzdem bedienbar.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man via ApDiag die Script Diagnose-Variablen aktiviert und sich diese in einem Bild anzeigen lässt, kann man schön beobachten wie der Wert für die Warteschlange hochgeht, und dann wieder runter.

Genau das suche ich.
Ich schau mir das Montag mal an und frage dann sicher noch einmal nach, wie genau ich mir das anzeigen lassen kann. Denn letzte Woche hatte ich genau dies Anzeige nicht gefunden oder übersehen.

PS: Wir habe da ja ein System. das schon seit Jahren läuft, nun soll es taktzeitmäßig schneller werden. Siemens fragte, welches Update; dort läuft noch Upd2 oder 3. Das müssen wir zuerst einmal hochziehen (aktuell auf Upd12), bei Upd2 war wohl noch sehr viel buggy. Da frage ich mich dann aber doch, wie man sowas in die Industrie lassen kann. Ok, Fehler passieren immer, aber ich kann ja auch nicht dauernd zum Kunden fahren und mal eben ein neues SP einspielen. Wenn ich so die Notes dazu lese, da muß man dann am IIS Änderungen vornehmen etc. Es ist also auch nicht 100% sicher, dass das System nach einem Update wieder korrekt läuft, ohne dass noch an weiteren Systemkomponenten des Win2008SR2-Servers herumgeändert wird, den darf man ohnehin nur mit Samthandschuhen anfassen, das ist so richtiger MS-Rückschritt gewesen. Das wäre dann der Supergau. Na gut, dafür kann dann Siemens allerdings auch nichts. ;-)

 

[Ralle]

Ich bin gerade vor Ort am WinCC-Server.
Wenn ich ApDiag aus uTools starte, kann ich alles mögliche aufrufen und starten, es werden aber keinerlei wirkliche Daten angezeigt.
Wen ich die Variablen:

@SCRIPT_COUNT_TAGS
Diese Variable enthält die aktuelle Anzahl über Script angeforderte Variablen.
@SCRIPT_COUNT_REQUEST_IN_QUEUES
Diese Variable enthält die aktuelle Anzahl an Aufträgen.
@SCRIPT_COUNT_ACTIONS_IN_QUEUES
Diese Variable enthält die aktuelle Anzahl an Aktionen, die zur Bearbeitung anstehen.

in einem WinCC-Fenster einfüge und ansehe, dann sind die immer alle 0, auch wenn ich FillTags in ApDiag aud ON gestellt haben.

Kann mir jemand sagen, was ich einschalten oder starten muß, damit ich hier überhaupt einmal ein paar Werte angezeigt bekomme?

 

[Ralle]

Count of TransAction

Beispiel:

===============================================================
1.Applikation: GSC_RT Count of Transactions 1
2.Applikation: ITLG-RT Count of Transactions 0
3.Applikation: PDLRuntimeSystem Count of Transactions 7
4.Applikation: APDiagnose Count of Transactions 0
===============================================================

bei mir

===============================================================
1.Applikation: GSC_RT Count of Transactions
2.Applikation: ITLG-RT Count of Transactions
3.Applikation: PDLRuntimeSystem Count of Transactions
4.Applikation: APDiagnose Count of Transactions
===============================================================

ohne Zahlen dahinter.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei anderen Infos aus dem Info-Bereich steht immer 0 dahinter.

 

[Thomas_v2.1]

Ich habe das jetzt auch noch nicht so oft benutzen müssen, aber bisher hat das immer auf Anhieb geklappt.
Siehst du denn überhaupt im Diagnosefenster irgendwelche Ausgaben von der WinCC-Runtime, die dort per HMI.Runtime.Trace oder printf() geschrieben wurden? Scheint so als ob apdiag überhaupt keine Verbindung zum WinCC-Projekt bekommt. Ich würde darum mal in den Logfiles im Diagnose-Ordner nach Auffälligkeiten suchen.

 

[Ralle]

Doch, ich sehe unsere Ausgaben aus den Scripten, das geht.
Ich werde erst einmal auf V7.2 Upd12 hochrüsten, mal sehen, ob sich etwas ändert.