photron

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

Du willst also sagen, dass Pin 3 nach der Zeit nicht zurückschaltet?

Brick Viewer 1.1.19 Updates and Flashing Dialog show only releases with major version 1 (in preparation for Protocol 2.0) Icons and images are now always loaded from the correct directory Should work on older Mac OS X versions (< 10. again Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.19 Updates und Flashing Dialog zeigen nur Releases mit Major Version 1 (Vorbereitung auf Protokoll 2.0) Icons und Bilder werden jetzt immer aus dem richtigen Verzeichnis geladen Sollte wieder auf älteren Mac OS X Versionen (< 10. funktionieren Downloads: Windows, Linux, Mac OS X

Hier jetzt korrigierte Java Bindings zum Testen. tinkerforge_java_bindings_2_0_0_4c60813b8b2c33ca573883d1382bad78ef692994.zip

Einstein, es hat nichts mit deinem Code zu tun, der ist so in Ordnung. Das Problem ist in der IP Connection selbst. Es wird durch den disconnect Aufruf ausgelöst, der versucht den Callback Thread zu beenden. Den gleichen Bug hatten auch die C# Bindings, dort habe ich es gestern behoben.

Hier also endlich das Delphi Unicode Example: http://www.tinkerforge.com/doc/Software/Bricklets/LCD20x4_Bricklet_Delphi.html#unicode

Der Brick Viewer aktiviert Callbacks die er selber verwendet wenn du einen Tab auswählst und deaktiviert sie wieder wenn du den Tab abwählst. Dadurch können sich dein Programm und der Brick Viewer bei der Verwendung von Callbacks/Listenern in die Quere kommen. Wie AuronX schon sagt sind Callbacks standardmäßig deaktiviert und du muss sie erst passen aktivieren.

Du kannst v2 schon testen, siehe Protokoll v2 Beta Thread: http://www.tinkerunity.org/forum/index.php/topic,1238.0.html

BorgelMorgel, folgende Variante für deinen Vorschlag: Diese Auflagen in den vier Ecken nicht unter den Brick sondern oben drüber machen in der Höhe des eigentlichen Schraubbolzens. Dann könne man sich den Bolzen sparen und durch das ganze dann eine Gewindestange ziehen und es würde fest sitzen, weil jeder Brick über und unter sich etwas in de Ecken hat. Mal eine Skizze dazu angehängt, ich hoffe sie ist verständliche. Links: Deckel, 3x Stepper Gehäuse, Boden. Mitte: Das ganze mit Bricks. Rechts: Das ganze zusammen gedrückt.

Es gibt nur get_state und set_state, welche immer für beide Relais sind. Du kannst folgendes tun um nur den Zustand von Relais 1 zu ändern und Relais 2 unverändert zu lassen: state = dr.get_state() dr.set_state(True, state[1])

Ich hab mir jetzt mal den libusb Code im Detail angesehen und es sieht so aus, dass dadurch wie wir libusb in brickd benutzen bei jedem Abstecken eines Bricks (sei es mechanisch oder per Reset) intern ein Teil einer endlichen Ressource leakt. Und nach ca. 50 Mal Abstecken ist die Ressource vollständig belegt. brickd kann dann nicht mehr mit Bricks über USB kommunizieren und muss neugestartet werden. Das betrifft soweit ich das sehe nur Windows. Ich sehe leider im Moment keine Möglichkeit das zu fixen. Ich habe mir das auch noch mal im neuen Brick Daemon für Protokol v2 angesehen. Dort benutzen wir libusb etwas anders so dass dort dieses Problem nicht auftritt. Genauer gesagt, mit brickd v1 betrifft das Problem alle Windows Versionen. Mit brickd v2 nur noch Windows XP, dort verhält sich die WinUSB API aus irgendwelchen Gründen anders. Windows Vista und neuer sind nicht mehr betroffen. TL;DR: Mit Brick Daemon für Protokol v2 ist das Problem in den allermeisten Fällen behoben.

Die Position der Stecker ist nicht direkt als solche dokumentiert. Du kannst dir aber die KiCAD Platinenlayouts der Bricks ansehen und es daraus ablesen Diese sind auf github zu finden, z.B. hier: https://github.com/Tinkerforge/stepper-brick/tree/master/hardware

Zu Bedenke ist dann, dass es Bricks in zwei verschiedenen Höhen gibt. Dadurch kann die Gesamthöhe des Stack auch bei gleicher Teilnehmerzahl stark variieren.

Das sind Fehler aus libusb, die wir für die USB Interaktion verwenden. LIBUSB_ERROR_NO_MEM besagt, dass nicht genug Speicher frei war. Achte doch mal bitte auf den Speicherverbrauch von brickd während dein Programm läuft. Es scheint mir aber dass da ein andere Fehler vorliegt den libusb aber fälschlicherweise als LIBUSB_ERROR_NO_MEM meldet. Ich muss mir dazu mal den Source Code ansehen. Wie arbeitet dein Programm? Ich nehme an du öffnest am Anfang eine IPConnection und rufst da periodisch GetPort auf. Wenn du erkennst, dass das IO-16 Bricklet nicht mehr reagiert resettest du das ganze. Wie häufig resettest du bis brickd hängt?

Steht im Windows Event Log eine Fehler oder Warnung von brickd?

Nic, die Frage war doch ob man 6 Stepper Brick in einem Stack mit Master und WIFI betreiben kann, oder nicht? Ja, das kann man. Dann gibt es noch die Frage nach der Stromversorgung, die wurde hier gar nicht direkt gestellt, oder übersehe ich die? Dazu gibt es die 2 Optionen: a) Per Step-Down Power Supply bis zu 27V mit 5A in den Stack einzuspeisen. Darüber können dann die Stepper Bricks auch die Motoren versorgen. b) Wenn 27V oder 5A nicht ausreichen kann man auch an jedem Stepper Brick einzeln bis zu 38V mit 2,5A (pro Phase) einspeisen. Dann kann man a) und b) auch noch mischen, da die Stepper Bricks schlau sind und passend umschalten, je nachdem ob sie den Motorstrom über den Stack oder ihren eigenen Anschluss beziehen können. Und nein, ich nehme es dir überhaupt nicht übel wenn du hier den Leuten helfen willst. Ich finde es gut, dass du das tust Mein Punkt ist nur, dass dein Post sich so liest als können man niemals 6 Stepper Bricks mit 1,7A Stepper Motoren in einem Stack betreiben, nur weil man sie dann nicht direkt über den Stack versorgen kann, denn dem ist nicht so.

Der Stack kann über die 10 Power Leitungen nur insgesammt 5A transportieren. richtig. Aber jeder Stepper Brick hat ja auch noch seinen eigenen schwarzen Power Anschluss über den man dessen Motor versorgen kann.

The 1.0.1 is the API version of the IMU Brick. We have plenty of version numbers: the API version, the bindings version, the firmware version, etc We should raise the API version to v2 too, thanks for reporting this. You can still use git to get the bindings for protocol v1 you just need to switch to the v1.x.y branch using 'git checkout v1.x.y'.