photron

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

Brick Viewer 2.0.3 Filter out false-positives errors in Protocol 1.0 detection Check WEP key for being in hexadecimal notation and 10 or 26 digits long Trigger enumeration for RS485/Chibi slaves if RS485/Chibi master enumerates itself as connected Fix IO-4 Bricklet Plugin initialization Fix Piezo Buzzer Bricklet Protocol 1.0 auto detection NSIS installer for Windows installs bootloader driver Add support for WIFI hostname configuration to Master Brick plugin Add support for measurement range selection to Analog In Bricklet plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.3 False-Positive Fehler in Protokoll 1.0 Erkennung werden besser erkannt WEP Schlüssel wird auf hexadezimal Notation und richtig Länge geprüft Enumeration wird für RS485/Chibi Slaves ausgelöst wenn sich ein RS485/Chibi Master selbst als connected enumeriert Fehler IO-4 Bricklet Plugin Initialisierung korrigiert Piezo Buzzer Bricklet Protokoll 1.0 Autodetektion korrigiert NSIS Installer für Windows installiert den Bootloader Treiber WIFI Hostname im Master Brick Plugin einstellbar Messbereich im Analog In Bricklet Plugin einstellbar Downloads: Windows, Linux, Mac OS X

Java Bindings 2.0.5 have a TinkerforgeException as basis now.

Bindings: C/C++ 2.0.4, C# 2.0.5, Delphi 2.0.6, Java 2.0.5, PHP 2.0.5, Python 2.0.5, Ruby 2.0.5, VB.NET 2.0.1 get/set_range Funktionen zur Analog In Bricklet API hinzugefügt [alle] Unwahrscheinliche Race Condition in der Antwortpaketbehandlung korrigiert [alle, außer PHP] TinkerforgeException als Basis aller anderen Exceptions hinzugefügt [alle, außer C/C++ und Python] Auslieferung von ausstehenden Enumerate Callbacks korrigiert wenn dispatchCallbacks(-1) verwendet wird Serialisierung von Unicode Strings korrigiert [Python] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET