photron

Ich kann das TArray0To2OfUInt8 Problem reproduzieren. Ich könnte schwören ich hab das vor Release alles getestet und es hat funktioniert auch mit Delphi XE2. Ich bin gerade dabei das zu fixen.

Ich denke du hast hier das gleiche Problem wie Bralph in diesem Thread: http://www.tinkerunity.org/forum/index.php/topic,1357.0.html Wenn ich das richtig sehe ist overwrite hier richtig, weil GetIdentity aus TDevice ja wirklich überschrieben werden soll. reintroduce überschreibt nicht wenn ich das richtig verstehe. Das Problem hier liegt in der mehrfachen Definition von TArray0To2OfUInt8. Ich bin dabei das zu korrigieren.

Ist in Python Bindings Version 2.0.2 korrigiert.

Bindings: Python 2.0.2 Fix char list packing in Python3 Download: Python

Bindings: Python 2.0.2 Char List Packing in Python3 korrigiert Download: Python

Ist in PHP Bindings 2.0.2 korrigiert.

Bindings: PHP 2.0.2 Fix UID encoding/decoding on 32bit systems Download: PHP

Bindings: PHP 2.0.2 Encoding/Decoding der UID auf 32Bit Systemen korrigiert Download: PHP

Bindings: Delphi 2.0.2 Rewrite socket code to use WinSock on Windows, allows to set TCP_NODELAY Download: Delphi

Bindings: Delphi 2.0.2 Socket Code für Windows auf WinSock umgestellt, dies erlaubt es TCP_NODELAY zu setzen Download: Delphi

Ich nehme an du hast ein 32bit Ubuntu. Damit konnte ich gerade das Problem reproduzieren. Auf 64bit tritt es nicht auf. Es hängt mit der Größe des internen Integertypes von PHP zusammen. Eine Lösung ist in Arbeit.

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