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



## JesperMP (6 Juni 2008)

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 (6 Juni 2008)

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 (6 Juni 2008)

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


----------



## JesperMP (9 Juni 2008)

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 (9 Juni 2008)

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 (9 Juni 2008)

... 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 (9 Juni 2008)

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 (9 Juni 2008)

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 (9 Juni 2008)

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 (9 Juni 2008)

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 (9 Juni 2008)

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 (9 Juni 2008)

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


----------



## Larry Laffer (10 Juni 2008)

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 (10 Juni 2008)

vierlagig schrieb:


> in vielen sprachen gibt es eine
> 
> 
> ```
> ...


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 (10 Juni 2008)

afk schrieb:


> 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 (10 Juni 2008)

vierlagig schrieb:


> 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 (10 Juni 2008)

afk schrieb:


> 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 (10 Juni 2008)

vierlagig schrieb:


> 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 (10 Juni 2008)

afk schrieb:


> 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 (10 Juni 2008)

@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


----------



## afk (10 Juni 2008)

vierlagig schrieb:


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


Da trügt Dich bestimmt Deine Erinnerung ... 


Gruß Axel


----------



## afk (10 Juni 2008)

Larry Laffer schrieb:


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


Ich philosophiere nicht, ich korrigiere nur eine falsche Aussage, die man IMHO so nicht stehen lassen kann. 



Larry Laffer schrieb:


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


Da bin ich ganz Deiner Meinung, nur daß ich aufgrund Jespers Beschreibung einen anderen Grund für das Problem vermute als Du, wie ich hier auch zusammen mit einem mir bekannten Lösungsweg zu dem Problem aufgezeigt habe, wobei ich leider nicht weiß, ob das unter WinCC-Flexible auch funktioniert.



Larry Laffer schrieb:


> In diesem Sinne ...


*ACK*, ich bin auch auf die Auflösung gespannt ...


Gruß Axel


----------



## JesperMP (11 Juni 2008)

afk schrieb:


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


Das war sehr hilfreiche Informationen.
Die 15-30 Sekunden Timeout kann genau erklären, warum ein Skript bufferüberlauf passiert, wenn das Skript alle 3 sekunden ausgelöst wird.
Ich werde in diese ein bisschen mehr untersuchen.


----------



## JesperMP (11 Juni 2008)

Larry Laffer schrieb:


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


 
Ich tue die Fehlersuche und Änderungen per email (!). 
Der Kunde ist in Japan, und ist sehr, sehr vorsichtig.
Leider ist der nächste "Fenster" für ein Programmänderung erst Freitag 20. Juni.




Larry Laffer schrieb:


> Mein Augenmerk hier besonders die 0,4s-Tags.


Ja, es gibt tags mit 0.4 sek aktualisierungs takt.
Aber das skript wird mit 3 sekunden getriggert.
Ich glaube nicht dass die 0.4 sekunden tags probleme verursachen.

Es ist mir jetzt klar das es ist notwendig den ADODB timeout zeit von 15-30 sekunden auf 5-10 sekunden zu bringen.
Ich habe jetzt folgendes eingefügt:
conn.connectionTimeout 5
conn.commandTimeout 5

Dazu habe ich folgendes geändert:
Skript wir nur gestartet wenn vorige skript erfolgreich beiendet ist plus 3 sekunden wartezeit, oder nach ein timeout von 10 sekunden.

Ich bin überzeugt das die programmänderungen das problem mit Skript überlauf vermeiden will.
Das ursprüngliche (und eigentliche) Problem hatte mit der Netzwerkverbindung zu der Datenbank oder der Datenbank selber zu tun. Dafür ist meine Kunde verantwortlich. 
Doch der Effekt war, dass mein Skript gestört wäre und nicht wieder automatisch wiederholen konnte.

Von diesen thread habe ich viel gelernt.
Danke an LL und AFK !


----------



## afk (11 Juni 2008)

JesperMP schrieb:


> Danke an LL und AFK !


Gern geschehen. 
Laß mal hören, ob die Änderung den gewünschten Erfolg gebracht hat, sobald Du mehr weißt.


Gruß Axel


----------



## JesperMP (11 Juni 2008)

Ich kann voraussagen, dass wenn die Überlauf-Fehler wird gelöscht, dann beginnt die Jagd auf das eigentliche Problem.


Ich möchte gerne eine bessere Fehlerdiagnose für die Endbenutzer.
Es wäre gut zu wissen, ob das Problem mit der Datenbank, oder mit dem Netz liegt.
Dafür spekuliere ich jetzt, ob ich ein "Ping"-SKript starten soll (nur einmal), in den Fall das es gibt ein Fehler mit ADODB.


```
dim strTarget, strPingResults, biPingDone
 
