photron

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

Die 0,1K ist als konservative Angabe für 0,06K zu sehen Die 0,06K Schritte sind das normale Verhalten.

Die Dokumentation spricht von 0,1°C Auflösung. Wo kommen die Angabe über 0,01°C her?

Richtig, getResponseExpected mach unnötige viele Funktionsaufrufe. Ich bin gerade dabei das in Java zu verbessern und schau mir dann auch noch alle anderen Bindings an.

Ah ich sehe was du meinst. Du beziehst dich auf den socketMutex. Der ist neu in v2 und führt dazu dass alle Setter/Getter Aufrufe aller Devices der selben IPConnection serialisiert werden. Das ist schlecht für die Performance mit mehreren Threads. Da haben wir nicht aufgepasst AuronX, du beziehst dich auf den requestMutex im Setter Fall. Wie im Pull Request schon gesagt sehe ich da keine Problem das zu ändern. In remotecontrols Fall über WLAN (nehme ich an) wo die Getter Roundtriptime höher ist ist der Gewinn einer solchen Änderung natürlich deutlich größer als über USB. Damit steht jetzt feineres Locking auf der TODO Liste für die nächste Release.

Das ist das alte Vorgehen aus v1 Zeiten. In v2 haben alle Devices addXYZListener(XYZListener listener) und removeXYZListener(XYZListener listener) pro Listenertype. Diese Umbau ist uns für die IPConnection durch die Lappen gegangen, sorry. In der nächsten Java Bindings Version wird das geändert sein.