photron

Ist jetzt auch dokumentiert. Jeder Brick und Bricklet hat jetzt in der API Dokumentation einen Abschnitt über Konstanten.

Log Also, das Log nach dem brickd Neustart zeigt, dass brickd den Master Brick korrekt findet und initialisiert. 4sec später nimmt er die eingehende TCP Verbindung an. Dein Programm ruft einen Getter eines Bricklets auf. Brickd sendet die Anfrage korrekt an den Master Brick weiter. Der Write Transfer kommt ohne Fehler zurück, was für brickd bedeutet, dass die Anfrage korrekt an den Master Brick ausgeliefert wurde. 2,5sec später ruft dein Programm einen Setter auf einem anderen Bricklet auf. Auch diese Anfrage geht korrekt an den Master Brick raus. Es ist noch keine Antwort auf den ersten Getter Aufruf angekommen und da mittlerweile 2,5sec vergangen sind wird jetzt in deinem Programm eine TimeoutException geworfen. Ich nehme an du behandelst diese nicht und dein Programm wird abgebrochen. Daher wird jetzt die TCP Verbindung zum brickd getrennt. Damit endet das Log. Bezüglich "Broadcasting request because no Brick knows the UID", das ist okay. Brickd arbeitet wie ein Switch und lernt hinter welchem USB Gerät sich welche UIDs verbergen. Der Eintrag besagt einfach, das brickd noch nicht weiss hinter welchem USB Gerät sich die UID für diese Anfrage befindet und daher wird die Anfrage an alle geschickt. Verständlicher wäre wahrscheinlich "Broadcasting request because UID is currently unknown" als Logeintrag. Von brickd Seite ist das alles vollkommen okay, es ist kein Neustart von brickd notwendig. Was da passiert ist, dass auf den Getter Aufruf keine Antwort innerhalb des Timeouts kommt. Dies scheint kein vereinzelte Timeout zu sein, denn sonst müsste dein Programm weiter funktionieren, wenn du des nach dem Abbruch neustartest. Es scheint als hätte der Master Brick aufgehört zu antworten. Das ist nicht normal. USB Da dmesg nichts besonderes zeigt ist es zumindest kein USB Problem, dass der Kernel erkennen könnte. Auch im brickd Log funktioniert USB normal. Der aktive USB Hub ist einen Versuch wert. Das Dual Relay Bricklet braucht zum Schalten kurzzeitig mehr Strom (60mA). Möglicherweise geben das die USB Buchsen der Netbooks nicht her. Last Was ist das für ein Gerät das du da schaltest bei 12V/6A? Ein Motor, eine Lampe, etc? Ich frage, weil es im Zusammenhang mit dem Dual Relay in seltenen Fällen EMV Probleme gab. Das also der Master Brick durch das Schalten gestört wird. Es kann auch sein, dass unabhängig davon etwas in der Umgebung des Bricks ist was diesen gestört hat. Deswegen auch die Frage nach der Länge der Bricklet Kabel. Lange Kabel wirken als Antennen und fangen Störungen ein. Als weitere Möglichkeit, die du neben dem aktiven USB Hub noch testen kannst ist den Master Brick zu schirmen, z.B. in einer Metalbox, oder auch einfach mit der ESD Tüte in der er verpackt war.

Deine per AddHandler registrierte Funktion wird von einem Thread der IP Connection aufgerufen. Aus diesem Thread kannst/darfst du nicht mit dem UI interagieren. Die Lösung mittels Delegate und Invoke() wird z.B. hier beschrieben: http://tech.xster.net/tips/invoke-ui-changes-across-threads-on-vb-net/

I added "... permanently on the WIFI Extension" to the quoted sentence.

Die Dokumentation dieser beiden Callbacks waren nicht eindeutig. Das habe ich jetzt verbessert.

Log Für ein Log auf Debug Level ist das noch kurz. In dem Log sehe ich zwei Aufrufe der gleichen Setter Funktion (könnte set_state des Dual Relay sein). Dann wird die Socket Verbindung der IP Connection geschlossen. Nichts auffälliges, alles normal. Das zweite Log ist auch normal, nichts auffälliges. Brick Daemon startet seine Subsysteme, findet den Master Brick, initialisiert ihn und wartet dann darauf, dass etwas passiert. Das zweite Log zeigt, dass der Master Brick zumindest USB mässig noch funktioniert, zumindest soweit das er für Linux heile aussieht. Interessant wäre jetzt wie ein Setter Aufruf im Log aussähe, nachdem der Brick nicht mehr reagiert. Ein normaler Aufruf sähe so aus: 2013-03-01 12:46:50.362571 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 11, R: 0) from client (socket: 16, peer: 127.0.0.1) 2013-03-01 12:46:50.362644 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 11, R: 0) to 1 Brick(s) 2013-03-01 12:46:50.362743 <D> <transfer.c:232> Submitted write transfer 0x20aa788 for 10 bytes to Master Brick [6krz2t] 2013-03-01 12:46:50.362804 <D> <brick.c:503> Sent request to Master Brick [6krz2t] 2013-03-01 12:46:50.362861 <D> <event_posix.c:238> Handled all ready event sources 2013-03-01 12:46:50.362923 <D> <event_posix.c:177> Starting to poll on 10 event source(s) 2013-03-01 12:46:50.367796 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready 2013-03-01 12:46:50.367906 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7 2013-03-01 12:46:50.368013 <D> <transfer.c:72> Write transfer 0x20aa710 returned successfully from Master Brick [6krz2t] [*]Der Setter Aufruf geht bei brickd ein (Got request from client). [*]Wird an den Master Brick geschickt (Submitted write transfer to Master Brick) [*]Der Write Transfer kommt erfolgreich zurück (Write transfer returned successfully from Master Brick) Mich würde interessieren ob im 'abgestürzten' Zustand der Write Transfer in diesem Fall auch ohne Fehler zurück kommt. USB Kabel Die Frage nach dem Kabel, weil wir schon mal Probleme mit USB Kabeln ohne Ferrite Bead (der "Klumpen" hinter dem Mini-USB Stecker) hatten. dmesg In dmesg sollte das so aussehen [229718.296121] usb 6-3: new full speed USB device number 64 using ohci_hcd Linux findet ein neues USB Gerät (new full speed USB device). [229718.936149] usb 6-3: reset full speed USB device number 64 using ohci_hcd Kurz darauf wird brickd darüber informiert und führt einen Reset durch um das Gerät in einen definierten Zustand zu bringen (reset full speed USB device). [230529.492792] usb 6-3: USB disconnect, device number 64 Und hier wurde das USB Gerät wieder abgezogen. Dual Relay Bricklet Wie häufig schaltest du das und was hängt da als geschalteten Last dran? Wie lang sind die Bricklet Kabel die du verwendest?

Diese Defines gibt es schon, es fehlt aber wohl noch deren Dokumentation. Zum Beispiel #define AMBIENT_LIGHT_DEVICE_IDENTIFIER 21 in bricklet_ambient_light.h.

Das Brick Daemon Log ist unter /var/log/brickd.log zu finden. Schau mal was da drin steht. Dann kannst du noch per dmesg schauen was der Kernel über USB Geräte zu sagen hat. Wenn erst USB ab- und anstecken hilft, hängt es vielleicht mit USB zusammen. Ist der Brick direkt per USB an den PC angeschlossen, oder ist da noch ein Hub dazwischen? Was für ein USB Kabel verwendest du? Gibt es ein Muster wann der Brick verschwindet? Fällt es z.B. mit dem Schalten des Dual Relay Bricklets zusammen?

Für das 0-20mA Bricklet haben wir hier einen Prototypen liegen und für ein Industrial Analog Out Bricklet wird noch über mögliche Realisierungen nachgedacht. Das 0-20mA Bricklet steht jetzt auch in der Timeline. Potentiell kommt es nach der Ethernet Extension. Wann genau können wir noch nicht sagen. Für ein Industrial Analog Out Bricklet können wir dir keine weitere Angaben machen.

Ja, ein Bug in der Firmware. Ist in Version 2.0.1 korrigiert.

