Hallo,
offensichtlich existiert bei euch folgendes Postfach nicht „bugreports@ipsymcon.de“ ==> euer Server meldet „550 sorry, no mailbox here by that name“
… daher hier als Post,
wie ich in der Console das Debugfenster der RegisterVariable öffnen wollte ist es zur folgenden Meldung gekommen „ERROR OCCURED ==> SessionID #??? existiert nicht“ (siehe Screenshot) und *.ELF
… was ich eigentlich schauen wollte ob das Zeitproblem noch in der RegVar besteht ==> diese Zeitproblem kann ich auch gleich hiermit als noch vorhanden melden
Das was auf dem Bild zu sehen ist, ist muss ein Programmierfehler deinerseits sein. IP-Symcon schreibt den Buffer in den Log, wenn du RegVar_SetBuffer aufrufst. Da der Inhalt in deiner Verantwortung liegt, muss in deinem Skript ein Fehler sein.
hier das Empfangsfile, welches durch die RegVar aufgerufen wird
<?
$RegVar_COM3_READ = 35886 /*[LOGO\RegisterVariable_COM3_READ]*/ ;
//BUFFER FUELLEN --> Daten lesen von COM-Port
$buf = RegVar_GetBuffer($RegVar_COM3_READ);
//Semaphore setzen wenn der Buffer leer ist und neue Daten empfangen werden
if (strlen($buf) == 0)
{
SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,1);
}
$buf .= $IPS_VALUE;
RegVar_SetBuffer($RegVar_COM3_READ,$buf);
//*******************************************
if (strlen($buf)>= 71)
{
if (ord($buf[8]) == 17)
{
echo("DATENEMPFANG OKAY Byte8=" . ord($buf[8]) . " ==> " . strlen($buf) . " Zeichen
");
SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,0);
}
else
{
echo ("ERROR: Lesebuffer verschoben !! --> Typ=Byte[8]=" . ord($buf[8]) . ")
" );
SetValueInteger(17047 /*[LOGO\LOGO_READ\LOGO_SEMAPHORE]*/ ,0);
}
}
?>
… dieses Zeitverhalten ist erst seit der „StrUtilities.dll“ vom 28.05.2009 zum ersten mal aufgetreten, mit einer älteren DLL ist dieses Verhalten nicht festzustellbar und alles geht „ratz fatz“, nur eben das Speicherproblem
Hallo Horst,
dafür sorgt der Anforderungsscript, bevor der neue Request geschickt wird ein löschen des Buffers durchgeführt
verkürzter Script (es sind normalerweise eben noch Prüfungen für den Semaphore enthalten, welche die Anforderung nicht durchlassen wenn noch nicht fertig)
<?
$ComPortID = 33848 /*[Serial_Port_COM3]*/ ;
$RegVar_COM3_READ = 35886 /*[LOGO\RegisterVariable_COM3_READ]*/ ;
$RegVar_COM3_WRITE = 39138 /*[LOGO\RegisterVariable_COM3_WRITE]*/ ;
//LeseBuffer leeren bevor neuen Request
RegVar_SetBuffer($RegVar_COM3_READ,"");
IPS_Sleep(50);
echo("SENDE NEUE ANFORDERUNG ========> " . date("H:i:s"));
//Schreibe BEFEHL an die LOGO! --> 0x55 0x13 0x23 0x00 0xAA
RegVar_SendText($RegVar_COM3_WRITE, chr(hexdec("55")).chr(hexdec("13")).chr(hexdec("13")).chr(hexdec("00")).chr(hexdec("AA")));
?>
… als Anhang nochmals den Ablauf des Empfangs bzw. Verarbeitung im Debugfenster (siehe zeitlichen Zusammenhang)
tgusi74
P.S.: sollten wir nicht den Thread wechseln ?? (bzw. ihr verschiebt die Post’s)
das Zeitverhalten kann ich bestätigen. Schnelles auslesen meines BHKW ist mit der „StrUtilities.dll“ vom 28.05.2009 nicht mehr möglich. Teilweise dauert das 5-6 Sekunden. Sonst hatte ich im 3 Sekundenintervall ausgelesen um bestimmte Meldungen mit zu bekommen.
Das Speicherproblem ist jetzt dafür weg, der bleibt konstant stehen (hoffe das bleibt so).
Dafür kam gestern ein paar mal diese Meldung im Log:
27.07.2009 14:30:20.609 | 59281 | WARNING | Serial Port | Access violation at address 0053E9BD in module ‚ips.exe‘. Write of address 00000004
Heute kam die nicht und passiert ist durch die Meldung auch nichts.
Gruß
Thomas
P.S wie ich im anderen Post schon geschrieben habe, finde ich die jetzige Lösung nicht sehr gelungen. Ausserdem ist es auch nicht sehr erbauend, wenn sich solche Sachen grundlegend ändern und man in einem großen Projekt dann dadurch Arbeit hat ohne Ende. Durch das Speicherproblem wurde man aber gezwungen zu handeln.
Da haben paresy und ich Dich wohl falsch verstanden. Aufgrund des tollen Linktitels Speicherüberlauf mit dieser Konstellation und dem Hinweis auf das Speicherproblem dachten wir, dass Du auch noch auf ein zusätzliches Speicherleck aufmerksam machen wolltest :rolleyes:.
Das mit der Verlangsamung ist eigentlich meine Schuld, da ich mich darüber beschwert hatte, dass durch das Threading die ankommenden Daten von mehreren Skriptaufrufen parallel verarbeitet worden sind und ich dadurch dann gerne mal die Daten im Buffer verdreht hatte. Da half dann auch keine Semaphore mehr. Das wurde zusammen mit dem Speicherleck behoben. Allerdings ist diese Version verlangsamt.
Nach dem Release der 2.1 kannst Du paresy aber nochmal drauf hinweisen. Dann wird er mal sehen, dass er der RegisterVariable einen eigenen Thread reserviert.
Sorry,
wenn ich da mit dem Link für Verwirrung gesorgt habe, wollte eben nur darauf hinweisen das wir das ZEITLICHE verhalten vom 28.05.2009 nun in der IPS2.1b haben, finde ich überhaupt nicht gut das jetzt die Verarbeitung mindestens 5mal solang dauert als früher
Leider muss ich jetzt auch gleich daraufhinweisen, das mir vorhin IPS wieder eingeschlafen ist !! (wie im LINK hier :mad:)
Im Logfile waren die letzten Einträge
Access violation at address 7C920F20 in module 'ntdll.dll'. Read of address 000003CE
P.S.: könnt ihr die Beiträge entsprechend verschieben, oder den Thread umbenennen
Hallo,
hier nochmals ein LOG-Auszug, ab diesen Zeitpunkt war wieder der Bufferinhalt verdreht !!
… es war aber zu diesen Zeitpunkt kein Aktivitäten mehr ersichtlich, jedoch wenn dann das „Zwangslöschen des Semaphore“, im Test nach 20 Sekunden durchgeführt wird (Anforderungsscript), dann stimmt ab diesen Zeitpunkt der Bufferinhalt nicht mehr
Problemlösung ist dann immer das schließen und wiederverbinden der COM-Schnittstelle !! (… dann stimmt auch der Bufferinhalt wieder)
… irgendwo hängen da noch Daten im Empfangsbereich, welche trotz sauberen Ablöschen des Buffers vor „neuer Anforderung“ da, dann immer noch reinspucken !!
Als Anhang die Scripts des Test’s (alle anderen Timer, … sind während Test deaktiviert)
Hallo,
habe heute tagsüber den Test laufen gehabt,
nach ca. 6 Stunden ist IPS wieder eingeschlafen, da hat offensichtlich der von PARESY vermutete DEADLOCK vom 30.05.2009 wieder zugeschlagen, jedoch war dieses mal nicht auffälliges im Logfile
@RWN,
da liegt der Fehler im Kommentar, der Anforderungstring stimmt ==> 0x55 0x13 0x13 0x00 0xAA
Hallo Paresy,
habe den Test mit der neuen 2.1b 29.07.2009 erneut durchgeführt, wird DEADLOCK und Access Violation
Access violation at address 7C920F20 in module 'ntdll.dll'. Read of address 00000004
… schau dir bitte einmal das Logfile an, hier gehen bevor die Access Violation kommt der Anforderungsversuch 3 ab ??? (Timerevent wo eben der Semaphore noch sitzt)
Kannst du mal die Version ausprobieren, die ich eben hochgeladen habe? Sie müsste eigentlich wieder sehr schnell sein und hoffentlich auch den Fehler gleich mit erledigen.
30.07.2009 22:27 Teststart
31.07.2009 01:27:02 erste mal dass der Bufferinhalt fehlerhaft ist
... jede weitere Anfrage fehlerhaft
31.07.2009 01:51:24 Bufferinhalt wieder in Ordnung
... jede weiter Anfrage wieder sauber !!
31.07.2009 06:51 das offene Konsolenfenster ist eingefroren,
aber IPS arbeitet in Hintergrund noch fehlerfrei
31.07.2009 13:13:00 erneut ist der Pufferinhalt verschoben
... je weitere Anfrage fehlerhaft
31.07.2009 15:30 Versuch die Konsole zu beenden (keine Rückmeldung)
... mit Taskmanager abgeschossen (Konsole + SysTray)
... SysTray wieder gestartet und Konsole öffnen ==> Fenster öffnet nicht
... wieder mit Taskmanager abgeschossen (Konsole + SysTray)
... SysTray gestartet ==> versuch den Dienst zu beenden, ohne Erfolg (jedoch stehen einige Zeilen im Logfile)
... Taskmanager IPS abgeschossen
… leider ist die IPS-Konsole eingefroren und der Bufferinhalt ist Zeitweise verschoben gewessen
… als Anhang das gekürzte Logfile (22MB anstatt 650MB)
tgusi74
P.S.: habe jetzt den Test wieder gestartet und die ZEITSYSNCHRONISATION in Windows abgeschaltet !!!
Also der Buffer kann seitens IPS nicht verschoben sein, da es eine einfache Liste ist, die nacheinander abgearbeitet wird. Da muss bei dir noch irgendwo ein Synchronisationsproblem drin sein.
Außerdem wirkt das Skript insgesamt recht kompliziert. Die Write RegVar kannst du löschen und einfach die Read RegVar dafür verwenden. Oder sind das wirklich 2 Com Ports? Wenn nicht, fallen dann schonmal 50% der Skriptaufrufe weg.
Hallo Paresy,
habe nun die RegVAR „RegisterVariable_COM3_WRITE“ entfernt (ausgehängt), war immer der Meinung das ich für das schreiben eine eigene RegVar benötige zwar mit Dummyscript :rolleyes: und habe mich immer gewundert warum diese auch beim Empfang mitgetriggert wird
… habe nun auch das Logging nochmals umgebaut um genauer sagen zu können was da im Buffer steht (Test läuft, Script im Anhang)
==> wenn das Zeichen 8 im Buffer nicht 0x11 (Dec 17) ist, dann stimmt der Bufferinhalt nicht !! (Gerätekennung, welcher Typ von LOGO! angeschlossen ist)
… zu Test von gestern,
hat es so ausgeschaut als ob das letzte Zeichen 0xAA (Dec 170), noch irgendwo im „IPS“ gehängt (Steuerung ist auzuschliessen) währe und nach einer neuen Anforderung als erstes eingelesen wurde und somit der Buffer zwar nicht verdreht aber verschoben war, normalerweise muss als erstes Zeichen ein 0x06 (Dec 6) empfangen werden ==> ACK das die Anforderung verstanden wurde
… zu Test heute NACHT,
IPS ist wieder um 00:28 eingeschlafen !! (Logfile im Anhang)
Das mit dem „RTS/DTR“ muss leider so gemacht werden, ansonsten keine Daten von der LOGO!
P.S.: … die RegVAR kann nicht gelöscht werden, das stürzt IPS2.1[30.07.2009] ab !! (kann jederzeit auch mit neuanlegen und löschen nachgestellt werden)
hat es so ausgeschaut als ob das letzte Zeichen 0xAA (Dec 170), noch irgendwo im „IPS“ gehängt
Hast Du noch einen Cutter dazwischen?
Das Problem hab ich bei meinem Bussystem auch. Nur schickt der mir noch einen kompletten Datensatz obwohl schon neue Daten vorhanden sind. Allerdings habe ich da noch nicht weiter nachgesehen, da nur Temperaturdaten.
Der ganze Hickhack ist erst seit Umstellung der RegVar.
P.S.: … die RegVAR kann nicht gelöscht werden, das stürzt IPS2.1[30.07.2009] ab !! (kann jederzeit auch mit neuanlegen und löschen nachgestellt werden)