photron

Du kannst die RS485 Extension nicht einfach so für deine Zwecke nutzen. Der Brick Daemon benutzt die um mit anderen Stapeln zu sprechen. Du muss dann zumindest die RS485 Extension über Brick Viewer auf None konfigurieren, damit brickd sie nicht nutzt. Erst dann kannst du /dev/ttyS0 nutzen, muss dann aber noch das Receiver Enable des RS485 Transceivers von Hand bedienen und auch vorher noch die GPIO Pins richtig muxen. Sprich, das ist alles nicht mal eben gemacht. Es wird demnächst ein RS485 Bricklet geben, dass wie das RS232 Bricklet funktioniert, aber mit RS485, statt RS232. Benutzt du das RS232 Bricklet in der nähe von anderen elektromagnetisch strahlenden Geräten? Ich frage, weil wir vor kurzem festgestellt haben, dass unter bestimmten Umständen die Reset Leitung des I2C-nach-UART ICs auf dem RS232 Bricklet anfällig für externe Störungen ist. Durch solche Störungen kann ein unerwartetes Reset ausgelöst werden. Das Bricklet kommt dadurch in einen falsch konfigurierten Zustand, der alle Problem mit den kaputt empfangenen und gesendeten Daten erklären kann. Wir haben das RS232 Bricklet überarbeitet und alle aktuell verkaufen RS232 Bricklets sind jetzt robuster gegen externe Störungen. Schick uns eine Mail an info@tinkerforge.com mit deiner Adresse, Bestellnummer oder ähnliches und wir schicken dir ein neues überarbeitetes RS232 Bricklet zu. Ich entschuldige mich dafür, dass dieses Problem mit dem RS232 Bricklet jetzt so lange bestanden hat

Das geht z.B. so: os.system('echo tf | sudo -S -p "" shutdown -h now')

Du nimmst aus dem Bindings Zip den tinkerforge Ordner aus dem source Ordner und lädst ihn zusammen mit deinem Programm hoch.

FlyingDoc, das kann ich nicht reproduzieren. Ich kann ohne Neustart des Aufbaus zwischen den Baudraten wechseln, ohne Problem. Ich kann auch auf dem Oszilloskop sehen, dass die Bitzeiten korrekt sind. Wie genau sieht dein Aufbau aus? Ich habe das hier mit zwei RS232 Bricklets mit aktueller Firmware 2.0.3 und Brick Viewer getestet.

Du rufst nur einmal "nr.requestTagID(BrickletNFCRFID.TAG_TYPE_TYPE2);" auf. Du musst innerhalb deiner stateChanged Methode am Ende wieder "nr.requestTagID(BrickletNFCRFID.TAG_TYPE_TYPE2);" aufrufen, wenn du mit dem Auslesen des Tags fertig bist. Das stößt dann die Suche nach dem nächsten Tag an. Schau dir auch mal das "Scan for Tags" Beispiel an: https://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_Java.html#scan-for-tags

Das ist in dem Sinne kein Bug, sondern vielleicht eine Unschönheit in der Benutzung. Das averaging Parameter hat Symbole für seine Werte (1, 4, 16, 64, ...). Zuerst wird geschaut ob die Eingabe einem Symbol entspricht, wenn nicht dann wird sie als Zahl interpretiert. In diesem Fall überschneiden sich die Symbole und die Zahlen leider bei 1 und 4. Teste das mal bitte so: tinkerforge --no-symbolic-input call voltage-current-bricklet UID set-configuration x 4 4

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.