Brickd (1.0.11) bleibt hängen

Arnim · January 10, 2013 at 12:59

Sodele,

ich nähere mich so langsam einem stabilen System, aber jetzt habe ich ein ganz neues Problem: Der Brickd bleibt hängen (ist aber im Status noch "Wird ausgeführt") und muss in der Dienststeuerung (Windows 7, 64 bit) zurückgesetzt werden.

Kurz zum System:

Ein Master-Brick hängt per USB am Rechner. Per RS485 (etwa 40cm, Testaufbau) geht's zu nem anderen Master-Brick. An dem hängt ein IO16 das direkt an einem UART16550 hängt. Am UART hängt eine Towitek RF-ID-Leseantenne. Die Antenne sendet zyklisch (alle 220ms) ein 5 Byte-Paket an den UART (16 Byte Buffer) und diesen Frage ich per IO16 ab.

Da ich es mit einem Interrupt auf die DataReady-Leitung nicht zuverlässig hinbekommen habe polle ich die DataReady-Leitung im 100ms Takt. Gibt es nix zu lesen passiert auch nix. Gibt es Daten, so lese ich diese aus.

Im Dauerlauf läuft das recht gut. Ab und zu bleibt der IO16 hängen und liefert keine plausiblen Daten mehr. Ein automatischer Reset beider Master-Bricks über die Software bringt aber wieder alles ins fließen. So weit so toll.

Aber nach so ca. 4000 erfolgreichen Abfragen (= ca. 15 Minuten) bleibt mein Programm mit einem Timeout an einem (willkürlichen) GetPort hängen. Und auch der Brickv bekommt keine Verbindung mehr zum Brick. Ein Reset am Brick hilft auch nicht, aber der Restart vom Brickd (ohne Restart der Bricks) bringt wieder alles zum Laufen.

Lange Rede kurzer Sinn: Sonst noch jemand das Problem oder eine Idee was hier hängen könnte?

Danke, Arnim.

photron · January 10, 2013 at 13:22

Steht im Windows Event Log eine Fehler oder Warnung von brickd?

Arnim · January 10, 2013 at 13:26

Oh, ja!

Drei mal haben wir dies:

2013-01-10 10:56:05 <ERROR> <usb_device.pyo:393> Could not write to USB Device

Traceback (most recent call last):

File "usb_device.pyo", line 389, in write_loop

File "libusb\usb1.pyo", line 520, in submit

USBError: LIBUSB_ERROR_NO_MEM [-11]

Und einmal folgt auf die Meldung oben noch

2013-01-10 10:58:59 <ERROR> <usb_device.pyo:137> Could not create USB Device

Traceback (most recent call last):

File "usb_device.pyo", line 117, in __init__

File "usb_device.pyo", line 146, in add_read_transfer

File "libusb\usb1.pyo", line 520, in submit

USBError: LIBUSB_ERROR_NO_MEM [-11]

2013-01-10 10:59:18 <ERROR> <usb_device.pyo:67> Could not create extra USB context

Traceback (most recent call last):

File "usb_device.pyo", line 65, in __init__

File "libusb\usb1.pyo", line 1530, in __init__

USBError: LIBUSB_ERROR_OTHER [-99]

Am USB sollte es aber so direkt nicht liegen, da wie gesagt eine Restart des Daemon (ohne an den Bricks oder dem USB etwas zu berühren) alles wieder ans Laufen bringt.

Ideen?

photron · January 10, 2013 at 13:45

Das sind Fehler aus libusb, die wir für die USB Interaktion verwenden. LIBUSB_ERROR_NO_MEM besagt, dass nicht genug Speicher frei war. Achte doch mal bitte auf den Speicherverbrauch von brickd während dein Programm läuft.

Es scheint mir aber dass da ein andere Fehler vorliegt den libusb aber fälschlicherweise als LIBUSB_ERROR_NO_MEM meldet. Ich muss mir dazu mal den Source Code ansehen.

Wie arbeitet dein Programm? Ich nehme an du öffnest am Anfang eine IPConnection und rufst da periodisch GetPort auf. Wenn du erkennst, dass das IO-16 Bricklet nicht mehr reagiert resettest du das ganze.

Wie häufig resettest du bis brickd hängt?

Arnim · January 11, 2013 at 08:18

Ich habe jetzt mein IO16 und den UART mit deutlich kürzeren Kabeln verbunden (5cm statt 30cm). Seither läuft das System praktisch perfekt. In einem Dauerlauf seit gestern 18:30 Uhr (läuft noch) bin ich (also der Computer) jetzt bei 260.000 erfolgreichen Karten-ID-Lesungen. Nicht ein einziges Byte wurde falsch gelesen. Lediglich mehr oder weniger direkt nach dem Start hat der IO16 einmal nicht mehr reagiert und die Software hat die Bricks resetet.

Gestern - als ich die Abstürze des Daemon hatte - lief das System (wohl auf Grund der längeren Kabel) sehr unzuverlässig und hat etwa 40 Reset in 10 Minuten gefahren. So beim ca. 40sten Reset hat sich dann der Daemon verabschiedet.

Ich lasse es mal über den Tag weiter laufen und beobachte, wie sich das System verhält. Aber bei aktuell 260.000 Lesungen ohne Fehler und geschätzen 25 Türöffnungen je Tag (im Schnitt) läuft das System jetzt schon knapp 30 Jahre stabil, das reicht mir. ;-)

Völlig OT, aber ich will nicht extra noch mal was aufmachen, zwei Dinge:

