Timeout bei PHP-Scripts und Anweisung Schreibedatei

[contronics-RK]

Wenn ein Makro länger als 2,5 Sekunden aktiv ist, wird es durch einen Timeout beendet. Normalerweise hat das keine Auswirkungen, da die Ausführungszeit normaler Makros im Millisekunden-Bereich liegt.
Bei der Anweisung Schreibedatei und bei Ausführung umfangreicher PHP-Scripts ist es vorgekommen, das der Timeout überschritten wurde. Insbesondere bei langsamen PCs oder Verwendung von Datenbankroutinen bei PHP kann das passieren. Daher wurde jetzt der Timeout bei Benutzung dieser Anweisungen deaktiviert.
Aber Vorsicht: Grundsätzlich sollte man versuchen Makros, die länger als 2 Sekunden laufen (und das ist schon sehr lang) zu vermeiden. Makros, die aufgrund des deaktivierten Timeout länger als 4 Sekunden laufen, können Fehlfunktionen verursachen, da evtl. ein zeitgesteuertes Makro innerhalb eines 5-Sekunden-Takts nicht ausgeführt wird und somit Aktionen verlorengehen. Es liegt in der Verantwortung des Anwenders dies zu vermeiden.

Die aktuelle Version steht noch nicht im Intenet, kann aber kann unter folgenden Link geladen werden:

http://www.contronics.de/download/homep ... a80202.zip

[buempi]

Sehr geehrter Herr Krapoth

Ich habe bei mir schon festgestellt, dass Makros nicht ausgeführt wurden. Wenn ich mich richtig erinnere, waren es ausnahmslos sehr kleine Makros, in welchen allerdings ein SCHREIBEDATEI() vorkommt bzw. andere Makros, die aus einem Makro mit SCHREIBEDATEI() heraus hätten gestartet werden sollen; und zwar in folgender Reihenfolge:

starte(AnderesMakro)
schreibedatei("XX","YY")

Ich hatte immer eher denn Verdacht, dass durch das Zusammentreffen mehrer Ereignisse die Ausführungswarteschlange "überfüllt" war. Homeputer läuft bei mir auf einem USB-Stick und da kann doch das Schreiben nicht so lange dauern? Bei einer Festplatte, die vielleicht zuerst "angeworfen" werden muss, sähe ich das anders.

Gestatten Sie mir in diesem Zusammenhang bitte drei Fragen:

1. Was passiert mit geänderten Variablen und vorgenommenen Schaltungen oder STARTE(), wenn ein Makro wegen Timeout abgebrochen wird? Werden die Variablen, Schaltungen und Aufrufe verworfen, oder werden sie bis zum Abbruch-Punkt trotzdem wirksam? Ersteres wäre m.E. "sicherer", denn es ist weniger schlimm, wenn der alte Zustand erhalten bleibt, als wenn was "Halbfertiges" ausgeführt wird.

2. Ich denke, dass ich die Probleme minimieren kann, indem ich das SCHREIBEDATEI() an den Schluss eines Makros setze und vorher ein warte("00:00:00") einfüge. Dann kommt alles richtig heraus (Variablen, Schaltungen und Aufrufe anderer Makros), nur mein Protokoll ist unvollständig...? Bzw. blockiert mit der neuen Version allenfalls andere zeitgesteuerte (ev. auch bei Empfang auszuführende?) Makros!

3. Es ist natürlich richtig, dass der Anwender dafür verantwortlich ist, keine Makros zu schreiben, die den Computer blockieren. Sie könnten uns darin aber unterstützen, wenn ein entsprechender Eintrag mit Zeitstempel und Name des wegen Timeout abgebrochenen Makros im MsgFile.txt erfolgen würde. Ev. sogar, bei welcher Programmzeile. - Wäre das möglich?

Viele Grüsse
Bümpi

[contronics-RK]

Hallo,

für dieses Verhalten habe ich leider keine plausible Erklärung. Eigentlich müsste das Schreiben in einen USB-Stick schnell gehen, je nach USB-Stick (aber sicher nicht schneller als auf eine laufende Platte).
Die Starte-Anweisung ist sehr schnell (es werden nur ein paar Bytes auf einen Stack gelegt). Dass dieser überläuft ist ziemlich unwahrscheinlich, er hat Platz für 500 Einträge (wenn es mehr sind stimmt sowieso was nicht). Das kann auch nicht passiert sein, weil bei Überlauf des Stacks eine Meldung in die Meldungsliste geschrieben wird, diese würden Sie dann sehen.

zu 1
Das Makro wird abgebrochen, aber alle bis dahin veränderten Werte bleiben erhalten bzw. mit Start aktivierte Makros werden ausgeführt.

zu 2
Das mit der Warte("00:00:00")-Anweisung ist grundsätzlich eine gute Sache, dadurch wird auch die Timeout-Zeit zurückgesetzt und andere Makros kommen evtl. zwischendurch zur Ausführung. Was sein kann ist, dass evtl. die in Schreibedatei benutzten Werte durch andere Makros verändert werden, bevor die Anweisung tatsächlich ausgeführt wird.

zu 3
Ich habe es mal auf die Update-Liste gesetzt, bei Abbruch eine Meldung in die Meldungsliste zu schreiben.

[buempi]

Sehr geehrter Herr Krapoth

Vielen Dank für die rasche Antwort.