On Error Resume Next
 
strTarget = "10.1.0.7" 'IP address or hostname of server

Set objShell = CreateObject("WScript.Shell")

IF NOT biPingDone THEN 
  Set objExec = objShell.Exec("ping -n 2 -w 1000 " & strTarget)
  strPingResults = LCase(objExec.StdOut.ReadAll)
  IF NOT InStr(strPingResults, "reply from")  THEN 
    ShowSystemAlarm("There is no LAN connection to the database server !")
  END IF
  biPingDone = TRUE
END IF
```


----------



## Larry Laffer (15 Juni 2008)

Mir ist da noch etwas eingefallen - vielleicht bringt es was ...

Wie gestaltet sich konkret dein Zugriff auf die Datenbank (Code-Beispiel) ?
Ich hatte da vor sehr langer Zeit mal was (da ging es aber um Lesen). Dabei war der Zugriff auf die Datenbank das was Zeit gekostet hat. Hatte man dann den Zugriff, dann war es (fast) egal ob man 1 oder 100 Variablen gelesen hat. Vielleicht ist das bei dir so ähnlich. Wenn ja, dann könntest du doch die Datensätze in der Visu zunächst (lokal) puffern und irgendwann 5 oder 10 Datensätze schreiben. Ggf. bekommst du dann von der Überlast etwas weg ...

Und noch etwas ...

Wieviele Scripte werden denn noch so in deinem Projekt angestossen und welchen Zweck haben sie ?
Vielleicht ist es möglich, da etwas zu optimieren ...

Gruß
LL


----------



## vierlagig (15 Juni 2008)

@larry: der ansatz klingt nicht schlecht... was ist wenn man die verbindung offen läßt? kommt das nicht aufs selbe?


----------



## JesperMP (15 Juni 2008)

Hallo LL

Es gibt zwei Skripte.

En "lese" skript, das ich leider immer zyklisch aufrufen muss, wegen das ich erkennen muss wenn ein neuen teil gefertigt ist in kundensitige maschine.
Jetzt will ich es so ändern dass ich ein quittierung bekommt bevor ich das nächste lese-skript auslöst.

Dann gibt es ein "rückmeldungs"-skript an den kunde, so das er verschiedene daten bekommt über den teil.

Beide SQL operationen bestehen von nur 2 records (1 in jeder richtung). Die daten sind "fields" innerhalb diese records.
Also, es ist so einfach und schnell wie möglich denke ich.

Lese skript:

```
' en: The script reads the indicated data record
'Declaration of local tags
Dim conn, rst, SQL_Table, strNameOfDatabase, strDSN, strNameOfTable, strConnect
If SmartTags("ODBC\for_test_block_ODBC") Then Exit Sub
If SmartTags("ODBC\strTableName_readDB") = "" Then SmartTags("ODBC\strTableName_readDB") = "disa.mw_cdr_mold_info" End If
If SmartTags("ODBC\strDSN_connect") = "" Then SmartTags("ODBC\strDSN_connect") = "Driver={Microsoft ODBC for Oracle};Server=MWE1_MSYS;UID=DISA;PWD=DISA" End If
On Error Resume Next
Set conn = CreateObject("ADODB.Connection")
Set rst = CreateObject("ADODB.Recordset")
'Open data source
conn.Open SmartTags("ODBC\strDSN_connect")
If SmartTags("ODBC\debug_message_on") Then ShowSystemAlarm "conn.open " & SmartTags("ODBC\strDSN_connect")
If Err.Number <> 0 Then
 ShowSystemAlarm "Error #" & Err.Number & " " & Err.Description
 Err.Clear 
 Exit Sub
