photron

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.

Schreiben auf's LCD und setzen der IO16 Pins ist schnell, weil da in deinem Programm nicht auf eine Antwort über WIFI gewartet wird. WriteLine und SetPort returnen sobald die Daten per Netzwerk rausgeschickt wurden, darum merkst du da die Verzögerung nicht. Auf dem Brick kommt das Ganze dann aber mit Verzögerung an, bzw. wird mit Verzögerung bearbeitet. Bei GetPort muss der Aufruf in C# warten bis die Antwort vom Brick da ist, da merkst du dann die Verzögerung wieder. Soll heißen nicht nur GetPort ist bei dir langsam, sondern das sollte auch alle anderen Getter betreffen, z.B. IsButtonPressed des LCD. Rufst du viele Setter pro Sekunde auf? Es könnte sein, dass du den Eingangsbuffer der WIFI Extension mit Setter Aufrufen auf einem hohen Füllstand hältst und es deshalb länger dauert bis ein GetPort Aufruf eine Antwort bekommt. Ist also GetPort auch dann langsam, wenn dein Programm nur GetPort aufruft oder wird es erst langsam wenn du noch viele andere Funktionen aufrufst? In dem Falle überforderst du sozusagen die WIFI Extension und du solltest versuchen weniger Funktionen pro Sekunde aufzurufen.

Also doch Modif. im Framework ? Die Funktionsaufrufe der Bindings führen direkt Netzwerkkommunikation und blockieren auch im Zweifelsfall bis zum Timeout. Unter Android darf/soll man im UI Thread aber nichts potentiell blockierendes tun, damit das UI nicht hängen kann. Seit Android 4.2 bekommt man z.B. eine NetworkOnMainThreadException wenn man im UI Thread versucht einen Socket zu öffnen. Die Lösung dafür ist die Bindings in einem AsyncTask oder eigenen Thread zu benutzen.