photron

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

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 Add get/set_range functions to Analog In Bricklet API [all] Fix unlikely race condition in response packet handling [all, except PHP] Add TinkerforgeException as basis for all other exceptions [all, except C/C++ and Python] Fix dispatch of pending enumerate callbacks when dispatchCallbacks(-1) is used Fix serialization of unicode strings [Python] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

The 5V line is used to power the LCD. If the cable gets to long the LCD will get a too low voltage on the 5V line and might not work anymore. Whether or not I2C over a longer cable will work for you depends on your environment. A long cable acts as an antenna capturing interference that can disturb the I2C communication. The 2m Bricklet cables work in most cases. A longer cable might work for you, that depends on your specific setup and environment. So you'll have to try

So... mit Version 2.0.1 hat das Analog In jetzt get/set_range über die der Messbereich gewählt werden kann.

Firmwares: Analog In Bricklet 2.0.1 Support manual measurement range selection Download: Analog In Bricklet

Firmwares: Analog In Bricklet 2.0.1 Messbereich ist manuell einstellbar Download: Analog In Bricklet