End If
 
SQL_Table = "SELECT * FROM " & SmartTags("ODBC\strTableName_readDB")
'Reads the data records of the SQL table
 If SmartTags("ODBC\debug_message_on") Then ShowSystemAlarm SQL_Table
Set rst = conn.Execute(SQL_Table)
'Error routine
If Err.Number <> 0 Then
 ShowSystemAlarm "Error #" & Err.Number & " " & Err.Description
 Err.Clear 
 Exit Sub
End If
If SmartTags("ODBC\debug_message_on") Then ShowSystemAlarm SQL_Table
 
If Not (rst.EOF And rst.BOF) Then 
 'Compare if "End of File" or "Begin of File" exists, if not the pointer will be reset to the first entry
 rst.MoveFirst 'reset to 1st entry 
 'read from DB values into HMI tags
 SmartTags("ODBC\FromDB\cdr_type") = rst.Fields(0).Value
 SmartTags("ODBC\FromDB\shift_date") = rst.Fields(1).Value
 SmartTags("ODBC\FromDB\mold_no") = rst.Fields(2).Value
 SmartTags("ODBC\FromDB\cool_time") = rst.Fields(3).Value
 SmartTags("ODBC\FromDB\into_frm_wt") = rst.Fields(4).Value
 SmartTags("ODBC\FromDB\into_sand_wt") = rst.Fields(5).Value
 SmartTags("ODBC\FromDB\flow_temp") = rst.Fields(6).Value
 SmartTags("ODBC\FromDB\frame_stat") = rst.Fields(7).Value
 SmartTags("ODBC\FromDB\updown_rate") = rst.Fields(8).Value
 'read from DB values into PLC tags
 SmartTags("ODBC\FromDB\arrayToCDR")(0) = rst.Fields(0).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(1) = rst.Fields(1).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(2) = rst.Fields(2).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(3) = rst.Fields(3).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(4) = rst.Fields(4).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(5) = rst.Fields(5).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(6) = rst.Fields(6).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(7) = rst.Fields(7).Value
 SmartTags("ODBC\FromDB\arrayToCDR")(8) = rst.Fields(8).Value
 rst.close 
Else
 ShowSystemAlarm "Dat_No. is not available"
End If
 
'Close data source
conn.close
Set rst = Nothing
Set conn = Nothing
```
 
Rückmeldungs-skript:


> ' en: The script wirtes the indicated data record into a table
> 
> Dim conn, rst, SQL_Table, chDecPoint, strNameOfDatabase, strDSN, strNameOfTable
> If SmartTags("ODBC\for_test_block_ODBC") Then Exit Sub
> ...


----------



## Larry Laffer (16 Juni 2008)

vierlagig schrieb:


> was ist wenn man die verbindung offen läßt? kommt das nicht aufs selbe?


 
Daran hatte ich auch schon gedacht.
Also statt CreateObject bei jedem Aufruf nur einmal CreateObject, sich merken, dass das Objekt existiert und bei jedem weiteren Aufruf mit GetObject den Handle holen. Ist auf jeden Fall einen Versuch wert. Bei meinen eigenen Excel-Zugriffen hat das enorm was gebracht.

Gruß
LL


----------



## JesperMP (1 Oktober 2008)

Leider habe ich einige schlechte Nachrichten.
Nachdem ich die Änderungen  eingefügt haben (siehe unten) dachte Ich, das Problem wurde geheilt, oder zumindest besser behandelt.
Aber es ist wie vorher, die kunde bekommt den fehlermeldung 20015 (Skript Überlauf), ohne das es ein andere Fehlermeldung kommt (z.b. fehler beim ODBC zugriff).
Es ist wie das timeout zeit noch 15 sekunden ist, und nicht 5 sekunden wie ich es eingestellt habe.


```
Set conn = CreateObject("ADODB.Connection")
Set rst = CreateObject("ADODB.Recordset")
[U]conn.connectionTimeout=5
conn.commandTimeout=5[/U]
conn.Open SmartTags("ODBC\strDSN_connect")
  If SmartTags("ODBC\debug_message_on") Then ShowSystemAlarm "conn.open " & SmartTags("ODBC\strDSN_connect")
  If Err.Number <> 0 Then
    ShowSystemAlarm "Error #" & Err.Number & " " & Err.Description
    Err.Clear 
    [U]Exit Sub[/U]
  End If
 
