VBscript. Was passiert wenn man 2 Skripte auf einmal auslöst ?

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine gute Frage denke ich.

Ich habe mehrere Skripte in WinCC Flexible erstellt, und sie werden über ein Tag und "wertänderung" ausgelöst.
Jetzt überlege ich was passiert wenn 2 oder mehrere Skripte auf einmal ausgelöst wird.

Werden alle gleichzeitig aktiviert ?
Oder, werden alle einer-nacheinander aktiviert ?
Oder, wird nur ein Skript aktiviert, und die Reste verworfen ?

So weit ich weiss ist VBS nicht multithreaded.

 

[Larry Laffer]

Hallo Jesper,
ich kann jetzt an dieser Stelle nicht für Flex sprechen ... aber bei ProTool (und dem ist das Flexibel ja nachempfunden) ist es so, das angeblich gleichzeitig 20 Scripte bearbeitet werden können. Ob das jetzt wirklich gleichzeitig oder Pseudo-gleichzeitig ist kann ich leider nicht beurteilen. Ich habe aber durchaus schon Anwendungen gebaut in denen das gleiche Script mit unterschiedlichen Parametern gleichzeitig mehrfach aufgerufen wurde und (so zumindest auf dem Bildschirm) gleichzeitig abgearbeitet wurde ...

Ich weiß aber von meinen jüngsten Experimenten, dass die Scripte auf jeden Fall der Variablen-Aktualisierung untergeordnet werden ...

Gruß
LL

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke LL. Das lautet beruhigend.
Ich werde auch selber einige Tests machen.

 

[JesperMP]

Ich habe mittlerweile ein bisschen mehr Infos gefunden.
Ja, es gibt eine Warteschlange von 20 Skripte.
Die Skripte werden einer nach dem anderen ausgeführt.
Wenn die Warteschlange ist Überschreitten mit mehr als 20 Skripte, erhaltet man ein System-Fehler "20015 - Script-Überlauf".

Und genau dies ist mir passiert.

Ich glaube, ich habe ein Problem mit ODBC Lese-Operationen.
Wenn es ein Problem mit der ODBC-Verbindung gibt, dann wartet das Skript in eine außergewöhnliche lange Zeit, bis die ODBC endet mit einem Timeout-Fehler.

Ich versuche herauszufinden, wie ich dieses mehr robust hantieren kann.

 

[vierlagig]

in vielen sprachen gibt es eine

try{befehl}
catch{z.b. fehlermeldung}

das verhindert timeout-probleme, aber ob das in winCC verfügbar ist? *schulterzuck*

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... das passiert in ProTool ganz genauso ...

Eine Möglichkeit ist schon mal, die Anzahl der Scripte zu reduzieren.
Warscheinlich steckt der Teufel bei dir (wie auch bei mir) in den Scripten selbst. Werden verschiedene Scripte "bei Wertänderung" aufgerufen ?
Hast du Scripte kaskadiert ? Das auf jeden Fall vermeiden ...
Hast du viele Variablen (> 500) im Datenaustausch mit der SPS ? Hier hilft ggf. das Verändern der Aktualisierungszeit.

Schreib mal etwas mehr zu deiner Anwendung ...

Gruß
LL

 

[JesperMP]

Try/Catch gibts es nicht in VBS. Schade.
Das "beste" Ersatz dafür ist ON ERROR RESUME NEXT und das ERR objekt.

Mein applikation ist wie so:
Jeder 3 sekunden wird ein ODBC Lese-skript durch "wertänderung" angestossen.
Dafür verwende ich das ADODB objekt.
Es funktioniert meistens einwandfrei. Es scheint als ob ein lese auftrag in weniger als 1 sekunde fertig ist.

Nun meldet mein kunde das er den system fehler 200015 bekommt.
Ich vermute das es mit den netzwerkverbindung zum datenbank zu tun hat, oder mit irgendeine andere problem zwisschen ODBC trieber und datenbank. Ich vermute das den ODBC treiber wartet ein gewisse zeit bevor es mit ein "timeout" beendet. In diesen zeit wird mehrere skripte aufgerufen, und dadurch wird den skript überlauf erzeugt.

Dies ist mein plan für ein mehr robuste skript hantierung:

Jeder zyklisch aufgerufene skript muss den "wertänderungs"-zähler zurück zum SPS senden als "feedback".
Nur wenn den feedback mit den wertänderungs tag stimmt, wird ein neues skript durch wertänderung ausgelöst.
Wenn es zu lange dauert bevor den feedback kommt, wird ein systemalarm ausgelöst. Nur wenn den operator den alarm zurückgestzt hat, startet ein neue skript durch wertänderung.

