photron

Die Python Bindings im aktuellen RED Brick Image sind leider nicht auf dem aktuellsten Stand. Es wird demnächst eine Möglichkeit geben die Bindings über Brick Viewer zu aktualisieren. Bis das allerdings soweit ist, musst du selbst Hand anlegen. Entweder du lädst neben deinem Programm auch die aktuellen Bindings mit hoch, oder aktualisiert die installierten Bindings über die Console im Brick Viewer mit folgendem Befehl: sudo pip install --upgrade tinkerforge Dazu braucht der RED Brick allerdings Internetverbindung.

Du musst den Schlüssel eingeben, den du zuvor im Brick Viewer für den Access Point des RED Bricks angegeben hast.

Nein, momentan gibt es keine Lösung um zwei Stapel per Funk zu verbinden. Mit der WIFI Extension kannst du nur eine Verbindung zwischen Stapel und PC herstellen. Ich nehme mal an im festen Teil ist das Raspberry Pi über USB mit dem Master Brick verbunden: Stepper Brick -> Stepper Motor Master Brick -> Sensor Bricklets Step-Down Power Supply -> Raspberry Pi Und den beweglichen Teil willst du auch vom Raspberry Pi erreichen können: WIFI Extension Master Brick -> Sensor Bricklets Powerbank Eine Lösung ist es dem Raspberry Pi einen USB WLAN Stick zu spendieren, um darüber die Verbindung zur WIFI Extension herzustellen.

Brick Daemon Settings ist genau das richtige. Die Listen Address steht standardmäßig auf 0.0.0.0. Dass heißt, das brickd von überall aus Verbindungen annimmt. Wenn du die Listen Address auf 127.0.0.1 stellst, dann nimmt brickd nur noch Verbindungen von den auf dem RED Brick laufenden Programmen und USB an.

Hast du wie WIFI Extension 2.0 auch auf die aktuellste Version 2.1.1 aktualisiert?

Wie können das Problem hier mit aktueller Hardware und Software nicht nachstellen. Sprich, es funktioniert in unseren Tests so wie es soll. Welche Hardware Version der Ethernet Extension (1.0 oder 1.1) nutzt du? Welche RED Brick Image Version nutzen du? Hast du auf dem RED Brick irgendwelche Änderungen an Brick Viewer vorbei vorgenommen? Zum Beispiel das Linux System mit "apt-get upgrade" aktualisiert? Welche Brick Viewer Version nutzen du? Wie genau sieht deine statische IP Adresskonfiguration aus (IP, Subnet Mask, Gateway)?

Das betrifft nur Master Brick Hardware Version 2.0, dort aber mit allen Extensions.

Teste mal bitte die angehängte Version der Java Bindings. tinkerforge_java_bindings_2_1_11_24b91bf71eb0.zip

Schau mal hier: http://www.tinkerunity.org/forum/index.php/topic,3174.msg19663.html#msg19663

Es reicht wenn du den Access Point Modus aktivierst. Das funktioniert dann mit den Standardeinstellungen. Wir haben das gerade nochmal mit einem Windows 10 Laptop getestet. Hast du das mal mit einem anderen PC versucht? Hast du mal versucht den RED Brick neuzustarten?

Siehst du denn die prints die du in cb_state_changed() drin hast? Sprich wird cb_state_changed() aufgerufen. Vielleicht muss du da ein paar mehr prints einbauen um zusehen bis wohin der Code kommt.

Oh, die Tab-Reihenfolge ist mal wirklich durcheinander. Wird in der nächsten Version verbessert sein. Das andere tue ich mal auf die Nice-to-have Liste.

Brick Viewer benutzt Qt4. Da gibt es das Tool qtconfig bzw qtconfig-qt4 für. Damit kannst du IIRC auch global die Fontgröße für alle Qt4 Programme umstellen.

Also ich finde das jetzt nicht zuviel verlangt, dass der Nutzer den mentalen Brückenschlag machen muss, dass die Dokumentation über Features der WIFI Extension 2.0 auf der der Unterseite der WIFI Extension 2.0 zu finden ist

Ist denn in deiner sqlite Datenbank was drin? Sprich, ist das Problem, dass nichts in der sqlite Datenbank ist, oder dass das Konvertieren nach Excel nicht klappt?

