photron

No, the normal characters' bitmaps cannot be read from the LCD. I fixed generator to add the missing [].

Der Brick Daemon funktioniert im Moment wirklich nur als Service. Es spricht aber nichts dagegen, ihn auch als normales Programm lauffähig zu machen. Bas brauch ein paar Änderungen, es sollte recht einfach sein. Ich setzte es mal auf die TODO Liste. Dementsprechend macht die optionale Service Installation im Moment keinen Sinn, das stimmt. Der Neustart hat denke ich historische Gründe, als brickd noch in Python war gab es wohl mal Probleme damit den Service ordentlich zu starten und ein Neustart des Systems war dann ein Workaround dafür, wenn auch ein drastischer. Ich persönlich hatte damit allerdings noch nie Probleme. Kommt auch auf die TODO Liste das noch mal anzusehen, ob man diesen Fall nicht besser behandeln kann, bzw ob er überhaupt noch besteht.

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