photron

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'.

imu_set_response_expected_all is new in protocol v2, so you're using the C bindings for protocol v2 here. Did you do this on purpose, or accidently by getting the latest code from git? You need to use brickd, brickv, firmwares and bindings in either for protocol v1 or v2, you cannot mix them. Currently v2 is still in beta. If you got the C bindings in v2 by accident then just get the latest v1 version from here: http://www.tinkerforge.com/doc/Downloads.html If you decided to use v2 on purpose then ensure that brickd, brickv and the firmware flashed on the IMU Brick is v2. If that's already the case then you might be using the wrong UID, ensure that you use the UID shown for the IMU Brick in brickv.

Auf meinem Ubuntu mit Linux Kernel 3.0 brauche ich keinen extra Treiber. Der Brick im Bootloader Modus wird vom cdc_acm Treiber abgehandelt. Ist das in Kernel 3.5 jetzt anders? Was sagt dmesg denn wenn du deinen Brick im Bootloader Modus per USB anschließt? [245768.151243] cdc_acm 6-2:1.0: This device cannot do calls on its own. It is not a modem. [245768.151280] cdc_acm 6-2:1.0: ttyACM0: USB ACM device Im brickv wähle ich dann /dev/ttyACM0 als Serial Port aus zum Flashen.

Ein Pin im Stack verträgt 500mA. Der Stack hat 10 Pins für Power (die externe Spannung der Power Supply die auch Treiber Bricks nutzen können), daher kann der Stack da 5A transportieren und z.B. bei 5 Stepper Bricks in einem Stack kann sich jeder dann 1A genehmigen. Keine Ahnung wo die Information mit 3A in diesem Kontext herkommt. Die Step-Down Power Supply kann 5V mit bis zu 3A liefern, ja, aber das sind die 5V, nicht Power. Die USB Versorgungsspannung muss zwischen 4,8V und 5,7V liegen. Laut Datenblatt kann das Relais auf dem Dual Relay Bricklet 360 Schaltoperation pro Stunde also 1 Mal pro Sekunde. Ja, ihr habt recht, das ist alles nicht gut dokumentiert, sorry. Das ist aber keine Absicht unsererseits und ich verbessere gerade die Dokumentation.

Sieht toll aus mit dem Lego Gehäuse

Hast du mal andere Getter getestet? IsButtonPressed des LCDs oder GetStackVoltage des Masters. Ich erwarte, dass die auch so langsam sind. Bei Settern merkst du die Verzögerung beim Methodenaufruf nicht, weil da nicht auf eine Antwort gewartet wird, sie ist aber da. Das heißt, wenn du beim LCD das Backlight einschaltest solltest du zwischen BacklightOn Aufruf und bis das Backlight wirklich an geht 100ms Verzögerung sehen können (unter der Annahme, dass die Verzögerung auf Hin- und Rückweg gleich ist). Wenn du also nicht durch viele Aufrufe den Eingangsbuffer der WIFI Extensions voll hältst, dann bleibt noch schlechter WIFI Empfang als Erklärung. Du könntest auch mal versuchen die WIFI Extension als Access Point zu konfigurieren und dich dann direkt mir ihr zu verbinden um deinen normalen Access Point aus der Gleichung heraus zu nehmen.