photron

You need to install brickd on your Windows 10 IoT device. Then you can use the C# API bindings and the examples as you would with any other installation of brickd to talk to the devices connected over USB to the Windows 10 IoT device. There is currently a limitation that you cannot run brickd and your C# app on the same Windows 10 IoT device. Microsoft doesn't allow for two apps on the same device to talk to each other over localhost. You'll need to run you C# app on a different device for now. I've a solution for this problem in mind, but haven't implemented it yet.

Oh, I didn't notice that recent Mono picks up those project.json files as well. They are only meant for Visual Studio. You can just delete them on Linux for now. I'll look into a correct solution for this problem. Thanks for the report.

Unfortunately the disconnected callback doesn't work as good as it could in case you disconnect the Ethernet cable or cut the power to the stack. We'll improve this soon by adding a heartbeat mechanism to the API bindings. Regarding test 2b: The connect() call of the IP Connection is blocking. It'll fail with an Exception if it cannot connect. You can catch the exception and retry the call. Maybe we could add a async version of the connect() call, that would not block. I'll at that to my list of things to investigate, but I can't promise anything yet.

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