photron

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])

Gestern - als ich die Abstürze des Daemon hatte - lief das System (wohl auf Grund der längeren Kabel) sehr unzuverlässig und hat etwa 40 Reset in 10 Minuten gefahren. So beim ca. 40sten Reset hat sich dann der Daemon verabschiedet.

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

Prinzipiell würden 2 Teile ausreichen: Eine Bodenplatte etwa 50x50mm mit Bohrungen/Gewinde für M3 zum Anschrauben des Stacks, über diese Bodenplatte wird ein Verkantprofil in der Maximallänge eines Stacks, der höchstens bestehen kann aus 1*Step-Down Power Supply + 1*Master + 8*Brick + 2*Extension als Schutzverkleidung übergestülpt. Die Seitenwände haben Vorbohrungen für die USB-Buchsen und zumindest Reset/Erase Schalter. Lassen sich Sollbruchstellen oder Einkerbungen ins Material anbringen um das Vierkant auf die passende Höhe (1, 2, 4, ... Bricks) später abzutrennen ?

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.

Was meinst Du mit

Mit dem Thread-Handling muss man etwas aufpassen.

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.

Hier wird von max.3A berichtet, die durch den Stack dürfen: http://www.tinkerunity.org/forum/index.php/topic,965.msg6813.html#msg6813

Was aber bedeutet dann 10x500mA, doch max. 5A ?

Die Step-Down Power Supply kann auf der 5V Leitung 3A liefern.

Aber es geht hier nicht um die 5V Ausgangsleistung der Step-Down Power Supply, sondern um die Powerleitungen im Stack, die haben mit der 5V Leitung nichts zu tun.

Das sind sozusagen "Kompassgrad", 0° ist Norden, 90° ist Osten.

Auch das fehlt noch in der Dokumentation.

Falls du Mac OS X mit Brick Viewer 1.1.17 verwendest dann solltest du auf 1.1.18 updaten, denn 1.1.17 hat einen Fehler, der dazu führt, dass das Dual Relay nicht angezeigt wird.

Falls das nicht das Problem ist kann es sein, dass das Bricklet keine UID gesetzt hat bzw. sie verloren hat. Das kannst du im Brick Viewer kontrollieren: Flashing -> Bricklet -> Passenden Brick und Port wählen an dem das Bricklet hängt -> UID Load klicken. Wenn da dann 1 steht hat das Bricklet keine UID gesetzt. Dann kannst du da etwas ungleich 1 eingeben z.B. dr1 und Save klicken. Wenn du jetzt den Brick neustartest sollte das Bricklet wieder auftauchen.

Falls das auch nicht hilft, dann bleiben noch andere Dinge zu testen:

• Ein anderes Bricklet Kabel versucht?
  
• Einen anderen Port am Brick?
  
• Das Bricklet mittels Brick Viewer neu flashen (geht im gleichen Tab wie das UID Lesen/Setzen)?