Technisches Problem evtl. Master Brick

Abend zusammen,

ich habe das Problem, dass nach einer Zeit von ca. 2 Stunden mein Stapel nicht mehr funktioniert.

Folgende Situation:

Am Master Brick ist ein Ambient Bricklet, Motion Detector Bricklet, ein IQR Bricklet und ein Piezo Speaker angeschlossen. Stromversorgung über USB Port.

Folgende Software ist Programmiert. Ambient Light Bricklet fragt alle 10 Sekunden die Helligkeit ab. Ist der LUX Wert < 15, dann wird im IQR der Relay 1 geschlossen, wenn LUX > 15, dann wird Relay 1 geöffnet.

Das Ganze ist in C programmiert. Wenn das Programm nun ohne Unterbrechung ca. 2,5 Stunden läuft, dann wird nicht mehr auf Veränderungen der Helligkeit reagiert (Taschenlampe auf Ambient Bricklet gehalten (ca. 400LUX)).

Ein Connect mit dem Brick Viewer bringt auch nichts mehr. Weder Master Brick noch die anderen Bricklets werden angezeigt.

Hier ein paar technische Daten:

- Verwendete Programmiersprache: C

- IDE: Xcode

- OS: Mac OS X 10.9.1

Firmware Versionen:

Master Brick: 2.1.2

Ambient Light: 2.0.3

Motion Detector: 2.0.0

Piezo: 2.0.1

IQR: 2.0.0

Output /var/logs/brickd.log

2014-01-30 19:44:07.528614 <I> <usb|usb.c:144> Added USB device (bus: 250, device: 6) at index 0: Master Brick [xxxxxxx]

2014-01-30 19:44:15.154137 <I> <network|network.c:94> Added new client (socket: 19, peer: 127.0.0.1)

Erst das ziehen des USB Steckers und erneuten Verbinden löst das Problem.

Kennt jemand das Problem?

Hast du am Quad Relay eine Last angeschlossen oder schaltet das einfach so vor sich hin?

Ich nehme mal an das Problem ist jetzt schon mehrfach aufgetreten. Passiert das immer nach ca. 2 Stunden? Bzw. fällt das mit einem anderen Ereignis zusammen?

Leg sich der Mac vielleicht genau dann schlafen wenn das passiert?

Teste mal bitte ob es auch hilft brickd neuzustarten, statt USB ab und an zu stecken, wenn das Problem auftritt. Dazu in einem Terminal folgende Befehle ausführen:

sudo launchctl stop com.tinkerforge.brickd
sudo launchctl start com.tinkerforge.brickd

AM IQR liegt eine Last von 3V an, damit eine LED geschaltet werden soll.

Das Problem ist schon öfters aufgetreten. Ich habe jetzt für den Test den Mac so eingestellt, dass er sich nicht mehr schlafen legt und zusätzlich den brickd gestoppt und neu gestartet.

Ich werde Heute Abend das Ergebnis mitteilen. Leider sieht man im Logfile keine Meldung, warum die Connection weg ist. Gibt es vielleicht ein anderes Loglevel, welches man für den brickd einstellen kann (Beispiel: Loglevel DEBUG)?

Okay, eine LED wird kein Problem machen.

Es gibt unter Linux und Mac das Problem, dass brickd nach einem Suspend nicht mehr mit den Bricks kommunizieren kann. Das kann durch einen Neustart von brickd oder eine Reset der Bricks behoben werden. Das Problem ist, dass brickd das nicht mitbekommt, wenn das passiert. Daher siehst du das auch nicht im Logfile. Ich denke ich weiß wie das Problem zu beheben ist, wenn brickd das Problem erkennen könnte.

Daher meine Frage, ob dein Problem mit einem Suspend zusammenfällt. Wenn ja, dann ist es wahrscheinlich das oben genannt Problem und ich kann dir leider momentan keine wirkliche Lösung anbieten.

Standardmäßig wird das Debug Loglevel nicht ausgegeben, da dies sehr detailliert Auskunft über die stattfindende Kommunikation gibt. Was dazu führen kann, dass brickd bei der Abarbeitung der Kommunikation durch die Logausgabe selbst merklich gebremst wird.

Du kannst das Loglevel in /etc/brickd.conf einstellen und muss dann brickd neustarten, um die Änderungen zu übernehmen. Wobei dies wahrscheinlich keine weiteren Erkenntnisse bringen wird, da Fehler oder unerwartete Dinge auf Error und Warn Loglevel gemeldet werden und diese beiden standardmäßig ausgegeben werden.

Ich habe das jetzt mal geprüft. Ohne Ruhemodus läuft alles perfekt.

Sobald der Ruhemodus an geht, dann reagiert das Ganze nicht mehr.

Also scheint es an dem vom dir beschriebenen Problem zu liegen, dass nach einem Suspend der brickd nicht mehr mit den Bricks kommunizieren kann.

Werdet ihr dafür eine Lösung finden und es via Update liefern?

Bei den meisten Mac's wird die Kommunikation beim USB im Schlafmodus abgeschaltet, der 5V Strom bleibt jedoch erhalten!

So reagiert eine USB Tastatur nicht mehr, und der Mac kann über die USB-Tast. so nicht aufgeweckt werden.

Das bedeutet dass während der Schlafphase keine Steuerung über USB mehr funktioniert.

Ich denke da liegt das Problem.

Das bedeutet dass während der Schlafphase keine Steuerung über USB mehr funktioniert.

Ich denke da liegt das Problem.

Während der Schlafphase läuft das Programm ja auch nicht, da will dann ja auch keiner mit dem Brick reden. Aber nach dem der Mac wieder aufgewacht ist ist die Kommunikation weiterhin unterbrochen.

Ich hab mir das jetzt mal genauer angesehen und zumindest unter Linux und Mac ist es so, dass beim Suspend die USB Kommunikation beendet wird und beim Resume neu aufgebaut wird.

brickd verwendet aber über den Suspend hinweg den gleichen libusb Handle für den Brick. Allerdings läuft dieser nach dem Resume ins Leere, weil durch den Neuaufbau der USB Kommunikation der Brick jetzt einen neuen/anderen Handle hat.

Soweit ich das sehe kann brickd nicht erkennen, ob der Handle zum Brick ins Leere läuft oder nicht. Was brickd aber tun kann, ist auf die Ursache des Problems zu reagieren, den Suspend.

Die angehängt brickd Version lauscht jetzt auf den Resume Event von Mac OS X, der besagt, dass der Rechner gerade aus einem Suspend aufgewacht ist. In diesem Fall schließt brickd alle linusb Handles und öffnet sie neu.

LinTec, damit sollte dein Problem behoben sein. Kannst du das bestätigen?

Für Linux habe ich auch eine Lösung in Arbeit und unter Windows muss ich noch testen ob das Problem dort überhaupt auftritt.

brickd_macos_2_0_10_wakeup.dmg