Gibt es andere verfahren ?

 

[Larry Laffer]

Hallo Jesper,
das hört sich fast 1:1 an wie mein letztes Problem. Ich habe bei meiner Anlage mit sehr vielen Tags die Produktionsdaten der gefertigten Teile in etwa dem gleichen Takt (3 - 4 Sek.) in eine Excel-Datei geschrieben.
Das dafür zuständige Script wird über eine Zähl-Variable aus der SPS (zählt von 0 .. 10000 und fängt wieder von vorn an) per Wert-Änderung angestossen. Manchmal hatte ich die Überlast ...
Ich hatte das Programnm nun dahingehend geändert, dass das SPS-Programm erst weiterlaufen durfte, wenn das Script ein Quittierungs-Bit gesetzt hat. Nun trat folgender Effekt auf : Die Anlage blieb bis zu 10 Sekunden (!!!) stehen und lief dann weiter. In der Visu hatte ich dann auf dem Anzeigeschirm die externe und die interne Zählvariable (diese zählt jedes Mal wenn das Script bearbeitet wird) dar gestellt. Meine Beobachtung hier : Schon die SPS-Zählvariable wurde laut PG in der SPS erhöht, auf der Visu war davon nichts zu sehen. Irgendwann sprang dann die Zahl auf dem Bildschirm um und dann auch sofort die zweite (für die interne Zählung).
Kommt dir das bekannt vor ...?

Ich habe eine Menge hin und her programmiert - letztendlich geholfen hat, dass ich die Aktualisierungszeiten der angezeigten Variablen stark überarbeitet habe. z.B. müssen ja die Var's nur in dem Takt aktualisiert werden, wie sie sich ändern ... Das hat dann den Erfolg gebracht. Seit dem läuft es störungsfrei.

Vielleicht hilft dir das weiter ...
Gruß
LL

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo LL.

Nachdem das du den änderung mit den quittierbit programmiert hast, hattest du den überlauf fehler wieder ?

Das mit den tag-verzögerung zwisschen SPS und HMI, galt dies nur für den wertänderungstag, oder auch für andere tags ?
So etwas habe ich nicht selber gesehen. Es wurde auch ein andere fehler auslösen als den überlauf fehler.

Ich kann nicht den skript aktualisierenszeit verlängern weill ich lest von den datenbank. Ich muss relativ schnell erkennen wenn es neue daten im datenbank gibt. Und ich glaube das das problem kommt als ein ausnahme wenn es verbindungsprobleme gibt zwisschen ODBC treiber und datenbank.
Mein kunde kann nicht (will nicht ?) selber die daten per ereignis übertragen.

 

[Larry Laffer]

Nach der Änderung hatte ich keinen Überlauf mehr ... ist auch logisch, wenn man auf deinen Beitrag #4 schaut ...

Die Verzugszeiten hatte ich dann im Programm - es ging mir an der Stelle darum, dir die Historie / den Werdegang der Sache aufzuzeigen.

Wie schon gesagt. Meine Abhilfe war die Anzeigeelemente genau zu bewerten. Hier hatte ich sehr viel auf Aktualisierungszeit "1 Sek" - jetzt steht bei sehr vielen "2 Sek" oder auch "3 Sek". Das hatte auf die Performance der Visu fast keinen Einfluß - da mußt du bei dir vielleicht mal schauen.
Hast du auch Kurven oder Trends mit in deinem Projekt ... hier läßt sich auch einiges machen, weil die ja ständig aktualisiert werden ...

Gruß
LL

 

[JesperMP]

Ich habe relativ viele tags, meistens mit 1 sek aktualisierungstaks, einige mit 0.4 sek aktualisiereungstakt.
Aber die PC CPU belastung ist null-und-nichts.
Für die ethernet verbindung ist die netzwerk belastung konstant za. 0.2% (fantastisch wie viel "saft" man hat mit ethernet).
Auf diesen grund glaube ich nicht das das problem mit zu vielen tags zwisschen SPS und HMI zu tun hat.

Für die datenbank verbindung (andere netzwerk karte) ist die netzwerk belastung konstant 0%, aber springt zu 5-10% wenn ein ODBC lese auftrag angestossen wird.
Es ist also heftiger 10 werte über ODBC zu lesen, als 1000 werte über S7 ethernet verbindung zu lesen.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kann dir nur das schildern, was ich selbst erfahren habe ...
Was du daraus machst, mußt du selber wissen ...
Gruß
LL

 

