photron

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

Hmmh, bei der Implementation ist mir aufgefallen, dass ich schon vor dem ersten Fix Koordinaten (GetCoordinates) bekomme, allerdings wird das m.E. nicht im Viewer dargestellt. Der zeigt zu Beginn nur die Uhrzeit, aber keine Koordinaten.

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 habe ans Bricklet extern eine typische GPS-Antenne angeschlossen, die Knopfzelle ist permanent an der Platine. Antenne hängt aus dem Fenster Richtung Süden ohne Hindernisse, so bleibt das Bricklet testweise erstmal trocken . Sat.Viewed: 10-12; Used:6-8; Epe:1,4-2,5m (aber erst nach ein paar Min.)

Ein Kaltstart (nach PC hochfahren, Stack connectieren etc.) von App.start bis ersten Fix komme ich nie auf 2-3.

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.

Warum liefert ihr ungeflashte bricklets aus ?

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.

brickd v2 beta3 für Mac OS X kommt jetzt wieder mit der passenden libusb. Unter Windows schreibt brickd jetzt Warnings und Errors ins Event Log.

Das steht noch auf der TODO Liste. IIRC hatte ich mich damals davon überzeugt, dass es zur Unicodebehandlung unter Delphi und Free Pascal nichts Einheitliches gab. Hab' da gerade noch mal gegooglet und UnicodeString (was es aber wohl erst ab Delphi 2009 gibt) und WideString gefunden. Keine Ahnung warum ich mich damals vom Gegenteil überzeugt hatte. Damit ist das auf der TODO Liste nach oben gerückt.

Dyld Error Message:

  Library not loaded: @executable_path/libusb-1.0.0.dylib

  Referenced from: /usr/libexec/brickd.app/Contents/MacOS/brickd

  Reason: Incompatible library version: brickd requires version 2.0.0 or later, but libusb-1.0.0.dylib provides version 1.0.0

Das da steht brickd würde libusb 2.0.0 benötigen verwundert mich, es gibt keine libusb 2.0.0.

Hier ist ein weiterer Beta-Tester ...

Was auch noch dringend fehlt ist ein "Wie porte ich meinen Code vom alten auf das neue Protokoll"-Tutorial. Ich denke, dass ich dies vor Weihnachten noch verfasse.

Müssen bei der Migration auf das neue Protokoll im eigenen Code Anpassungen vorgenommen werden ?

Ja. Das betrifft hauptsächlich die IPConnection und die Signatur von Callbacks. Vergleiche v1 mit v2 des Temperature Bricklet Callback Beispiels.

Wo liegt unter Win das Log-File des BrickD-Treibers ? Lässt sich der Log-Level einstellen ? Bzw. ist das nötig ?

Standardmässig schreibt brickd unter Windows kein Logfile, sondern wird Errors und Warnings ins Event Log schreiben. "wird" weil die aktuelle Beta das noch nicht tut. Wird brickd allerdings mit --debug Option gestartet dann schreibt er ein Logfile mit vollem Debug Level in eine brickd.log Datei ins gleiche Verzeichnis in der auch brickd.exe liegt.

Um brickd mit --debug Option zu starten muss er über die Computerverwaltung beendet, als Startparameter --debug angegeben und wieder gestartete werden.

Es wird dann auch noch die Möglichkeit geben, das Logging genauer über eine Konfigurationsdatei einzustellen. Im Moment kann das nur über die --debug Option gesteuert werden.

Also ich konnte den Fehler wieder beobachten. Das ganze passiert wenn mein Programm läuft und man den Master per Reset neustartet. Dann geht die CPU-Last hoch und das Log wird innerhalb von Sekunden extrem groß(1GB).

 

Ich benutze die Java Bindings mit Callbacks (Temperatur)

Plattform ist 64 Bit

 

Hier mal das LOG

