photron

Mit "nach dem Flashen" meinst du nach dem der Fortschrittsbalken für Write und Verify durch ist? Dann kann das eigentlich nur das Auslösen des Resets sein. Wenn du die Bricks dann manuell neustartest, dann funktionieren sie und haben auch die passende Firmwareversion? Wenn ja dann ist der Fehler harmlos. Wobei mir nicht klar ist warum das Flashen funktioniert das Neustarten aber nicht. Ich werde die Fehlermeldungen mal detaillierter machen damit man das in Zukunft besser nachvollziehen kann, denn ein "Serial write error" wird im Moment an mehreren Stellen ausgegeben.

Das Problem war das in den Delphi Bindings TTcpClient verwendet wurde und da konnte ich nicht herausfinden wie ich da TCP_NODELAY setze. TTcpClient hat werder eine direkte Option für TCP_NODELAY noch eine SetSockOpt Funktion. TIdSocketHandle aus dem Indy Package hat SetSockOpt aber da wollte ich mich nicht auf die Verfügbarkeit von Indy verlassen müssen. Ich bin gerade dabei das einfach mit WinSock neu zuschreiben, da hab ich dann setsockopt und alles ist gut. Dennoch Danke für die Hinweise. Es gibt dann gleich eine neue Version der Delphi Bindings.

Richtig, über den Enumerate Listener und einen ipcon.enumerate() Aufruf kannst du alle angeschlossenen Bricks und Bricklets dazu veranlassen sich zu melden. dr.setMonoflop(relay, true, ms); Das wirft keine TimeoutException da auf Setter wie setMonoflop standardmässig keine Antwort vom Brick(let) kommt. Dadurch können die Bindings dann nicht erkennen ob die Anfrage angekommen ist un nehmen an sie wäre es. Das kannst du ändern, indem du mittels dr.setResponseExpectedAll(true) für alle Funktionen des Dual Relay Bricklets eine Antwort erzwingst. Alternative kann das auch mittels dr.setResponseExpected(BrickletDualRelay.FUNCTION_SET_MONOFLOP, true) nur für setMonoflop erzwungen werden. Eine Antwort zu erzwingen hat den Vorteil, dass du in deinem Fall dann eine TimeoutException bekommst wenn kein Dual Relay Bricklet mit passender UID angeschlossen ist. Es hat aber auch den Nachteil, dass mehr Nachrichten dafür verschickt werden müssen.

BorgelMorgel, daran ist einen Fehler in der 2.0.0 Firmware des Joysticks schuld, wodurch das Bricklet nicht auf alle Anfragen richtig geantwortet hat. In Version 2.0.1 ist der Fehler behoben. Danke für den Hinweis. Durch eine Änderung der Logik des Joystick Bricklets (war schon im Juni 2012) funktionierte das Find Corners Example nicht mehr wie vorgesehen. Das ist allerdings erst jetzt aufgefallen . Daher gibt es jetzt stattdessen das Find Borders Example.

It was com.tinkerforge.IPConnection.TimeoutException in bindings version 1.x.y. I moved the TimeoutException to com.tinkerforge.TimeoutException in version 2.0.0, but missed to remove it from com.tinkerforge.IPConnection. The inner version of TimeoutException is not used anymore in the bindings and I just remove it in version 2.0.2. You only need com.tinkerforge.TimeoutException in your program. Sorry for this oversight.

Bindings: Java 2.0.2 Remove unused IPConnection.*Exception classes Download: Java

Bindings: Java 2.0.2 Unbenutzte IPConnection.*Exception Klassen entfernt Download: Java

Im alten Protokoll war es so, dass der Chibi/RS485 Master beim Start seine Slaves gesucht hat. Deshalb musste man den Chibi/RS485 Master immer nach den Slaves starten, damit die Slaves schon initialisiert sind wenn der Chibi/RS485 Master sie sucht. Dieses Suchen der Slaves gibt es im neuen Protokoll nicht mehr, Das funktioniert jetzt dynamisch und es können im laufenden Betrieb Master uns Slaves beliebig neugestartet/hinzugefügt/entfernt werden und das Gesamtsystem sollte davon unbeeinträchtigt weiterlaufen.

Okay, we obtained another Mac Book with Mac OS X 10.7.3 and were able to reproduce the segmentation and illegal instruction faults. A GDB backtrace is useless here because the errors occur before the main function is executed. So the problem is not in the C code, but in the way the binary is build. I didn't figure out the real problem yet, but building the same unchanged source code using the same unchanged Makefile on Mac OS X 10.7.3 produces a binary that works. Brick Daemon 2.0.1 was just released and is tested to work on Mac OS X 10.7.3 and 10.8.2. Therefore, it should work on your 10.7.5 too. Thanks for reporting this and sorry for the trouble.

Brick Daemon 2.0.1 Add socket peer name to related log messages Don't accept an empty string as valid integer value in config file Reject 0 as port number in config file Report config errors to log file Tested on Mac OS X 10.7.3 und 10.8.2. Brick Daemon 2.0.0 crashed on Mac OS X 10.7.5 immediately after start up. Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.1 Socket Peername wird in Socket bezogenen Log Messages mit ausgegeben Ein leerer String ist keine gültige Zahl in der Konfigurationsdatei 0 ist keine gültige Portnummer in der Konfigurationsdatei Fehler in der Konfigurationsdatei werden im Log gemeldet Getestet auf Mac OS X 10.7.3 und 10.8.2. Brick Deamon 2.0.0 stürzte auf Mac OS X 10.7.5 direkt beim Start ab. Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Viewer 2.0.1 Add custom character support to LCD Bricklet plugins Handle no-internet-connection case probably in updates dialog Add more information to Bricklet UID and plugin writing error messages Make Protocol 1.0 Bricklet auto-detection more robust Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.1 Unterstützung für benutzerdefinierte Buchstaben für LCD20x4 und LCD16x2 Bricklet hinzugefügt Updates Dialog detektiert jetzt wieder richtig, ob eine Internetverbindung besteht Fehlermeldungen beim Bricklet UID und Plugin schreiben enthalten mehr Information Automatische Erkennung von Protokoll 1.0 Bricklets ist robuster Downloads: Windows, Linux, Mac OS X

Alle 2.0 Bindings haben TCP_NODELAY aktiviert.

Passiert das nur bei diesem einen Brick, oder auch bei anderen an diesem Rechner? Du könntest versuchen den WinUSB Treiber für den Brick über Zadig zu installieren. Vielleicht macht das einen Unterschied. http://download.tinkerforge.com/_stuff/zadig_v2.0.1.159.exe

There is a hardware wishlist (in German) in the wiki: http://www.tinkerunity.org/wiki/index.php/DE/Produkt_Wunschliste There is also this hardware voting thread (that is a bit outdated by now): http://www.tinkerunity.org/forum/index.php/topic,314.50.html

Even though our MacBook runs Mac OS X 10.8 the latest installed SDK is 10.6. So the original brickd 2.0.0 should just work on Mac OS X 10.6 and newer. Here's a version explicitly compiled for SDK 10.5: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_0_mmacosx_version_min105.dmg If this doesn't work either we need to look into more detail why it doesn't work for you. Do you have gdb installed (part of the Xcode commandline tools) an can get a backtrace of the segfault?

Die Kalibrierung die man im Brick Viewer unter Advanced Functions machen kann ist für den AD-Wandler des Bricks. Der hat mit dem Temperature Bricklet nichts zu tun, da diese digital per I2C Bus ausgelesen wird. Das Problem ist komisch. Etwas ins Blaue geraten frage ich daher mal ob da vielleicht krumme Pins in einem den Brickletanschlüsse an den Master Bricks sind? Ist die Temperatur nur zwischen den beiden Master Bricks unterschiedlich, oder auch zwischen den einzelnen Brickletanschlüssen eines Bricks?

Wenn du den Brick anschließt meldet Windows, dass neue Hardware gefunden wurde. Du installierst den Treiber und das funktioniert auch erstmal? Wann meldet Windows dann wieder das neue Hardware gefunden wurde? Einfach so, oder erst nach erneutem Anstecken des Bricks? Ist der Brick nach der Treiber Installation richtig im Geräte Manager aufgeführt?

Hast du mal den Rechner neugestartet?

Die Dokumentation für 2.0 auf dem Server war nicht aktuell, ich habe sie gerade neu generiert. Die Dokumentation ist für die aktuelle Version der Bindings im git. Zum Beispiel addTemperatureListener ist Teil der letzten Änderung, die wir nach Beta 1 gemacht haben. Es wird wohl heute noch Beta 2 der Firmwares und Bindings geben.

Interessant! Wenn socket.setTcpNoDelay(true) hilft, dann sollte das Problem nicht direkt mit WIFI zusammenhängen, sondern auch über LAN auftreten. Hast du einen 2. Rechner zur Hand an dem du den Stack per USB anschließen und dann noch mal testen kannst? 2. Rechner, damit die TCP Kommunikation nicht nur über Localhost geht und das Betriebssystem dann da irgendwas anders macht oder optimiert.

Wenn du die richtigen Pins (I2C Bus) erwischt dann kann der Master noch funktionieren aber der I2C Bus ist dann gestört. Der Sensor des Barometer Bricklets wird per I2C ausgelesen, da ein I2C Bus für alle Bricklet Ports verwendet wird kannst mit einem Kurzschluss in einem Port einen anderen stören. Hat also nichts mit dem AD-Wandler zu tun. Die Höhenmessung muss immer wieder kalibriert werden, da wie vom aktuellen Ort und Wetter abhängig ist, siehe: http://www.tinkerunity.org/forum/index.php/topic,946.0.html

Nein, die beiden sind gleich: Geschlossen/angeschaltet bedeutet die beiden Kontakte des (Solid State) Relays sind verbunden, es kann Strom fließen. Geöffnet/ausgeschaltet bedeutet die beiden Kontakte des (Solid State) Relays sind nicht verbunden, es kann kein Strom fließen. In der Dokumentation werden da verschiedenen Worte für das gleich verwendet. Das sollte verbessert werden, ist auf der TODO Liste.

TimeoutException bekommst du nur wenn du etwas aufrufst. Die kommt nicht spontan. TimeoutException für Setter wie WriteLine bekommst du standardmässig nicht. Dazu musst du das Response Expected Flag für diese Funktion aktivieren. Das ist neu. lcd.setResponseExpected(BrickletLCD20x4.FUCNTION_WRITE_LINE, true); Oder gleich für alle Funktionen aktiveren: lcd.setResponseExpectedAll(true); Für Callback Konfigurationsfunktionen ist das Flag standardmäßig an und Getter natürlich auch. Ansonsten ist das empfohlene Vorgehen für robuste Programme den Enumerate Callback zu verwenden. Darüber bekommst mitgeteilt wenn etwas neu verbunden wird und potentiell neu konfiguriert werden muss. Dazu gibt es dann auch noch ein neues Beispielprogramm an dem das genauer erklärt wird. Über den Callback bekommst du auch mitgeteilt wenn etwas von USB abgesteckt wird. Das funktioniert allerdings nur für USB, da der Brick Daemon hier vom Betriebssystem gesagt bekommt das USB getrennt wurde. Dann kann brickd für alle Bricks und Bricklets die ihm für diese USB Gerät bekannt waren einen Enumrate Callback für Disconnect senden. Wie gesagt geht das das nur für die Bricks und Bricklets die brickd bekannt sind im Sinne von brickd hat schon Kommunikation mit diesen gesehen. Ein Device mit dem nie kommuniziert wurde kann brickd nicht kennen und daher auch keinen Enumerate Callback für disconnect senden