rtrbt

Moin, Wenn du den Stick angeschlossen hast, tauchen die ganzen USB-Resets auf. Du kannst mit lsusb (poste mal die Ausgabe davon) mal nachprüfen ob das wirklich der Stick ist, Bus 0X Device 01 sollte der entsprechende Hub-Chip sein, Bus 0X Device 0Y dann der Stick. In den Resetmeldungen siehst du dann "usb X-1:" das ist der Hub und dahinter "USB device number Y", die sollte der aus lsusb entsprechen. Da die Resets vermutlich an den Stick geschickt werden: Wie ist dein Aufbau insgesamt? Wie versorgst du ihn mit Strom? Welche Image-Version hast du auf dem RED-Brick? Vermutlich ist das (noch) kein Treiberproblem, da das USB-Device ansich ja nicht korrekt auftaucht. Der Treiber würde erst im nächsten Schritt geladen werden.

Moin, Interessant wären die Ausgaben von lsusb und dmesg. Da gerade dmesg auf der seriellen Konsole des RED-Bricks sehr unübersichtlich ist, kannst du die Ausgabe mit dmesg | tail -n 30 filtern.

Die Selbsterwärmung des Sensors kann mit der Funktion set_temperature_offset kompensiert werden.

As there is a brickv folder in /usr/share, did you install the Brick Viewer Debian package or from source? The Debian package typically is installed to /usr/share/brickv. To start the Brick Viewer, you can run brickv from the terminal instead of calling main.py directly. The error message indicates, that Qt can not reach the X server. Are you running your graphical interface as root or as another user? If so, Brick Viewer should work if you run it as the "normal" user.

Moin, das ist vermutlich auf einen Bug im Brick Viewer zurückzuführen, der mit Version 2.4.5 gefixt wurde. /etc/localtime ist ein Symlink auf die gewünschte Zeitzone in /usr/share/zoneinfo/. Vor Version 2.4.5 hat der Brick Viewer aber localtime auf nicht vorhandene Dateien gelinkt, C# gibt dann die FileNotFoundException aus. Wenn du mit dem aktuellen Brick Viewer die Zeitzone des RED-Brick neu setzt, sollte das Problem behoben sein. Um die Zeit des RED-Bricks zu setzen kannst du date auf der Kommandozeile oder mit System.Diagnostics.Process verwenden. Zum Beispiel mit date +%s -u -s @1565681174 (als Unix-Timestamp, so macht es der Brick Viewer) oder mit date -s "13 AUG 2019 09:25:30"

War doch einfacher als gedacht. Habe dir die gefixte Version mal angehangen, bei mir gibt g++ 9.1 die Warnung nicht mehr aus. tinkerforge_c_bindings_2_1_25.zip

Versuch es mal ohne die () hinter cb_enumerate und cb_connected.

Moin, Ich bin dem mal nachgegangen, das Problem ist nicht das Alignment innerhalb der Strukturen, sondern das der Strukturen selbst (also Packet, PacketHeader und den konkreten wie z.B. SpectrumLowLevel_Callback). Da sie als packed markiert sind, geht der Compiler (richtigerweise) davon aus, das sie nicht auf 4 Byte alignt sind und gibt die Warnung aus. Abgesehen davon gibt es tatsächlich Fälle, in denen die Paketstruktur so ist, dass Arrays an "krummen" Adressen liegen, z.B. beim RS232 Bricklet. Das sauber für alle Compiler zu fixen dauert noch etwas, falls du auf x86 oder einer anderen Architektur, die unalignte Zugriffe unterstützt, unterwegs bist, kannst du die Warnung erstmal mit -Wno-address-of-packed-member unterdrücken. Ich melde mich sobald ich das repariert habe.

Prinzipiell funktioniert das, hängt aber natürlich auch von deinem Handy ab. Im Settings-Network-Tab des Brick Viewers taucht es als Wired-Interface usb0 auf.

Moin, Habe ich mal implementiert, kommt mit 2.4.7. Du kannst dann im Flashing-Window auf den Brick Viewer klicken, dann wird je nach Plattform das richtige Paket heruntergeladen. Hm das ist kaputt. Habe ich mal gefixt, kommt auch in der 2.4.7. Erik

Die set_sleep_mode-Funktion fährt den Raspberry nicht von alleine heruntergefahren, sondern sagt nur dem HAT, dass der Strom weggenommen werden muss. Das Runterfahren (z.B. wie du es geschrieben hast mit shutdown) musst du selber machen. PS: Mir ist gerade aufgefallen, dass in den Beispielen die Zeit in Millisekunden mitgegeben wird. Das müssen aber wie dokumentiert Sekunden sein. Habe ich gerade gefixt, sollte in ein paar Minuten aktualisiert werden.

Moin, Versuch es mal mit dieser Version. Ich habe das Zeitzonenhandling insgesamt überarbeitet, jetzt sollten auch echte Zeitzonen (anstatt von UTC-Offsets) angezeigt und gespeichert werden. Erik

Not supported in this case means "works in some cases, but not in enough to support it.": The firmware of bricklets with co-processor sends an enumerate when booting and bricks poll their ports with an exponentional decreasing rate, which in conjunction allows hot plugging. But bricks are not able to tell if a bricklet gets disconnected. So if your use case only requires adding co-processor bricklets and never removing them, you could reasonably expect this to work, but as I've said it is not supported.