2012-12-22 16:33:18.958975 <I> <main_linux.c:275> Brick Daemon 2.0.0 started (daemonized)
2012-12-22 16:33:19.193359 <I> <usb.c:137> Added USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:34:14.630459 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:35:20.991206 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:27.535909 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:35:36.839606 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:35:39.685049 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:35:44.676683 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:35:48.520440 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:36:02.533402 <I> <client.c:61> Socket (handle: 18) disconnected by client
2012-12-22 16:36:03.983742 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:36:09.237350 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:36:14.174956 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:36:18.364469 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:36:59.951934 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:37:02.877460 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:37:10.114530 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:37:15.943577 <I> <network.c:87> Added new client (socket: 17)
2012-12-22 16:37:49.366481 <I> <network.c:87> Added new client (socket: 18)
2012-12-22 16:38:25.558476 <I> <client.c:61> Socket (handle: 17) disconnected by client
2012-12-22 16:38:27.828234 <I> <client.c:61> Socket (handle: 16) disconnected by client
2012-12-22 16:39:14.282072 <I> <network.c:87> Added new client (socket: 16)
2012-12-22 16:39:20.523027 <W> <transfer.c:60> Read transfer 0x18d9d40 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523162 <W> <transfer.c:60> Read transfer 0x18d9db8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523524 <W> <transfer.c:60> Read transfer 0x18d9e30 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.523737 <W> <transfer.c:60> Read transfer 0x18d9c50 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.524057 <W> <transfer.c:60> Read transfer 0x18d9cc8 returned with an error from Master Brick [67N4R3]: LIBUSB_TRANSFER_STALL (4)
2012-12-22 16:39:20.565888 <I> <usb.c:262> Removing USB device (bus: 2, device: 6) at index 0: Master Brick [67N4R3]
2012-12-22 16:39:20.569079 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569109 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569129 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569139 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569152 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569161 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569172 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569182 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569194 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569203 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569214 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569223 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569234 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569244 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569270 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569279 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569290 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)
2012-12-22 16:39:20.569298 <E> <network.c:186> Client (socket: 0) not found in client array
2012-12-22 16:39:20.569308 <E> <client.c:52> Could not receive from socket (handle: 0), disconnecting it: ENOTSOCK (88)

Das Log reicht mir schon, kein weiteres mit LOG_LEVEL_DEBUG bzw --debug nötig.

Das Problem tritt nur auf, wenn mehreren Clients gleichzeitig eine Verbindung zu brickd haben. Dabei kann es passieren, dass die Clients in einer anderen zeitlichen Reihenfolge die Verbindung trennen verglichen mit der Reihenfolge des Verbindungsaufbaus. Das passiert in deinem Fall. Warum dass gerade mit dem Reset des Master Bricks zusammen fällt ist mir nicht klar.

Dadurch kommt die Datenhaltung in brickd durcheinander. brickd fällt in eine Schleife in der er versucht einen Client aus der Liste der verbundenen Client zu entfernen, scheitert aber durch den Fehler in der Datenhaltung. Diesen Bug habe ich gerade behoben. Auf github findet sich jetzt die korrigierte Version.

Zum Testen hab ich ein Debian AMD64 Package angehängt. Um Windows und Mac OS X Installer neuzubauen habe ich gerade nicht die dafür eingerichteten PCs zur Hand.

brickd-2.0.0_eda6a29a188cd8ce667afa9cdabbdef47f75f27b_amd64.deb

Mac ist hier die wichtige Information. Brick Viewer 1.1.17 für Mac OS X kommt jetzt mit einer älteren Qt Version (4.7). Die neuere Qt Version (4. hat ein Problem, dass dazu führt, dass die Graphen nicht dargestellt werden. Mit Qt 4.7 tritt diese Problem nicht auf und die Graphen funktionieren.

Die UIDs sind Base58 enkodiert, eine "1" entspricht dezimal 0 und wenn der Brick eine 0 als UID vom Bricklet EEPROM liest kann er nicht unterscheiden, ob an dem Bricklet Port jetzt wirklich ein Bricklet mit UID 0 steckt oder kein Bricklet abgeschlossen ist. Denn wenn der Brick versucht ein nicht existentes Bricklet auszulesen bekommt er auch eine 0 als UID zurück. Daher nimmt der Brick an, dass an Ports wo er UID "1" liest kein Bricklet angeschlossen ist und daher taucht ein Bricklet mit UID "1" nicht im Brick Viewer auf.

Eigentlich liefern wir alle Bricklets mit einer voreingestellten UID ungleich "1" aus. Wie da bei dir eine "1" reingekommen ist ist mir unklar.

Brick Viewer 1.1.17

• Mitgeliefertes Qt Version auf 4.7 zurücksetzen um auf Mac OS X ein Problem mit der Darstellung von Graphen zu beheben
  

Downloads: Windows, Linux, Mac OS X