Automatischer BugReport

tgusi74 · 1. August 2009 um 13:18

IPS ist vorhin wieder eingeschlafen,
und seit 09:35 ist der Buffer wieder durcheinander ?? (siehe Logfile)

Ich benutze KEINEN CUTTER ,es ist nur der Quellcode aus meinen Vorpost aktiv

… habe keine Ahnung mehr wo das Problem liegen soll,
aus meiner Sicht ist alles sauber programmiert


+ Buffer löschen
+ Anfrage schicken

+ Auf Daten von der LOGO! warten bis alle Daten vorhanden

+ eine "erneutes" Timerevent wird solange abgebrochen bis alle Daten empfangen (mit der schnellen IPS2.1b(30.07.2009) nie mehr der Fall) bzw. sollten die Daten nach 20 sekunden immer noch nicht da sein "Zwangslöschen" des Buffers

Habe mir jetzt auf den Laptop zusätzlich IPS2.0 installiert und horche jetzt über mein SNIFFER-Kabel den Datenstrom zusätzlich mit und loggt diesen in ein Logfile, damit ich beweisen kann das an der „physikalischen“ Schnittstelle alles in Ordnung ist


01.08.2009 12:39:00:562 | <-- |  55 |
01.08.2009 12:39:00:609 | --> |  06 |
01.08.2009 12:39:00:625 | <-- |  13 13 00 AA |
01.08.2009 12:39:00:703 | --> |  55 11 11 40 00 35 08 11 2A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AA |

01.08.2009 12:39:02:562 | <-- |  55 |
01.08.2009 12:39:02:609 | --> |  06 |
01.08.2009 12:39:02:640 | <-- |  13 13 00 AA |
01.08.2009 12:39:02:687 | --> |  55 11 11 40 00 35 08 11 2A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AA |

… dabei ist zu sehen das schon während des REQUESTSTRING (0x55 0x13 0x13 0x00 0xAA) von der Steuerung ein 0x06 (ACK) zurückkommt, bis dann die restliche Zeichen des Anfragestring zur LOGO! läufen, nach Empfang des vollstänigen Requeststrings antwortet dann die LOGO! mit dem „Processabbild“

tgusi74

tgusi74 · 1. August 2009 um 19:40

IPS erneut eingeschlafen,
jedoch mit einer AccessViolation im Logfile

Fehler beim Verarbeiten von Nachricht: 11105, Modul SOAPServer, Nachricht: Access violation at address 7C9208F3 in module 'ntdll.dll'. Write of address 00000000

… aber es wollte niemand etwas vom SOAP-Server

tgusi74

paresy · 1. August 2009 um 19:48

Dein Log sieht doch super aus. Warum wartest du das 0x06 eigentlich nicht ab? Muss man das nicht? So wie dein Log aussiehst musst du erst 0x55 senden, dann auf die 0x06 warten.

Dann würde ich den Buffer löschen und dann erst den Rest der Anfrage schicken und auf das Resultat warten.

Trotzdem ist das mit dem stehenbleiben nicht gut - Kannst du ausprobieren, ob IPS länger durchhält, wenn du die Abfragen verlangsamst/komplett deaktivierst? Dort müsste man Ursachenforschung betreiben, da ich beim besten Willen nicht weiß, warum es passiert. Das Logfile sagt mir und und meine RegVar Anwendungen laufen seit Tagen durch.

paresy

tgusi74 · 1. August 2009 um 22:00

Hallo Paresy,

So wie dein Log aussiehst musst du erst 0x55 senden, dann auf die 0x06 warten.

… das funktioniert leider nicht, wenn man nicht unmittelbar den restlichen String schickt kommt nicht ein 0x06 (ACK) sondern dann ein 0x15 (NAK) und 0x07 (BEL) zurück !!

Dann würde ich den Buffer löschen und dann erst den Rest der Anfrage schicken und auf das Resultat warten.