[Larry Laffer]

Hallo Jesper,
gibt es bei dir neue Erkenntnisse ...?
Da ich ein ähnliches Problem habe würden mich deine Ergebnisse natürlich brennend interessieren.

Gruß
LL

 

[afk]

in vielen sprachen gibt es eine

try{befehl}
catch{z.b. fehlermeldung}

das verhindert timeout-probleme, aber ob das in winCC verfügbar ist? *schulterzuck*

Das ist Quatsch, mit try ... except kann man zwar einen Fehler erkennen und behandeln, aber nicht verhindern. Das von Jesper beschriebene Problem ist aber ein Folgefehler, der ja gerade durch die lange Zeit bis zum Erkennen des Fehlers (Auslösen des Timeouts) hervorgerufen wird.

Zum eigentlichen Problem:
Ich kenne WinCC-flex zwar überhaupt nicht, aber bei den ADO-Komponenten gibt es normalerweise jeweils eine Eigenschaft für den Connection-Timeout (beim Connection-Object, per Default 15 Sek.) und für den Command-Timeout (beim Recordset-Object und Command-Object, per Default 30 Sek.). Beide Timeouts werden in Sekunden angegeben, und besonders bei Verbindungen zu einer Datenbank auf dem gleichen PC oder im LAN kann man den Connect-Timeout meist problemlos verkürzen. Der Command-Timeout muß aber lange genug sein, damit die Abfrage innerhalb dieser Zeit auch in jedem Fall von der Datenbank verarbeitet werden kann.


Gruß Axel

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist Quatsch, mit try ... except kann man zwar einen Fehler erkennen und behandeln, aber nicht verhindern. Das von Jesper beschriebene Problem ist aber ein Folgefehler, der ja gerade durch die lange Zeit bis zum Erkennen des Fehlers (Auslösen des Timeouts) hervorgerufen wird.

zum zeitpunkt des eintrags war noch nicht raus, dass der fehler durch die lange bearbeitungszeit entsteht PUNKT

 

[afk]

zum zeitpunkt des eintrags war noch nicht raus, dass der fehler durch die lange bearbeitungszeit entsteht PUNKT

Dann formuliere ich es kürzer:
Mit try ... except kann man nur bereits aufgetretene Fehler behandeln, aber nicht verhindern. Also trotzdem Quatsch.


Gruß Axel

 

[vierlagig]

Dann formuliere ich es kürzer:
Mit try ... except kann man nur bereits aufgetretene Fehler behandeln, aber nicht verhindern. Also trotzdem Quatsch.


Gruß Axel

hmm ... es verhindert nicht den fehler, aber es verhindert, dass man lange darauf warten muß bis einem mitgeteilt wird das ein fehler aufgetreten ist

 

[afk]

Zuviel Werbung?
-> Hier kostenlos registrieren

hmm ... es verhindert nicht den fehler, aber es verhindert, dass man lange darauf warten muß bis einem mitgeteilt wird das ein fehler aufgetreten ist

Nö, eben nicht, der Timeout dauert genau gleich lang, mit try ... except kann man ihn danach nur "ordentlich" behandeln.


Gruß Axel

 

[vierlagig]

Nö, eben nicht, der Timeout dauert genau gleich lang, mit try ... except kann man ihn danach nur "ordentlich" behandeln.


Gruß Axel

in C# habe ich andere erfahrungen gemacht *grübel*

 

[Larry Laffer]

@afk und 4L :
Es ist schön, wie ihr hier philosophiert ... das hat nur leider (aus miener Sicht) gar nichts mit dem "Fehler" zu tun. Es ist auch kein Fehler sondern eher ein Ablauf-Problem. Das Script ist ja gar nicht fehlerhaft sondern es tritt eine Art Stau im Scripte-Stapel auf. Dieser rührt aus meiner Sicht von einer Überlastung die ursächlich aus dem Variablen-aktualsieren kommt. Das war jedenfalls meine Erkenntnis, die ich gewonnen habe. Es schein mir auch bei Jesper so sein :

Ich habe relativ viele tags, meistens mit 1 sek aktualisierungstaks, einige mit 0.4 sek aktualisiereungstakt.

Mein Augenmerk hier besonders die 0,4s-Tags. Dennoch bin ich auf Jesper's Ergebnisse (so er sie kundtut) gespannt, da es mir vermutlich auch weiterhelfen könnte ...

In diesem Sinne ...
Gruß
LL