photron

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

I could not reproduce your exact problem. For me the socket read call in the receive thread is the one that detects the disconnect, never the socket write in IPConnection.sendRequest() as in your case. I also get the TimeoutExceptions as expected in this case. Can you reproduce this problem? What is the order of events in that case? Are you calling getDistance() in a loop, see the stack trace print from the SocketException about "Host is down" and after that a getDistance() call returns you a value? Does that value look valid? If that's the case is there only one successful getDistance() call after the stack trace and all following calls fail with a TimeoutException? Or does getDistance() just work for several calls in a row after the stack trace?

remotecontrol, I think that's a reasonable idea. We could extend this to report exceptions from user code that might occur on the callback thread will executing user callback functions as well. AuronX suggested something similar for exceptions in user callback function in the C# bindings last week, but I didn't decide on a final solution for this yet.

For longer connections there is the RS485 Master Extension that allows to split stacks with up to 1200m cable in between. You'd need 1x Master Brick (as base for the second stack) and 2x RS485 Master Extensions (one for each stack) in addition to your current stack.

You're right regarding the try/catch/print in IPconnection.sendRequest(). This should be handled differently. But just throwing a NotConnectedException exception there is wrong, because socket is not null resulting in a AlreadyConnectedException being thrown if you call connect() in your NotConnectedException handler. This results in a situation where the exceptions contradict each other. The correct approach for this would be to handle a socket write error the same as a socket read error: Deal with it properly as a disconnect, trigger the disconnected callback and the auto-reconnect handling, if enabled. I think for the try/catch/print in disconnect() where we just want to close the streams and socket we should not raise an additional exception, but just ignore any IOException on the way out closing the connection. Almost all remaining try/catch/print's are on internal threads, where it doesn't make sense to throw them wrap in another exception, because that will just kill the thread breaking the internal working of the IPConnection. Also most of them are InterruptedExceptions that should never be able to occur, except someone decides to fiddle with the internals of the IPConnection and call interrupt() on the internal threads. So we need to catch and ignore InterruptedExceptions there. Finally, your getDistance() won't return you a value in case IPconnection.sendRequest() fails the way you've described, because without a request being send there won't be any response and Device.sendRequest() will raise a TimeoutException.

Zu dem Problem gibt es einen FAQ Eintrag: http://www.tinkerforge.com/doc/FAQ.html#eines-meiner-bricklets-wird-im-brick-viewer-nicht-angezeigt Probier bitte mal die dort beschriebenen Möglichkeiten aus.

Das Locking ist mit der letzten Version in allen Binsings verbessert worden. In allen Bindings wird das Request Lock nur noch für Getter Aufrufe (und Setter mit Response Expected Flag) gehalten. Das Socket Lock wird nur noch direkt um die Interaktion mit dem Socket gehalten. Es wird in Java nicht mehr für die gesamte Zeit eines Getter Aufrufs gehalten.

Ist jetzt in Java Bindings 2.0.4 verbessert.

Richtig, der Hostname wird permanent gespeichert, wie die anderen WIFI Einstellungen.

Deine Vermutung ist korrekt Bis dahin kannst du das aber schon über set_wifi_hostname setzen.

Bindings: C/C++ 2.0.3, C# 2.0.4, Delphi 2.0.5, Java 2.0.4, PHP 2.0.4, Python 2.0.4, Ruby 2.0.4 Reduce scope of request and socket mutex to improve concurrency [all, except PHP] Improve and unify code for response expected flag handling [all] Add get/set_wifi_hostname functions and callbacks for stack/USB voltage and stack current to Master Brick API [all] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 2.0.3, C# 2.0.4, Delphi 2.0.5, Java 2.0.4, PHP 2.0.4, Python 2.0.4, Ruby 2.0.4 Geltungsbereich für Request und Socket Mutex veringert um Nebenläufigkeit zu verbessern [alle, außer PHP] Code für die Behandlung des Response Expected Flag vereinheitlicht und vereinfacht [alle] get/set_wifi_hostname Funktionen und Callbacks für Stack/USB Voltage und Stack Current zur Master Brick API hinzugefügt [alle] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby