Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 40

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

  1. #1
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard


    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.
    Jesper M. Pedersen
    Zitieren Zitieren VBscript. Was passiert wenn man 2 Skripte auf einmal auslöst ?  

  2. #2
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.793
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    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

  3. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    JesperMP (06.06.2008)

  4. #3
    Avatar von JesperMP
    JesperMP ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

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

  5. #4
    Avatar von JesperMP
    JesperMP ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    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.
    Jesper M. Pedersen

  6. #5
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    in vielen sprachen gibt es eine

    Code:
    try{befehl}
    catch{z.b. fehlermeldung}
    das verhindert timeout-probleme, aber ob das in winCC verfügbar ist? *schulterzuck*
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  7. #6
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.793
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    ... 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

  8. #7
    Avatar von JesperMP
    JesperMP ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    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 ?
    Jesper M. Pedersen

  9. #8
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.793
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    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

  10. #9
    Avatar von JesperMP
    JesperMP ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.639
    Danke
    377
    Erhielt 803 Danke für 644 Beiträge

    Standard

    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.
    Jesper M. Pedersen

  11. #10
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.793
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. Antworten: 3
    Letzter Beitrag: 01.04.2011, 10:37
  2. Antworten: 18
    Letzter Beitrag: 25.01.2011, 10:33
  3. Was passiert Dienstag 8:00 ?
    Von JesperMP im Forum Simatic
    Antworten: 106
    Letzter Beitrag: 16.12.2010, 17:28
  4. RAM zu ROM, erforderlich/ was passiert dann?
    Von TommyG im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 27.04.2008, 14:36
  5. Was passiert mit dem Luftballon?
    Von 1schilcher im Forum Stammtisch
    Antworten: 11
    Letzter Beitrag: 30.03.2008, 14:46

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •