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

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

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.

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


Gruß Axel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.


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

Code:
 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
 
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
 
@larry: der ansatz klingt nicht schlecht... was ist wenn man die verbindung offen läßt? kommt das nicht aufs selbe?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:
Code:
' 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
If SmartTags("ODBC\strTableName_writeDB") = "" Then SmartTags("ODBC\strTableName_writeDB") = "disa.mw_cdr_jnl" 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
chDecPoint = Mid(CStr(8.1), 2, 1)
If SmartTags("ODBC\debug_message_on") And Not chDecPoint = "." Then ShowSystemAlarm "Decimal separator is wrong. Set to '.' in Windows Control Panel .. Regional settings."

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")
'conn.Open "Provider=MSDASQL;Initial Catalog=" & strNameOfDatabase & ";" & strDSN

If Err.Number <> 0 Then
ShowSystemAlarm "Error #" & Err.Number & " " & Err.Description
Err.Clear
Exit Sub
End If

SQL_Table = "SELECT * FROM " & SmartTags("ODBC\strTableName_writeDB") 'no WHERE because there is only 1 record.
'Writes a data record into a table
Set rst = conn.Execute(SQL_Table)
'Error routine - Fehler Routine
If Err.Number <> 0 Then
ShowSystemAlarm "Error #" & Err.Number & " " & Err.Description
Err.Clear
Exit Sub
End If

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
'Definition of data record
SQL_Table = "INSERT INTO " & SmartTags("ODBC\strTableName_writeDB") & " (" & _
"shift_date, " & _
"mold_no, " & _
"setpoint_vol_of_water, " & _
"vol_of_water, " & _
"mold_temp, " & _
"sand_temp, " & _
"cdr_stat1, " & _
"cdr_stat2, " & _
"cdr_stat3 " & ") VALUES (" & _
SmartTags("ODBC\ToDB\arrayFromCDR")(0) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(1) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(2) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(3) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(4) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(5) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(6) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(7) & ", " & _
SmartTags("ODBC\ToDB\arrayFromCDR")(8) & ")"
If SmartTags("ODBC\debug_message_on") Then ShowSystemAlarm SQL_Table
'Insert the data reacord of the table
Set rst = conn.Execute(SQL_Table)
End If

'Close data source
conn.close
Set rst = Nothing
Set conn = Nothing
 
Zuletzt bearbeitet:
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
 
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.

Code:
 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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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
 
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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)?
 
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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
 
Zurück
Oben