Index-Beschränkung in For-Schleife bei WinCC flex. 2008

Hexmex

Level-2
Beiträge
52
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

Weiß jemand ob es bei einer Indexvariablen in einem VBS Script von WinCC Flexible 2008 Sp3 eine Beschränkung gibt?
Kann es sein, dass eine For..Next-Schleife nur eine begrenzte Anzahl an Durchläufe machen kann?
Ich denke da jetzt aber nicht an die Begrenzung durch den Datentyp (Int).
Ich möchte eine Schleife 1632 mal durchlaufen, ist das prinzipiell möglich?

Danke für eure Antworten!
 
Hallo Froma,

eine Beschränkung bei For..Next-Schleifen-Indexvariablen wäre mir neu. Wobei ich gestehen muss, dass ich noch nie eine so 'große' Schleife benötigt habe... :-?


Gruß, Fred
 
Nur das Script wird lange dauern.
Dies wird eventuell andere Scripte behindern, aber der RT selber nicht.

Warum einfach nicht probieren und sehe wie es geht ?
 
nö, keine beschränkung.
bei einem ce panel wird es ein wenig dauern. bei eine pc477 geht es mitlerweile recht flot. do while mit end loop fallen mir perönlich leichter und da ist der rekord bei mir knapp 4 000 durchläufen. lief war aber eigene dumheit :). habe es dann anders gelöst. die skripte auf dem pc werden im windoofs ausgeführt. windoof ist also die eigenliche grenze.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ok, schon mal danke für eure antworten!

bin jetzt trotzdem noch sehr verwirrt...
hab nämlich folgendes problem:

ich bekomme bei nachstehendem script immer die meldung "überlauf des index k" (oder so ähnlich; siehe bitte screenshot).
warum ist das so? kann mir dabei jemand helfen?
ich habe nämlich das problem, dass das script manchmal richtig arbeitet, also die daten einer csv (in tabellenform) einliest, diese als textstream umwandelt und anschließend als eindimensionales datenfeld über die gezeigte schleife an den DB schickt. manchmal funktioniert das und manchmal eben nicht. wenn es nicht funktioniert, dann werden nicht alle 1700 schleifendurchgänge gemacht, sondern nur 100 - komisch!?!?


DB_Datensicht.JPGDB_Deklarationssicht.JPGscriptcode.JPGvariable.JPGausgabe.jpg
 
Check mal was Systemfehler 190010 bedeutet.
Es kann sein dass das Problem ist das 1700 REALs (=6800 bytes) sind zu viel.
Abhängig von CPU Type kann nur eine gewisse Menge von Bytes auf einmal übertragen werden.
Ich meine das für eine S7-300 ist es ungf. 240 Bytes.

Was WinCC Flex tut in diesen Situation, ist mir nicht ganz klar. Ich glaube das es versucht die Datenmenge über mehrere Sendaufträge zu verteilen. Kann sein das auch Zeifverhältnisse kommen ins Spiel.
 
Hallo,
das mit dem "Überlauf von k" könntest du ja damit abfangen, dass du den SmartTag nur zuweist wenn k <= 1699 ist - auch wenn in deiner Schleife k eigentlich nicht größer als 1699 werden kann.
Die Überlast-Meldung besagt, dass dein Script-Puffer voll ist. Es können nur 20 Scripte in Bearbeitung sein - das 21. (und folgende) wird verworfen.
Du solltest ggf. mal checken, ob die Bearbeitung deines Scriptes schon beendet ist bevor es wieder aufgerufen wird. Außerdem, was ggf. vorhandene weitere Scripte noch machen.
In jedem Fall sieht das für mich so aus, als wenn deine Fehlermeldungen in Zusammenhang mit der "Überlast"-Meldung stehen ...

Gruß
Larry

Nachsatz:
wann wird das Script aufgerufen ? Automatisch über eine SPS-Trigger-Variable ? Wenn ja ... eine Bool ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aus den WinCC Flex RT User Manual:

Für Event # 190010:
Too many values are written to the tag (for example, in a loop triggered by a script).
Values are lost because only up to 100 actions are saved to the buffer.
Ich bin relativ sicher das es handelt um zu viele Bytes in Verhältniss zu was möglich ist.

Es ist mir nicht klar warum der Index K ein System Event # 20010 auslöst.

Larry Laffer schrieb:
Die Überlast-Meldung besagt, dass dein Script-Puffer voll ist. Es können nur 20 Scripte in Bearbeitung sein - das 21. (und folgende) wird verworfen.
Das ist hier nicht der Fall.
Das wäre Event # 20015.
 
Zuletzt bearbeitet:
@Jesper:
An ein Problem mit der Größe des Datenpakets, das auf einen Schwung übertragen werden kann, habe ich auch schon gedacht. Aus diesem Grund wollte ich die Daten in "50er"-Blöcken übertragen. Ich möchte ja lauter Realwerte übertragen (entspr. 4Byte * 50 = 200Byte) -> sollte bei einer max. Übertragung von 240Byte kein Problem sein..:confused:

@Larry:
Ich trigger das Script mit einer internen Bool-Variable (siehe Screenshot). Zu Info, ich habe nur noch ein einziges weiteres Script in Verwendung, dieses wird ebenfalls nur einmal als Button-Event aufgerufen. In diesem Script lese ich den Dateipfad der zu übertragenden CSV-Datei ein und prüfe deren Plausibilität. Das sollte also nicht in das Script zur Übertragung mitreinpfuschen.
Ich habe irgendwie die vermutung, dass die Aktualisierungszeit der Visu mit der Zykluszeit der CPU ein Problem darstellt..