Das Makro wird abgebrochen, aber alle bis dahin veränderten Werte bleiben erhalten bzw. mit Start aktivierte Makros werden ausgeführt.

Wen dem so ist (und ich zweifle nicht daran, wenn Sie das sagen), kann ich mit Sicherheit ausschliessen, dass nicht ein Timeout in einem "SCHREIBEDATEI()-Makro" daran Schuld ist, dass bei mir manchmal Makros nicht ausgeführt werden.

Ich habe verschiedene Makros, die bei Empfang (eines HMS-Sensors oder vom K8055) ablaufen und:

- einen Wert verändern bzw. eine Schaltung vornehmen sollen
- ein anderes Makro starten
- mit SCHREIBEDATEI() einen Eintrag im Protokoll-File machen

Manchmal (auch schon 2x am Tag, dann wieder 10 Tage nicht), passiert es, dass ein Signal vom HMS empfangen wird (IOLog.txt/History-Eintrag), aber nachweislich keiner der drei Schritte ausgeführt wird.

Ich habe die Anwendung auch schon im Debug-Modus laufen lassen, weil ich dachte, dass Timeouts die Ursache sein könnten. Timeouts sind ja dann ganz ausgeschaltet. Der Fehler trat trotzdem auf (gefühlsmässig sogar eher häufiger).

Die vom Taskmanager angezeigte Prozessorauslastung beträgt bei mir maximal 5%, meistens aber 0% bis 2%. Daran kann es nicht liegen. Auch auf 500 Einträge in der Ausführungs-Warteschlange werde ich es nie bringen!

Der Fehler ist nicht reproduzierbar, tritt selten auf und hat keine gravierende Auswirkungen auf die Konsistenz des Ganzen. Es ist einfach dasselbe, wie wenn ein Signal gar nicht empfangen worden wäre. - Und das kommt leider viel häufiger vor.....

Viele Grüsse
Bümpi

[Tobbi35]

Hallo zusammen,
ich hab die neue Version,
mal auf mein Lap gespielt, also bei mir läßt sich
das Programm nicht mehr beenden und ich hab eine 100% Auslastung ?
Wie sieht das bei euch aus ?


Gruß Jürgen

[kafibo]

Hallo,

kann ich so bestätigen.
95 - 100% Auslastung und lässt sich nicht beenden.

[buempi]

Eigenartig: Bei mir läuft's - allerdings ohne angeschlossene Schnittstelle - ganz normal. Die Prozessorlast ist wie sonst und auch beenden kann ich das Programm ordnungsgemäss. Ich habe jede Menge SCHREIBEDATEI() aber keinen PHP-Code in meiner Anwendung.

Wie ist das bei euch: Habt ihr mit oder ohne Schnittstelle getestet? Und habt ihr PHP drin?

Viele Grüsse
Bümpi

[kafibo]

Hallo,

bei mir lässt sich das Programm weder mit noch ohne angeschlossener Schnittstelle beenden. Ich habe das ganze auf meinem Server wie auf einem Notebook getestet. Beides die gleichen Ergebnisse. PHP habe ich nur einmal für die Berechnung von Windchill drin und Schreibedatei kommt öfter in meinen Makros vor.

[contronics-RK]

Mit hoher Wahrscheinlichkeit, habe ich die Ursache des Problems gefunden - zumindest würde das würde alle geschilderten Auswirkungen erklären.
Wenn innerhalb eines PHP-Scripts im Makro eines Sensors der Wert des Sensors verändert wurde (also eine Zuweisung an den Sensor gemacht wurde), so wurde das wie eine "externe" Eingabe, also wir ein Empfang behandelt. Also wurde das Makro des Senders aktiviert, da im Makro dann wieder der Sensorwert verändert wurde, wurde es erneut aktiviert - die klassische Endlosschleife.
Deshalb tauchte das Problem auch nur dort auf, wo der Sensorwert innerhalb seines Makros geändert wurde.

Wir haben das jetzt geändert, Änderungen des eines Objektwertes innerhalb eines PHP-Scripts können keine Ausführung mehr verursachen, allerdings auch nicht mehr bei aktivierter Option "Ausführung bei Änderung". In diesem Fall muss dann ggfs. innerhalb des Makros stattdessen eine STARTE-Anweisung eingebaut werden. Wahrscheinlich ist diese Lösung die problemloseste, da ja anscheinend die Zuweisung von Werten an einen Sensor öfters gemacht wurde.

Die aktuelle Version steht unter:

http://www.contronics.de/download/homep ... a80203.zip

zum Download.

Änderungen von Sensorwerten, die über die DLL kommen sind davon nicht betroffen, ist hier "Ausführung bei Empfang aktiviert", so erfolgt die Ausführung - weil in vielen Fällen über die DLL Hardwareinputs kommen.

Ich hoffe das Problem ist damit erledigt - wenn nicht bitte hier posten und die Beta-Version dann nicht verwenden.
Bis zum 26.2. können wir leider wegen Urlaubs keine neuen Versionen fertig machen.

[kafibo]

Hallo,

ich will ja nicht Unken und ich habe es bis jetzt auch nur auf meinem Notebook probiert (ohne Schnittstelle).
Bei mir ist das Problem geblieben: 95-100% Auslastung und es lässt sich nicht beenden.
Wie ist es bei Euch?