You mean threads spawned in the enumerate callback to handle callbacks of the found devices? If you use the thread::spawn(move || { for x in receiver { //[...] } } pattern, then the thread will join, when the corresponding sender is dropped in the IpConnection, e.g. when the IpConnection is dropped. Another way would be to explicitly drop the receiver, but then you can not use the for loop pattern anymore. Dropping the bricklet does not close callback channels. Instead you have to either drop the IpConnection or the receiver. The device object does not hold any information abount the callback channels. Unfortunately, hot plugging devices to already powered stacks is not supported (for electrical reasons as well as in software). The EnumerationType::Disconnected is only sent, if the Brick Daemon on a PC notices that the USB connection to a stack is lost.

Moin, Bei manchen Karten wird angegeben, wie viele Daten geschrieben werden können. Wenn du da auf Nummer sicher gehen willst, kaufst du eine für den industriellen Einsatz geeignete Karte, die haben dann Datenblätter wie dieses hier (keine Werbung, das war das erstbeste Suchergebnis) Die Karte hält laut Datenblatt 600TB aus (unter Terabytes Written (Max.)). D.h. du kannst zwei Jahre lang pro Minute mehrere Hundert Megabyte schreiben, falls meine Schätzung stimmt. Du kannst natürlich immer Pech haben und eine Karte erwischen, die nach zwei Monaten hin ist, aber das Risiko hat man ja immer. Erik

Hi, You've found a design mistake in the bindings. The IpConnectionRequestSender has the purpose to allow multi-threaded calling of IpConnection functions and device creation, but for some reason I've forgot to accept the RequestSender in the [device]::new functions. The attached version (which will probably be released as 2.0.11 soon) fixes this. With this version everything you can do with an IpConnection should also be possible with the RequestSender, that can be cloned for as many threads as needed. Also attached is an example, that shows how to use the RequestSender in an enumerate callback handler. To use the local version of the bindings, extract the src folder and Cargo.toml into a tinkerforge folder inside your project's src folder, remove the tinkerforge=... line in your Cargo.toml and add [dependencies.tinkerforge] path = "src/tinkerforge" instead. Erik tinkerforge_rust_bindings_2_0_11.zip rust_ipcon_fix_example.zip

Vermutlich ist die Netzwerkfirewall da zu aggressiv: Die Requests die der Brick Viewer sendet, sehen nicht aus, als kämen sie von einem Browser. Deshalb werden die wohl blockiert. Als work-around kannst du die Firmwares von Hand runterladen und im Flashing-Fenster per Custom flashen.

Moin, Sieh mal nach, ob die Firewall von Windows den Brick Viewer blockiert hat. heißt, du kommst mit einem Browser auf http://download.tinkerforge.com/ ? Erik

Wenn ich nochmal darüber nachdenke: Das Verhalten, was du siehst, ließe sich erklären, wenn du bei beiden Beispielen statt der UID des jeweiligen Bricklets die des Master Bricks eingetragen hast.

Moin, hast du daran gedacht, die UIDs in den Beispielen zu ändern? Das übersieht man gerne. Die Logs kannst du mal anhängen, eventuell findet sich da ja was. Erik

Suspend kann zwar der Linux-Kernel, aber auf dem RED-Brick funktioniert er hardwareseitig nicht. Du könntest dir mit einem per USB angeschlossenen Master-Brick und einem Relay-Bricklet etwas basteln, das hat aber folgende Nachteile: Das Timing wird sehr ungenau (im Bereich von einer Minute pro Stunde, das hängt vom Quartz auf dem Master Brick ab). Der Master Brick braucht eine Stromversorgung, da brauchst du entweder eine Step-Down-Power-Supply oder musst dir ein USB-Kabel zurecht bauen. Der RED-Brick würde sich selbst die Stromversorgung (sofort) wegnehmen, also kann das Linux nicht sauber herunterfahren. Hängt also von deinem Einsatzzweck ab, ob das sinnvoll ist. Bei den Relaymodulen von Amazon musst du mal sehen, ob du mit dem Timing hinkommst. Das erste scheint auf maximal 999 Minuten (16 Stunden 39 Minuten) konfigurierbar zu sein.

Das b steht für Byte. Dass der Payload an der Stelle des Codes noch (nicht dekodierte) Bytes sind, ist ein Bug in den Bindings. Ich habe mal eine Version mit Bugfix angehangen. Du kannst mosquitto_pub mit -s beliebige Dinge auf der Standardeingabe füttern, die Bindings verstehen aber nur UTF-8 kodiertes JSON. Das sollte auch an dem Bug in den Bindings liegen. tinkerforge_mqtt

Moin, Das scheint ein seltsames Problem zu sein. Wenn ich die Befehle copy-paste und die UID anpasse, funktioniert es bei mir. Du kannst mal versuchen, die Bindings mit --debug --show-payload starten. Dann sollte in der Fehlermeldung die du bekommst hinten der Payload stehen, wie ihn die Bindings empfangen haben. Erik

Habe dir nochmal eine neue Firmware angehangen, da war noch ein Rundungsfehler in dem Fall den du getroffen hattest, der u.U. dazu führt, dass doch zwei Callbacks (das erste eins größer als das zweite) zugestellt werden. Die angehangene Firmware ist identisch zur offiziellen 2.0.3. rotary-poti-bricklet.bin

Moin, Dass nur UID (und enumeration type) gültig sind, liegt daran, dass der Brick Daemon nur diese Werte zwischenspeichert, um sie mit dem Callback rauszugeben. Das ist absichtlich so, da es Fälle gibt, wo nicht mehr Informationen verfügbar sind. Das war in der Firmware kaputt. Das Problem ist, dass dein Programm, weil in C, so schnell ist, dass das Callback schon registriert und aktiviert ist, wenn der erste Wert abgefragt wird. Weil die Firmware da die Reihenfolge falsch hatte, wurde erst der (geglättete) Positionswert aus nicht vorhandenen Daten berechnet und danach der erste echte Wert vom Poti gelesen. Teste mal bitte die angehangene Firmware, die löst das Problem bei mir. Erik rotary-poti-bricklet.bin