Die Konfiguration der Extension ist in einem EEPROM auf der Extension gespeichert. Diese hat eine Versionsnummer und eine Checksumme. Ich habe übrigens nicht gesagt, dass die gespeicherte Konfiguration beschädigt wurde. Es gibt in der Extension die gespeicherte und die aktive Konfiguration. Der Bug den du gefunden hast lag so, dass beim Speichern der Konfiguration auch die aktive Konfiguration geändert wurde, was dann zum Problem geführt hat. Die gespeicherte Konfiguration war davon jedoch nicht beeinflusst. Es wurde nie falsche oder beschädigte Daten gespeichert. Daher ist nach dem Update auf 2.1.1 die Konfiguration auch noch da. Der Master Brick hat übrigens nichts mit der Konfiguration der Extension direkt zu tun. Auch betraf das Problem nicht den Master Brick. Daher war es nicht nötigt den Master Brick erneut auf 2.4.2 zu flashen. Die Konfiguration einer Extension kannst du durch erneutes Konfigurieren des Extension Typs über Brickv Viewer löschen.

Okay, Version 2.1.1 is raus. Teste bitte damit noch einmal.

Firmware: WIFI Extension 2.0 2.1.1 Configuration saving fixed. The Extension can be switched to Mesh mode even if Brick Viewer is connected over Wi-Fi to it. Download: WIFI Extension 2.0

Firmware: WIFI Extension 2.0 2.1.1 Speichern der Konfiguration korrigiert. Die Extension kann jetzt auch in den Mesh Mode versetzt werden, wenn Brick Viewer selbst über WLAN mit der Extension verbunden ist. Download: WIFI Extension 2.0

Stimmt, das Problem existiert. Wird in der nächsten Version der Bindings behoben sein.

Du kannst ohne Problem mehrere IMU Bricks gleichzeitig am gleich PC über verschiedene USB Anschlüsse anschließen. In der API werden die dann über ihre eindeutige UID auseinander gehalten. Edit: Stapeln macht kein Sinn, denn dann messen ja beide die gleiche Orientierung. Für's stapeln müsste auch unter die zwei IMUs dann noch ein Master Brick gesteckt werden und der dann per USB angeschlossen werden.

Ahh, ich denke jetzt habe ich das Problem verstanden. Sprich du bindest in dem Simulationsprogramm deine tinker.c Datei. Da du da aber nur eine C Datei angeben kannst, hast du aus den Tinkerforge API Bindings Dateien eine DLL erstellt namens dymosim.dll, die du dann mittels der Library={"dymosim"} Zeile einbindest. Diese ganzen Fehlermeldungen in deinem ersten Post, kommen vom Simulationsprogramm das versucht jetzt tinker.c zu kompilieren. Du selbst rufst gar nicht den Compiler auf. Sorry, ich hatte dein Problem total falsch verstanden. Teste mal bitte folgendes: Die angehängte Version der Bindings kommt jetzt mit einem Makefile mit dem man unter Windows mit MinGW eine tinkerforge.dll erstellen kann. Dazu musst du das ZIP entpacken und im source Ordner mingw32-make aufrufen. Der Einfachheit halber habe ich dir diese tinkerforge.dll auch mit angehängt, die du dann anstelle der dymosim.dll verwendest. Die Library={"dymosim"} Zeile änderst du dann zu Library={"tinkerforge"} und brauchst dann auch nur noch deine tinker.c Datei und die entsprechenden .h der Bindings. tinkerforge_c_bindings_2_1_13_mingw_makefile.zip tinkerforge.dll

Das Problem mit dem Speichern war, dass die Änderungen zwar gespeichert wurden Brick Viewer sie danach aber nicht mehr richtig zurücklesen konnte um sie zu verifizieren. Der eigentliche Bug ist, das beim Speichern der Konfiguration in der WIFI Extension 2.0 ein Teil der laufenden Konfiguration mitgeändert wurde und dadurch die WIFI Extension 2.0 in einen kaputten Zustand geraten ist. Ich nehme an du hast den Stack nach der Fehlermeldung ins Brick Viewer noch nicht neugestartet. Dann ist die WIFI Extension 2.0 noch in diesem kaputten Zustand. Dadurch kannst du dich zwar mit Brick Viewer verbinden, aber es tauchen dann keine Bricks und Bricklets auf. Sprich, wenn du den Stack jetzt neustartet, dann ist die WIFI Extension 2.0 korrekt im Mesh Modus. Sprich hier liegt kein weitere Bug vor, sondern, dass Brick Viewer sich zwar verbinden kann, dann aber nichts anzeigt, ist ein Nebeneffekt des ersten Bugs. Dieser Bug ist bereits behoben. Es gibt entweder morgen oder Montag eine korrigierte Firmware Version.

Okay, ich verstehe das Problem. Hast du denn mal getestet, das mit der compile.bat zu kompilieren, wie ich es beschrieben habe?

Das Problem mit dem Speichern der Konfiguration über WLAN ist gefunden und behoben.