Firmwares: IO-16 Bricklet 2.0.1 Add missing invocation for set_selected_values function Download: IO-16 Bricklet

Firmwares: IO-16 Bricklet 2.0.1 Fehlenden Aufruf für set_selected_values hinzugefügt Download: IO-16 Bricklet

This Connect/Disconnect button enable/disable logic is already present since Brick Viewer 2.0.1. But it doesn't seem to help in your case.

From your other brickv screenshot I can see that you have Master Brick firmware 2.0.4. This feature is new in firmware 2.0.5 and brickv hides this option for older firmwares.

I thinks what's happening here is that brickv calls is_wifi_present() on the Master Brick and this calls gets a timeout (see the timeout counter shows 1). This makes brickv not show the WIFI configuration UI.

That's interesting. I didn't expect that DHCP would be the cause for this timeouts. Good to know!

Dann hast du einen Master Brick Hardware Version 2.0. Der hat dummerweise eine Änderung drauf, die dafür sorgt, dass der Brick nicht ordentlich in den Bootloader wechselt, wenn eine Master Extension wie WIFI oder RS485 im Stack ist. Das FAQ hat jetzt auch einen Abschnitt über Ursachen dafür, dass ein Brick nicht ordentlich als serielle Schnittstelle auftaucht.

Hier sind also beide per WIFI am AP angebunden? Und hier ist der Rechner per LAN statt WIFI angebunden und der Stack noch wie zuvor? Das macht irgendwie keinen Sinn, oder? Deute für mich darauf hin, dass das Problem auf der LAN Seite liegt, oder nicht? Ist der Durchsatz im LAN so schlecht, dass eine Nachricht vom Rechner zum Stack und zurück einfach länger also 2,5sec braucht?

Does this log tell that it works in general, but that there are some spontaneous TimeoutExceptions in between? I assume you're still calling getDistance() every 500ms. This might be due to WIFI reconnects. You could add the IPConnection ConnectedListener and DisconnectedListener to be able to log automatic reconnects of the IP Connection. Did you have a look at the logs of you WIFI access point? Are there any reconnects from the WIFI Extension at the time the TimeoutException occur? Maybe there was a reconnect just in the middle of a getter call. You could also log the time at which a TimeoutException occurs. For example, are the first two TimeoutExceptions from two getDistance() calls in a row, or are the minutes apart?

Ist seit Java Bindings 2.0.4 verbessert. Im gleichen Zuge habe ich auch den Response Expected Code der anderen Bindings überarbeitet.

Also, Extensions müssen immer über dem unterstem Master Brick im Stack sitzen. Dazu gibts jetzt auch einen Eintrag im FAQ. Der grundsätzliche Stackaufbau ist beim Master Brick beschrieben: Daraus geht auch hervor, dass die Extensions über dem unterstem Master Brick sitzen müssen.

Nice, now I can stop wondering why the TimeoutException got lost

Does the connection loss occur spontaneous, or do you have to do something to trigger this? You said it occurred as you disconnected the stack power input for a moment. Depending on the tab you look at you might not see timeouts immediately. For example, the Distance IR Bricklet tab is callback based. After the initialization it doesn't call any getters or setters anymore. If you switch between tabs you should be able to see the timeout counters go up, as the initialization is re-executed when you switch to a tab.

Bricks can only be flashed via USB (or JTAG) interface. The Erase button has to be pressed during startup to make the microcontroller execute the bootloader that allows to flash a new firmware. So there is no way to flash a new firmware without a USB connection.