- Kann ich am Master die RS485 Slaves neu abfragen ohne Reset? Also per Software.

- An meinem Slave-Brick hängen ein IO16 und ein LCD. Alles läuft gut. Hänge ich das LCD ab, wird das Lesen am IO16 plötzlich _extrem_ langsam. Das LCD wird in der Software aber weder aktiviert noch angesprochen! Jemand ne Idee? Ich untersuche das aber mal weiter und mache dann evtl. noch nen Thread auf.

Danke für die Antworten, Arnim.

borg · January 11, 2013 at 09:19

- Kann ich am Master die RS485 Slaves neu abfragen ohne Reset? Also per Software.

Mit Protocol V2 (was im Laufe der nächsten Woche veröffentlicht wird), geht das.

- An meinem Slave-Brick hängen ein IO16 und ein LCD. Alles läuft gut. Hänge ich das LCD ab, wird das Lesen am IO16 plötzlich _extrem_ langsam. Das LCD wird in der Software aber weder aktiviert noch angesprochen! Jemand ne Idee? Ich untersuche das aber mal weiter und mache dann evtl. noch nen Thread auf.

Du ziehst das LCD Bricklet im laufenden Betrieb ab? Das ist so leider nicht erlaubt . Der Brick hat keine Möglichkeit mitzubekommen ob das Bricklet im laufenden Betrieb an/abgesteckt wurde.

photron · January 11, 2013 at 09:35

Gestern - als ich die Abstürze des Daemon hatte - lief das System (wohl auf Grund der längeren Kabel) sehr unzuverlässig und hat etwa 40 Reset in 10 Minuten gefahren. So beim ca. 40sten Reset hat sich dann der Daemon verabschiedet.

Ich hab mir jetzt mal den libusb Code im Detail angesehen und es sieht so aus, dass dadurch wie wir libusb in brickd benutzen bei jedem Abstecken eines Bricks (sei es mechanisch oder per Reset) intern ein Teil einer endlichen Ressource leakt. Und nach ca. 50 Mal Abstecken ist die Ressource vollständig belegt. brickd kann dann nicht mehr mit Bricks über USB kommunizieren und muss neugestartet werden. Das betrifft soweit ich das sehe nur Windows. Ich sehe leider im Moment keine Möglichkeit das zu fixen.

Ich habe mir das auch noch mal im neuen Brick Daemon für Protokol v2 angesehen. Dort benutzen wir libusb etwas anders so dass dort dieses Problem nicht auftritt. Genauer gesagt, mit brickd v1 betrifft das Problem alle Windows Versionen. Mit brickd v2 nur noch Windows XP, dort verhält sich die WinUSB API aus irgendwelchen Gründen anders. Windows Vista und neuer sind nicht mehr betroffen.

TL;DR: Mit Brick Daemon für Protokol v2 ist das Problem in den allermeisten Fällen behoben.

Arnim · January 11, 2013 at 10:10

@photron: Scheint so, als würde ich mich auf Version V2 freuen! ;-)

@borg: Nein, natürlich nicht im laufenden Betrieb. Da habe ich mich schlecht ausgedrückt. Wenn ich die Bricks ohne das LCD angesteckt starte und meine Software läuft ist alles in Zeitlupe. Habe ich beim Start das LCD eingsteckt (wie gesagt, in der Software ist es NICHT gebunden oder verwendet) dann läuft alles super flott und so wie ich es erwarten würde. Wacky. :-/

borg · January 11, 2013 at 10:23

@borg: Nein, natürlich nicht im laufenden Betrieb. Da habe ich mich schlecht ausgedrückt. Wenn ich die Bricks ohne das LCD angesteckt starte und meine Software läuft ist alles in Zeitlupe. Habe ich beim Start das LCD eingsteckt (wie gesagt, in der Software ist es NICHT gebunden oder verwendet) dann läuft alles super flott und so wie ich es erwarten würde. Wacky. :-/

WTF? Das macht keinerlei Sinn . Wie sieht denn die Software aus, fängst du vielleicht irgendwo Timeouts ab ohne es mitzubekommen?

Arnim · January 11, 2013 at 12:02

WTF? Das macht keinerlei Sinn .

Das dachte ich mir auch. ;-) Ich muss das noch genauer Untersuchen.

Arnim · January 11, 2013 at 15:03

Sodele, 16:06 - nach erfolgreich gut 360.000 gelesen Karten und dem (IO16) bedingt 37 Neustart ist der Brickd tot.

Wäre es möglich, den den Remote-Brick zu reseten UND dann am Master die RS485-Slaves neu zu scannen wäre es wohl absolut kein Problem. Alternativ dürfte eben der Brickd nicht nach ca. 40 Zyklen schlapp machen.

Beides sollte sich ja - auf einen Streich - mit V2 von alleine lösen.

Lasst euch nur bitte keine 40 Jahre Zeit, sonst muss ich womöglich doch von Hand neu Starten.

Wegen dem LCD-Problem mache ich mir jetzt mal Gedanken.

photron · January 11, 2013 at 15:15

Du kannst v2 schon testen, siehe Protokoll v2 Beta Thread:

http://www.tinkerunity.org/forum/index.php/topic,1238.0.html

Anmelden

Brickd (1.0.11) bleibt hängen

Recommended Posts

Arnim

photron

Arnim

photron

Arnim

borg

photron

Arnim

borg

Arnim

Arnim

photron

Join the conversation

Umsehen

Aktivitäten