photron

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.

Danke für den Hinweis, ist korrigiert.

Wir versuchen möglichst viel des Binding Codes zu generieren. IPConnection.java und Device.java sind handgeschrieben der Rest wird generiert. Daher ist es einfacher den Generator getIdentity() implementieren zu lassen.

The_Real_Black, hat das Flashen den geklappt im Sinne von Brick Viewer hat keine Fehler gemeldet? Oder kommt die Meldung mit Code 43 im Gerätemanager wenn der Brick im Bootloader ist?

Andu, das war ein Fehler in der USB Unplug Erkennung. Der hatte sich in 2.0.2 eingeschlichen. In Brick Daemon 2.0.3 ist das jetzt korrigiert. Nic, ist das ein neues Problem oder besteht das schon länger?

Brick Daemon 2.0.3 Fix USB unplug detection on Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.3 Fehler in USB Unplug Erkennung korrigiert auf Windows Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Mit Brick Daemon 2.0.2 ist jetzt auch eine Version released in der das Problem korrigiert ist.

Brick Daemon 2.0.2 kann jetzt auf Windows auch als normales Kommandozeilenprogramm gestartet werden.

Brick Daemon 2.0.2 An error during client peer name lookup doesn't abort the socket connection anymore Support running as normal console application on Windows Support MinGW as compiler on Windows Support running as non-root on Linux Improve --help output Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.2 Fehler während des Client Peer Name Lookups brichtjetzt nicht mehr die Socketverbindung ab Support für Ausführung als normales Kommandozeilenprogramm auf Windows Support für MinGW als Compiler auf Windows Support für Ausführung als User auf Linux --help Ausgabe verbessert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Richtig, das fehlte. Ist jetzt auch drin. Danke für den Hinweis.