I don't see any general problem within your attached code. I stripped down your code to get a working program. The stripped down version is attached. My test stack: Step-Down Power Supply, Master Brick, WIFI Extension, Dual Relay Bricklet, Temperatur Bricklet, Distance IR Bricklet, LCD 20x4 Bricket. WIFI connection established using a AVM FritzBox 7170. The program works as expected. It prints on the LCD and operates the pump. Then I disconnect the power input from the Step-Down Power Supply and the GetDistance() call throws a TimeoutException. Then I power up the stack again. After ~20sec the WIFI Extension re-established the connection, the IPConnection auto-reconnects, and GetDistance() works again. $ java -cp Tinkerforge.jar:. CellarWaterPumpController_Test1 Starting Cellar Water Pump Control System @ Mon Feb 25 13:53:26 CET 2013 Initializing TinkerForge stack.. CONNECTED 0 FAKE: lcd.setCustomCharacter [...] FAKE: lcd.setCustomCharacter Done. LOG: Mon Feb 25 13:53:26 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:26 CET 2013: Water Distance = 67.1 cm LOG: Mon Feb 25 13:53:26 CET 2013: Water level is low. [...] LOG: Mon Feb 25 13:53:28 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:28 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:53:28 CET 2013: Water level is low. LOG: Mon Feb 25 13:53:29 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:29 CET 2013: Water Distance = 7.0 cm LOG: Mon Feb 25 13:53:29 CET 2013: Water level is high. Switching pump ON @ Mon Feb 25 13:53:29 CET 2013. FAKE: setPumpState ON LOG: Mon Feb 25 13:53:29 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:29 CET 2013: Water Distance = 7.0 cm LOG: Mon Feb 25 13:53:29 CET 2013: Water level is high. LOG: Mon Feb 25 13:53:30 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:30 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:53:30 CET 2013: Water level is low. Duration: 1092 FAKE: setPumpState OFF LOG: Mon Feb 25 13:53:30 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:30 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:53:30 CET 2013: Water level is low. [...] LOG: Mon Feb 25 13:53:34 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:34 CET 2013: Water Distance = 67.1 cm LOG: Mon Feb 25 13:53:34 CET 2013: Water level is low. [Disconnecting the input of the Step-Down Power Supply for 3sec] LOG: Mon Feb 25 13:53:34 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:37 CET 2013: Ooops: Did not receive response in time for function ID 1 [...] LOG: Mon Feb 25 13:53:52 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:54 CET 2013: Ooops: Did not receive response in time for function ID 1 LOG: Mon Feb 25 13:53:54 CET 2013: Polling sensors... [WIFI Extension re-established connection, IPConnections auto-reconnects] DISCONNECTED 1 CONNECTED 1 LOG: Mon Feb 25 13:53:57 CET 2013: Ooops: Did not receive response in time for function ID 1 LOG: Mon Feb 25 13:53:57 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:57 CET 2013: Water Distance = 67.1 cm LOG: Mon Feb 25 13:53:57 CET 2013: Water level is low. [...] LOG: Mon Feb 25 13:53:59 CET 2013: Polling sensors... LOG: Mon Feb 25 13:53:59 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:53:59 CET 2013: Water level is low. LOG: Mon Feb 25 13:54:00 CET 2013: Polling sensors... LOG: Mon Feb 25 13:54:00 CET 2013: Water Distance = 7.0 cm LOG: Mon Feb 25 13:54:00 CET 2013: Water level is high. Switching pump ON @ Mon Feb 25 13:54:00 CET 2013. FAKE: setPumpState ON LOG: Mon Feb 25 13:54:00 CET 2013: Polling sensors... LOG: Mon Feb 25 13:54:00 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:54:00 CET 2013: Water level is low. Duration: 543 FAKE: setPumpState OFF LOG: Mon Feb 25 13:54:01 CET 2013: Polling sensors... LOG: Mon Feb 25 13:54:01 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:54:01 CET 2013: Water level is low. [...] LOG: Mon Feb 25 13:54:04 CET 2013: Polling sensors... LOG: Mon Feb 25 13:54:04 CET 2013: Water Distance = 61.0 cm LOG: Mon Feb 25 13:54:04 CET 2013: Water level is low. ^CFAKE: reset So basically I still cannot reproduce your problem. I don't get the SocketException for "Host is down" in sendRequest() but I get the TimeoutException as expected. This was tested with Oracle Java 1.7.0 and OpenJDK 1.6.0_27 on Linux, and Java 1.6.0_37 on Mac OS X. All working, but I don't expect the Java version to blame here Java Bindings version 2.0.5 were used. Can you reproduce the problem with my stripped down version, or the simple example I attached? CellarWaterPumpController_Test1.java ExampleSimple.java