LibNoDave: Was tun, wenn Funktion nicht zurückkommt?

[Manni01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe folgendes Problem: Ich muss mit einem Server-Programm Daten aus einer SPS lesen und in einer Datenbank abspeichern. Funktioniert mit LibNoDave soweit auch sehr gut.

Nur wenn z.B. das Netzwerkkabel gezogen und wieder angestöpselt wird, hängt sich LibNoDave weg, d.h. Funktionsaufrufe kommen nicht mehr zurück. Habe bei Test's schon bis zu einer 1/2 Stunde gewartet, nichts passiert.

Da die Software unbeaufsichtigt, tagelang und auch nach solchen groben Fehlern weiterlaufen muss, stellt sich mir die Frage: wie kann ich das lösen?

Hat jemand eine Idee?

 

[MW]

Nur wenn z.B. das Netzwerkkabel gezogen und wieder angestöpselt wird, hängt sich LibNoDave weg, d.h. Funktionsaufrufe kommen nicht mehr zurück. Habe bei Test's schon bis zu einer 1/2 Stunde gewartet, nichts passiert.

Hat jemand eine Idee?

Das Problem scheint bekannt zu sein, nur an einer einfachen Lösung scheint es noch zu happern :-(

vielleicht hilft dir folgender Link

 

[Manni01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, besten Dank. Der Link hat schon mal geholfen. Die neue DLL von Zottel funktioniert bei mir wunderbar.

 

[Key]

Hallo Manni,

ich habe das Problem ja ursprünglich mal aufgeworfen und ich konnte das ganze nur über eine eigene Timerüberwachung lösen. Mir ist auch bekannt das es bei anderen Bibliotheken so gemacht wird. Du hast gesagt das die DLL von Zottel dein Problem gelöst hat. Bei mir war das nciht der Fall. Denn...

Hast du mal die netzwerkverbindung bei einem langen lesen bzw. schreibversuch hinter einem Switch gezogen. Genau dann dürfte das glecihe Problem wieder auftreten. Da die Route bis zum Switch zwar funktioniert jedoch nur das direkte entfernen des Netzwerkkables am Rechner erkannt wird. Ich habe es halt dann über einen Überwachungstimer gelöst.

Quasi

Timer.Start()
read bzw. write Data
Timer.Stop()

und das Timer elapsed Event wird gefeuert wenn die Zeit überschirtten wird z.B.: 10 sec oder länger

Gruß Key

 

[Manni01]

Ja, ich hatte alle möglichen Kombinationen ausprobiert. Kabel ziehen vor und hinter dem Switch sowie SPS einfach abschalten. Ich habe das mehrere Male hintereinander probiert. Die Funktionen sind jedesmal nach ca. 5 Sec. mit Timeout zurückgekommen. Ich benutze die Funktionen
readManyBytes, writeManyBytes. Vorher hing er fast immer in einer dieser Funktionen fest.

Aber wie machst Du das dann mit Deinem Überwachungstimer? Du kriegst zwar mit, dass die Funktion hängt, aber wie kommt die Anwendung wieder in den Tritt? Neustart? Thread abschiessen?

 

[Key]

Zuviel Werbung?
-> Hier kostenlos registrieren

Achso noch was. Wenn du dann einen Disconnect machst ist weider alles sauber. Beim anschließenden Reconnect erhälst du dann nämlich die korrekte Fehlermeldung das die Verbindung nicht aufgebaut werden konnte.

Also Timerüberwachung wie lange ein Read/Write dauern darf. Wenn überschritten Event feuern -> Timeout. Dann Disconnect und Reconnect...

Gruß Key

P.S.: Bei mir ging die neue Version auch nicht. Hatte da das Problem das er das Trotzdem nicht mitbekommen hat wenn es nach dem Switch war...

 

[Key]

Ich weiß nicht ob du das wirklich probiert hast. Aber mache mal ein Read auf einen DB der so 15-20 KByte liest und dann zeihe mal das netz hinter dem Switch. Also genau während des lesens. Dann sollte es zum gleichen Fehler kommen das nämlich garnix mehr geht.

War bei mir zumindest so. Denn bei kurzen Read Writes bist du garnicht so schnell und es kommt der normale Res Fehler -125 von Libnodave...

Gruß Key

 

[Manni01]

Habe es eben nochmal mit vielen Daten ausprobiert. Bei mir funktioniert's einwandfrei. Mal bricht er beim Lesen, mal beim Schreiben der Daten ab. Ich bekomme jedesmal den DaveError -1025 (Timeout). Ich habe es jetzt mind. 20 x hintereinander probiert. Stecker raus, 5 Sek. warten, Stecker wieder rein und nach spätestens 2 Sek. hatte ich mit einem Reconnect wieder eine laufende Verbindung. Konfiguration: S7-312C mit CP343-1 Lean und einem VB.NET-Programm.

Vielleicht liegt bei Dir ein anderes Problem vor. Ich hatte neulich mit 'nem Wago-Ethernet-Controller ein merkwürdiges Problem. Ich hatte mir eine kleine Routine geschrieben, mit der ich per ModbusTCP zyklisch Daten lese und schreibe alle (10 ms ca. 200 Byte). Das Ganze brach nach unterschiedlicher Zeit 1 - 10 Min. einfach mit einem Verbindungsfehler ab. Selbst nach Rücksprache mit den entsprechenden Wago-Fachleuten war kein Fehler in Programm oder Firmware zu finden. Ich habe dann einfach mal einen anderen Port an unserem Switch probiert und, siehe da, es funktionierte einwandfrei. Ich hatte dann jedoch nicht mehr die Zeit den Fehler am Switch näher zu untersuchen....

Eine weitere Möglichkeit wäre das Zusammenspiel von .NET mit der DLL. Ich habe Unterschiede festgestellt, wenn ich auf die Originale Wrapper-DLL (libnodave.net.dll) nur verweise oder aber wenn ich den Quellcode direkt in mein .NET-Projekt mit einbinde. Das Verhalten beim Reconnect im Zusammenhang mit I/O-Bytes ist ein anderes.

 

[Key]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann werde ich mir das bei Gelegenheit nochmal anschauen.

Gruß Key