photron
-
Gesamte Inhalte
3.054 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
39
Posts erstellt von photron
-
-
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.
-
-
-
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.
- Add socket peer name to related log messages
-
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.
- Socket Peername wird in Socket bezogenen Log Messages mit ausgegeben
-
-
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
- Unterstützung für benutzerdefinierte Buchstaben für LCD20x4 und LCD16x2 Bricklet hinzugefügt
-
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.
-
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:
-
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.
-
Also normal sollte ich ja TimeoutException bekommen wen etwas nicht erreichbar ist wen das der Fall ist würde ich ein pause machen und danach einen neu Verbindung machen(besiungs weise könnte ich ja auch die callbacks neu aufrufen).
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
-
Du willst also sagen, dass Pin 3 nach der Zeit nicht zurückschaltet?
-
-
again
Problem beim Upgrade auf 2.0
in Allgemeine Diskussionen
Geschrieben
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.