… das habe ich mir der Einfachheitshalber erspart und addiere da lieber 1 Zeichen beim Auslesen der Nutzinhalte dazu ==> habe eben auch nicht wirklich gute Erfahrungen gemacht, wenn man den Buffer so zwischendurch ablöscht denn dann passieren sehr schnell wieder „korrupte Bufferinhalte“, offensichtlich hat da IPS noch irgendwo dann ein POINTER-Zugriffsproblem (laufende Schreibzugriffe zeigen auf falsche Schreibposition, oder so, wenn man den Buffer löscht)

… habe jetzt zwar die Anfrage aufgeteilt und mit IPS_Sleep(200) verzögert aber ob das was bringt mal abwarten


//Schreibe BEFEHL an die LOGO! --> 0x55 0x13 0x13 0x00 0xAA
RegVar_SendText($RegVar_COM3_READ, chr(hexdec("55")));
IPS_Sleep(200); //noch alles OKAY ==> es kommt noch ein 0x06 (ACK) zurück
//IPS_Sleep(500); //es ein 0x16 (NAK) + 0x07 (BEL) zurück
RegVar_SendText($RegVar_COM3_READ, chr(hexdec("13")).chr(hexdec("13")).chr(hexdec("00")).chr(hexdec("AA")));

tgusi74

tgusi74 · 11. August 2009 um 21:59

Hallo,
nach einer Woche testen muss ich mich auch wieder mal melden

… im Grunde läuft die aktuelle Version wirklich stabil

Hier so meine Erkenntnisse aus der letzten Woche,
egal ob ich das polling der LOGO! langsamer mache z.b. nur alle 10 Sekunden oder alle 2 Sekunden friert IPS bei geöffneter Konsole innerhalb von 24 Stunden ein (Entweder eine Accessviolation, keine Meldung im Logfile oder nur die Konsole wird unbedienbar (IPS läuft in Hintergrund noch ==> kein neue Verbindung mit der Konsole ist unmöglich und Dienst lässt sich nicht sauber beenden))

Fazit: ==> Es gibt noch irgendwo im Zusammenhang mit der geöffneten Konsole ein Problem !!

… hängt nicht die Konsole per SOAP an IPS dran ??

Fehler beim Verarbeiten von Nachricht: 11105, Modul SOAPServer, Nachricht: Access violation at address 7C9208F3 in module 'ntdll.dll'. Write of address 00000000

Wenn ich die Konsole nur kurz öffne (z.B.: 10Minuten) und dann wieder schließe laüft IPS vermutlich ewig (bei meinen Test mehr als 72 Stunden)

Und was mir dann auch noch komisch vorkommt (tritt auch nur bei geöffneter Konsole auf), aus unerklärlichen Gründen wird auf einmal das letzte Zeichen nicht mehr der RegVar übergeben, daher löscht dann mein Script nach 20 Sekunden den RegVar-Buffer mit RegVar_SetBuffer($RegVar_COM3_READ,"") jedoch ist dann ab diesen Zeitpunkt der RegVar-Buffer korrupt !!!

… im aktuellen Beispiel taucht das „letzte Zeichen 0xAA“ jetzt aufeimal immer als „erstes Zeichen 0xAA“ bei einen neuen Request auf (dies wird aber definitiv nicht von der Steuerung in dieser Reihenfolge gesendet!!) und somit ist immer der RegVar-Buffer für mein Script fehlerhaft

… ich kann das Problem ganz einfach mit lösen

<?
$COM_PORT_ID = 33848 /*[Serial_Port_COM3]*/ ;

COMPort_SetOpen($COM_PORT_ID,false);
IPS_ApplyChanges($COM_PORT_ID);

IPS_Sleep(1500);

COMPort_SetOpen($COM_PORT_ID,true);
IPS_ApplyChanges($COM_PORT_ID);
?>

… meine Frage, was sorgt dafür das durch das schliessen und wieder öffnen der Schnittstelle der RegVar-Buffer wieder korrekt befüllt wird (werden hier POINTER neu initialisiert ???), welche vorher irgendwie durcheinandergekommen sind

… als Anhang eine Auszug aus dem Logfile wo nach schliessen und wiederöffnen der Schnittstelle der RegVar-Buffer wieder korrekt befüllt wird

tgusi74

P.S.: hat das jemand anderer auch ein Problem mit IPS wenn die Konsole geöffnet bleibt ???