photron

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.

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

GetCoordinates gibt immer etwas zurück, die Daten sind allerdings nur dann richtig/gültig, wenn GetStatus einen 2D oder 3D Fix anzeigt. Das war leider so noch nicht dokumentiert, ich verbessere das gerade. Ich hab's gerade noch mal getestet. Nach einem Kaltstart (Strom war weg und Batterie raus) dauert es so 4-5 Minuten bis zum ersten Fix, diese Zeit hängt nicht von der Verwendung der Batterie ab. Dass der EPE dann nach und nach geringer wird ist denke ich normal, das Modul wird sich über die Zeit sicherer darüber wo es genau ist. Wenn ich dann den Aufbau vom Strom trennen (Batterie aber drin lasse) einen Moment warte und dann wieder anschließe dauert es 2-3 Sekunden bis zum Fix. Dabei liegt das Bricklet aber auch direkt an einem Fenster mit Blick auf eine Wiese. Wenn ich es jetzt ca. 1m weit vom Fenster weg lege vor meine Tastatur, dann dauert es schon 9-10 Sekunden bis zum Fix. Und ich habe auch gerade kurzzeitig den Fix verloren, als ich beim Tippen das Bricklet mit meinen Armen abgedeckt hatte. Ich denke, dass es also durchaus normal ist wenn es 10 Sekunden dauert, je nachdem was da so den GPS Empfang in deiner Umgebung stört.

Wenn das GPS Bricklet einen Fix hat und du es dann vom Strom trennst, dann stützt die Batterie die interne Datenhaltung des Moduls über Satelliten in View und die aktuelle Uhrzeit. Ohne Batterie gehen diese Daten verloren, wenn das Bricklet nicht mehr vom Brick mit Strom versorgt wird. Wenn dann wieder Strom angeschlossen wird dauert es bis zum neuen Fix typischerweise nur ein paar Sekunden, wenn eine Batterie zur Datenhaltung eingelegt ist. 10sec ist da eigentlich schon lange. Im Test hier waren das eher so 2-3sec, wobei das GPS Modul durchschnittlich 10 Satelliten in View hatte und am Fenster lag. Der erste Fix, wenn das Modul noch keine Satelliten in View hat kann länger dauern, zwischen 30sec und ein paar Minuten je nach Sicht.

Tun wir eigentlich nicht. Das muss wohl so durch unsere Qualitätskontrolle gerutscht sein, sorry

Funktioniert der Master Brick ohne GPS Bricklet? Hast du Master Brick und GPS Bricklet neu geflashed? Falls das GPS Bricklet nicht geflashed ist, dann er klärt das diesen Effekt. In diesem Fall erst den Master an USB anschließen und dann erst das Bricklet, so kannst du es wieder flashen. Und nein, der Master bootet natürlich auch schon bevor das GPS Bricklet eine Positionsbestimmung hat.

http://download.tinkerforge.com/tools/brickv/macos/brickv_macos_1_1_16.dmg http://download.tinkerforge.com/tools/brickv/macos/brickv_macos_1_1_17.dmg

Äh, ja wir haben da etwas Ärger mit der MacPorts Installation auf unserem MacBook und da ist wohl eine zu neu Qt Library eingerutscht. Du könntest mal Brick Viewer 1.1.16 testen, diese Version sollte nicht betroffen sein. Bei 1.1.17 bin ich mir nicht sicher.