(usw..)
```
Diese code sollte eigentlich dafür sorgen das es kommt ein fehlermeldung beim fehlerhafte ODBC zugriff, und ohne das es zu ein Skript Überlauf kommt.

Es passiert nur nach einige wochen, aber ist dennoch nervend.


----------



## MeTh (1 Oktober 2008)

Hallo,

wir hatten ein ähnliches Problem. wir mussten uns die Daten von mehreren Pc's aus Textdateien auslesen, und immer wenn ein Pc nicht erreichbar war, gab's Probleme.

Wir haben das gelößt, in dem wir alles mit einem 2. Programm Lokal auf die Platte kopieren (jede Minute).

Die Daten die dann weitergegeben werden stehen alle in einem 2. Verzeichnis und werden dann gesammelt jede Minute auf die Datenbank
kopiert. Wenn nicht erreichbar --> versuche es in der nächsten Minute.

Scheint bei dir schneller gehen zu müssen. Vielleicht hilft es trotzdem weiter.

LG MeTh.


----------



## Larry Laffer (1 Oktober 2008)

Hallo Jesper,

das sieht dann für mich so aus, dass du einfach während des ODBC-Zugriffs zu lange brauchst (im Grunde hat *MeTh* so etwas ähnliches geschrieben).
Vielleicht wäre es wirklich sinnvoll, dass du mit der Visu so eine Art Batch erstellst (als Text-Datei) in die du die Daten hineinschreibst und mit einer seperaten Anwendung (außerhalb der Visu) die Daten daraus in die Datenbank übermittelst ...

Gruß
LL


----------



## JesperMP (13 Oktober 2008)

Beim test zuhause habe ich jetzt gefunden, das den wert _conn.connectionTimeout_ kein einfluss auf den tatsäglichen timeout hat (!?).

Laut beschreibung von ADO ist den default timeout 30 sekunden.
Das "lustige" ist, das ich kriege ein timeout alarm nach ungefähr 7 sekunden (manchmal 20 sekunden !?), egal was ich mit _conn.connectionTimeout_ probiere.

Hat jemand ein idee ?


----------



## Redi (28 Juli 2011)

*Handling von "grosser" Datenbank*

Hallo zusammen.
Dieser Thread ist zwar nicht mehr gerade Taufrisch, trifft aber die Problematik mit der ich mich im Moment beschäftige recht gut. 
Ziel meiner Anwendung ist es für das QS verschiedene Parameter für ein Produkt(stück) in einem Assemblierautomat zu erfassen. Pro Datensatz (Zeile) fallen ca 500 Byte an. Pro Sekunde wird ein Produkt fertiggestellt, d.h pro Stunde 3600 Datensätze, pro Jahr gibt das etwas 30 mio. Datensätze (24/7). Das ganze soll auf einem Industrie Panel PC mit WinCC flexible RT laufen, die Daten werden auf dem IPC gespeichert. 
So was ich im Thread gelesen habe sollte das "schnelle" schreiben "kein" Problem sein (keine entfernter Partner der nicht anwortet). Was mir jedoch ein bisschen sorgen macht, ist das grosse Datenaufkommen das entsteht. In einem Jahr kommen da etwa 10GB zusammen. Gibt es ein Limit für die maximale Anzahl Zeilen in einer MySQL tabelle. Hat jemand Erfahrung wie schnell ein Suchvorgang in einer Datenbank mit 30 mio Einträgen dauert (z.B. ausgabe der am Datum xy hergestellten Produkte). Ist es noch handlebar wenn man mehrere Jahre behalten will z.B. 5 Jahre (150 mio. Einträge)?


----------



## Larry Laffer (29 Juli 2011)

Hallo,
ich kann da nicht auf Erfahrungswerte zurückgreifen ... aber diese vielen Daten in dem kurzen Intervall sehe ich als problematisch an (aus dem Bauch heraus) weil :
- es ggf. schwierig wird, die Daten konsistent (also zusammengehörig) zu haben vor dem Abspeichern.
- ich mir vorstellen kann, dass die Datenbank (nicht sofort aber später, wenn sie größer ist) den einen Datensatz noch nicht abgespeichert hat und du schon mit dem Nächsten kommst.
- der Rechner ggf. an seine Leistungsgrenzen kommt.


Mein Vorschlag :
Du erzeugst die Daten in handelbaren Untermengen (z.B. pro Stunde oder ggf. pro Tag) und übergibst die Sachen dann einem anderen System, dass die dann zusammenführt und das dir dann auch die Möglichkeit für Visualisierung derselben oder Auswertung bietet.

Gruß
Larry


----------



## JesperMP (2 August 2011)

Nur als Kommentar:

Nach meine Erfahrungen mit WinCC Flex RT + VBS für SQL Datenoperationen, wurde ich nie wieder so eine Lösung empfiehlen.
Das Problem ist das VBS Fehlerhantierung ist einfach zu primitiv.

Für "nice-to-have" Funktione, dann eventuell ja.
Für kritische oder nur "wichtige" Funktione, dann absolut nein.

Die obige Geschichte hat mir eine extra Reise nach Japan gekostet, um eine Datanbank Software (*) zu installieren so das Problem endlich gelöst wurde.

*: FactorySQL von Inductive Automation.


----------



## Redi (2 August 2011)

Danke für Eure Antworten!

Je länger ich an diesem Projekt dran bin, desto mehr komme ich weiter weg komme ich von WinCC flexible. Ich habe die Archivierung (auch mit Hilfe des Forums) mit dem Schreiben in ein Textfile gelöst, das funktioniert für den Prototyp anstandslos... Für die weiteren Maschinen suche ich jedoch eine andere Lösung die dann wirklich zuverlässig und in diesem Fall auch schnell mit einer Datenbank zusammenarbeitet, oder ist generell eine entkopplung wie sie von Larry genannt wurde, zu empfehlen? 
Um mal in der Siemenswelt zu bleiben, kennt jemand sich aus mit solchen Problemstellungen in WinCC (und dem Addon PM Quality) aus. Einige denen ich meine Problem geschildert habe, haben dann auf WinCC verwiesen, aus Zeitdruck habe ich mich dann für WinCC flexible entschieden, da ich dieses schon kenne... Ein anderer Input war die Daten direkt via Soft SPS RTX in die Datenbank zu schreiben. Oder hole ich mir dann die Probleme nur noch eine Stufe tiefer auf die Steuerungsebene.
Kennt Ihr weitere Lösungen nebst der von Jasper genannten...?

Gruss
Daniel


----------



## Larry Laffer (2 August 2011)

Hallo,
der Vorschlag von Jesper würde ich als die Profi-Lösung einstufen. Wir selbst beschäftigen uns auch (z.Zt. noch ein wenig nebenbei) mit einer ähnlichen Ankopplung - hier auch auf einen Datenbank-Server (bei uns Microsoft).

Die von mir geäußerte Empfehlung (anders solltest du es nicht verstehen) entstammt aus einer mehr oder weniger leidvollen Erfahrung, die schon zu ProTool-Zeiten ihren Anfang genommen hat. Ich habe aber in dieser Hinsicht für Flex auch noch keine anders-lautenden Erfahrungen gemacht - dadurch ist es für mich dann so zu einer Art Grund-Spielregel geworden. 

Gruß
Larry


----------



## NikolausL (2 August 2011)

Hallo,

ein anderer Vorschlag: Für die WinAC RTX gibt es ein ODK. Mit diesem können Visual Studio Programme über S7 aufgerufen werden.
Mann könnte denn Datenbankzugriff in Visual Studio Programm kapseln.
Die Abarbeitung der Programme hier wesentlich schneller, der Datenaustausch zwischen Visual Studio Programm und SPS erfolgt über Shared Memory.

Viele Grüße 
Klaus


----------