Scriptaufruf.JPG
 
Ich hatte so ein ähnliches Problem auch schon, wollte einige Produktionsdaten in eine CSV schreiben, so ca. 100 Variablen (Bool, Real, Int).
Es kamen zwar keine Fehlermeldungen, und das ganze hat teilweise auch funktioniert, aber es kam immer wieder zu Problemen das manchmal nicht alle Daten übertragen wurden.
Hab ewig an dem Problem rumgemacht, war auch viel im Kontakt mit Siemens...
Zum Schluss hab ich ne externe Software gekauft (HSDBase).
Also wenn du es irgendwie anderst lösen kannst, dann geh lieber den anderen, sichereren Weg...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das mit dem "teilweisen funktionieren" kenne ich auch. manchmal führe ich das script aus und es funktioniert einwandfrei. alle datenplätze werden beschrieben, die reihenfolge der daten stimmt. und manchmal funktionieren eben nur die ersten 100 plätze. da ich hin und wieder einen volltreffer mit dem script lande, bezweifle ich, dass das script einen fehler enthält. meine vermutung geht in richtung aufruf des scripts und datenerfassungszeit (also einlesezeit der cpu) für die db-daten. dort vermute ich mein problem.

was bittet denn diese software von hdsbase? würde es eine csv einlesen und in einen DB schreiben?
 
Das Problem ist vermutlich das WinCC Flex RT überträgt erst die Daten am Ende des Script. Dann hilft es nicht die Daten zu verkleinern und verteilen innerhalb von den Script.
Genau wann und wie WinCC Flex Daten übertragen die in Scripte addressiert werden bin ich nicht 100% sicher.
Es gab schon einige Threads zu diesen Thema.

Ich glaube das wenn man Rezepte verwendet wird es zuverlässig von WinCC Flex RT hantiert.
 
1. Jeder Zugriff auf ein SmartTag-Array liest oder schreibt das gesamte Array - daher die Kommunikationsüberlast.
2. 1700 Real in einem Kommunikationsauftrag sind zuviel
3. Es werden auch noch Probleme mit der Aktualisierung der Variablenwerte kommen.

Datentransport per WinCC flexible-Script von CPU in eine Datei ist nur per Datensatz-Lesen beherrschbar - zum Problem, wie man Daten sicher liest und in eine Datei schreibt, gibt es hier im Forum schon viele Threads und Diskussionen.

Harald
 
@TE:
Wenn du mit einem Bool triggerst (auf Wertänderung) dann bedenke bitte, dass das Setzen des Bools eine Wertänderung ist und das Rücksetzen auch. Das solltest du im Script schon mal abfangen.

@Harald:
Um den Kommunikationsauftrag sollte Flex sich schon selber kümmern. Darauf haben wir so oder so keinen Einfluß. Ob das mit den 1700 Elementen eine Rolle spielt kann ich nicht beurteilen - 900 Elemente hatte ich aber schon mal und das hatte geklappt. Die Sache mit der Daten-Konsistenz ist natürlich nicht von der Hand zu weisen. Ich tippe hier aber tatsächlich auf zu häufiges Triggern - ggf. in Verbindung mit der übrigen Tag-Aktualisierung und der Rate derselben für die/alle anderen Tags.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich weiß jetzt nicht, wo in WinCC flex die Systemgrenze für die max Anzahl Variablen bzw. Elemente eines Arrays liegt, doch ich meine oft gelesen zu haben, daß das Lesen von mehr als 1000 Elementen immer wieder Probleme machte. Wir können die Kommunikation nicht beeinflussen, doch ich kann Probleme umgehen. Ich arbeite nie mit Arrays mit >1000 Elementen, ich überlege mir dann immer eine Lösung per Datensatz (Rezeptur).

Daß der Zugriff von WinCCflex-Skripten auf SmartTag-Arrays SEHR problematisch ist, haben wir auch schon öfter diskutiert, z.B. daß es nicht (mehr) möglich ist, ein SmartTag-Array in einem Rutsch komplett in ein lokales Skript-Array einzulesen.

Harald
 
Hallo Harald,
... Ich arbeite nie mit Arrays mit >1000 Elementen, ich überlege mir dann immer eine Lösung per Datensatz (Rezeptur).
wobei für die Rezeptur ja die gleichen Gesetzmäßigkeiten gelten wie für ein Array ...

Daß der Zugriff von WinCCflex-Skripten auf SmartTag-Arrays SEHR problematisch ist, haben wir auch schon öfter diskutiert, z.B. daß es nicht (mehr) möglich ist, ein SmartTag-Array in einem Rutsch komplett in ein lokales Skript-Array einzulesen.
Ja ... stimmt ... das war mal eine tolle Funktion gewesen (ich meine noch unter Flex 2007).

Aber ganz generell (ich hatte das ja auch schon ein paar Mal geschrieben bzw. mitdiskutiert) hat Siemens da etwas verschlafen wo die die Möglichkeit ausgespart haben, einen Benutzer-frei-definierten Datenblock kontrolliert und konsistent zu übertragen.
Man baut sich dann immer etwas zurecht - mehr oder weniger erfolgreich ... 8)

Gruß
Larry
 
Zurück
Oben