cl-

Sieht gut aus. Besten Dank!

Besten Dank! Kann ich erst morgen früh testen. Melde mich

Die gestern veröffentlichte Firmware V2.0.3 des Industrial Dual Analog In Bricklet 2.0 verhält sich komisch im Brick Viewer Version 2.4.9. Wenn die Anschlüsse offen sind (also keine Kabel außer dem Bricklet Kabel angeschlossen) liegt der Pegel bei 0V. Wenn man jetzt die Sampling Rate verstellt (unterhalb der 122 Hz), springt der Pegel im Plot runter auf unter -20V (siehe Screenshot). Ab 244 Hz Sampling Rate geht es wieder zurück auf 0V. Das ist womöglich den Änderungen der neuen Firmware entsprechend (MCLK divisor depending on oscillator).

Hallo zusammen, ich habe Probleme mit dem Industrial Dual Analog In Bricklet 2.0 Bricklet. Mit einem Funktionsgenerator habe ich ein 0.3 Hz Sinus erzeugt (zwischen -1V und +1V), mittels analogem Scope entsprechendes Signal kontrolliert und dabei keinerlei Auffälligkeiten entdecken können (hätte ja durchaus sein können, dass der Versatz schon in der Signalquelle war). Im Brick Viewer bekomme ich immer wieder einen horizontalen Versatz im Signal (siehe Screenshot). Ich habe Software-Updates eingespielt, die Bricklet Firmware erneut geflasht, konnte aber so keine Verbesserung erzwingen. Ich sehe hierbei drei mögliche Fehlerquellen: [*]Hardwarefehler (Bricklet): Macht der ADC alle x ms Pause? Gehen bei der Kommunikation Daten verloren? [*]Softwarefehler (Brick Viewer): Kann es sein, dass die GUI irgendwas verschluckt? Für mich sieht das nach einem horizontalen Versatz aus, einem Sprung der Kurve nach links und rechts. [*]Hardwarefehler (Grafikkarte): Ist das ein OpenGL Bug (macOS)? Kann das jemand mal bei sich testen? Besten Dank!

Ja, damit ist der Fehler weg! Danke

Komisch. Was ändert sich an der SSL Kommunikation, nachdem man das Python Script zu einem Package zusammenbaut? Es basierte ja auf der gleichen Code Basis?! Kann es sein, dass beim Build eine andere Python Version benutzt wird für diese Funktionalität? Ich habe drei Python Versionen installiert, die Default 2.7, die mit macOS mitgeliefert wird und die aktuellen 2.7.16/3.7.4 mittels Homebrew. Brick Viewer startet bei mir nur mit der 3.7er Version.

Danke für die Integration der genannten Funktionen in die neue Firmware.

Die Fehlermeldung kommt immer, egal wie oft ich die Fehlermeldung bestätige und/oder auf den "Search for Updates" Button klicke. Auch nach einem Neustart des Brick Viewers ändert sich daran nichts. Das Problem tritt nicht in der Windows Version auf (gleiches Netzwerk).

Es ist unverändert (habe auch noch mal zur Sicherheit ein neues Brick Viewer Image aus eurer Downloads Sektion geladen, solltet ihr das in der Zwischenzeit aktualisiert haben).

Hallo zusammen! Die neue Brick Viewer Version 2.4.7 hat Probleme bei mir, sich mit dem Internet zu verbinden. Das von euch erzeugte Build verhält sich hierbei anders als die Version, die man im entsprechenden Ordner per Python aufruft (GitHub Source Code, letzter Pull vor einer Stunde). Anbei ein Screenshot. Rechts euer Build, links der Aufruf mittels Python (dark mode). Beide wurden zeitgleich am gleichen Computer aufgerufen. Nur das Build gibt die Fehlermeldung. Vielen Dank für das Update!

Besten Dank! Ich selber nutze eure C++, Rust und MATLAB bindings. Bedarf bestünde bei mir momentan primär mit Rust und MATLAB. Cheers, Claudio

Is this topic solved or documented? I'm struggling with exactly this. How do I get the data from the callback function back to the main function in MATLAB? I like to write all accelerations into an array while the callback function is active. After the sensors stopped sending data, I like to run some statistics on the entire data stream. % Register 16-bit continuous acceleration callback to function cb_continuous_acceleration set(a, 'ContinuousAcceleration16BitCallback', @(h, e) cb_continuous_acceleration(e)); Within the callback, I can get access to the sensor data using the "e" object. However, how do I get the data back to the main function?

Brilliant! Thanks a lot for the quick response and solution! I tried the changes and the performance increased immediately.

First of all, I love the HAT Brick! Thanks! I have a general question related to its performance: Do you know whether there are technical limits on how much data I can get through the GPIO of the Raspberry Pi? I'm using the new Version 4 Raspberry Pi (2 GB RAM) and the HAT Brick. I tried to get the full rate of 25.6kHz out of an Accelerometer V2 bricklet, but it wasn't possible. It seems strange to me, as the Master Brick has no problems at all (at least when connecting only one Accelerometer V2 with continuous acceleration callback). I know about the technical limits for more than one Accelerometer V2 bricklet. When compared to the Master Brick, however, the data throughput with the HAT brick seems to be much lower. I was expecting it to be the other way around (as there isn't a USB connection anymore that limits the number of messages per second). Is there a technical reason why the HAT Brick doesn't get the (at least equal) amount of data through the system that is needed for the Accelerometer V2 bricklets? How does Debian (or Brick Daemon on the Pi) read the GPIO? I'm guessing it iterates over the SPI pins one by one? For comparison: I connected a Master Brick to the Raspberry Pi and it gave me the expected "Master Brick" like performance I was used to in the past. Thanks for your support! EDIT 1: I'm using your Rust API bindings. EDIT 2: Does it have to do with the maximal SPI clock of 1400000? // On RPi 3 make sure to set "core_freq=250" in /boot/config.txt. // The SPI clock is scaled with the variable core_freq otherwise // and the SPI clock is not stable... #define BRICKLET_STACK_SPI_CONFIG_MAX_SPEED_HZ 1400000

Das würde mich auch sehr interessieren. In der Firmware habe ich nicht gefunden, aber wo die beiden Bits 7 und 6 für IIR_BYPASS (filter bypass mode) und LPRO (low-pass filter roll off control) gesetzt (oder nicht gesetzt) werden.

Thanks for this clear and detailed answer! I'll go ahead with the "same bricklet kind and same UID" approach to implement the behaviour I was aiming for. Cheers

Thanks for the fix! It works for me.

Good morning! I updated brick daemon to 2.4.0 on macOS (10.14.5) today. Brick Viewer works as expected and it shows connected devices. However, when checking the version (brickd --version), it fails with the following error message: dyld: Library not loaded: @executable_path/libusb-1.0.dylib Referenced from: /usr/local/libexec/brickd.app/Contents/MacOS/./brickd Reason: Incompatible library version: brickd requires version 3.0.0 or later, but libusb-1.0.dylib provides version 2.0.0 Abort trap: 6 Temporary solution: I have libusb installed via homebrew. I can't uninstall it though, as it has dependencies (dfu-util for instance). When temporarily renaming libusb-1.0.dylib (inside /usr/local/Cellar/libusb/1.0.22/lib/), brick daemon does load its own libusb version again. Cheers, Claudio

Thanks again! I fully understand your warning that hot plugging might damage the electronics. What I noticed just today is that you even display a message in Brick Viewer in the bottom left corner saying "Hot plugging is not supported! Please reset ...". This small message can easily be overseen though. Maybe it's worth to display this message in a new window with bigger font size. Just another quick question regarding your note. Would it help to use Isolator bricklets between the master brick and my Accelerometer V2 bricklets? Could it make the unsafe hot plugging of co-processor bricklets a little less unsafe with an isolated bricklet? Although there is an "Open Bricklet" button in Brick Viewer (plugins folder, isolator.py, line 72), the API doesn't give a hint on its ability to manually control the isolator state. Does the term "Open" in this case indicate that the port is open and power/data is connected? My use case would be to check whether a co-processor bricklet got replaced by another one of the same kind (using the very same uid and brick position). The hardware replacement would only happen in case the bricklet got damaged. Say, the software wouldn't get connection to the bricklet anymore, even after re-establishing the IP connection to the brick daemon and resetting the master brick. In that case, I would just replace the bricklet and - in best case - wouldn't have to disconnect the RED and master brick from power supply. What one could additionally do is to reset the master brick after the replacement and reopen the IP connection to go back to its default state. Thanks for your support!

Thanks for clarification! Brick Viewer creates new tabs with data plots, after you connect bricklets to the powered brick. At least it does it for coprocessor-based bricklets (Accelerometer V2 in my case). It doesn't remove tabs from the GUI for previously connected bricklets though (they just stay there and won't update). Is that what you mean with "hot plugging devices to already powered stacks is not supported"? At least your software supports adding new devices while in operation. Bricklets without a co-processor won't automatically show up in Brick Viewer while in operation (I tried with some older bricklets).

Hi Erik, thanks a lot. I tried your fix and it works nicely. Another question came up when using the new version: What happens with the thread (that was spawned from within the enumerate callback function), when the bricklet cable gets disconnected? One could check for EnumerationType::Disconnected and do some manual clean up work (that's not the problem). But how do I make sure, that the spawned thread (related to the previously connected bricklet) will be joined? Is manual clean up required? In cases without using the enumerate callback function, I guess the spawned thread joins automatically when the callback_receiver object (ConvertingCallbackReceiver) is dropped, which in turn happens after the bricklet object goes out of scope? How will the binding handle the "enumerate callback function" case? Will the callback_receiver object be dropped automatically after the cable is disconnected? Or do I have to store the JoinHandle so I can do the manual clean up inside the "EnumerationType::Disconnected" condition? Background for my question: I'm trying to develop Rust code that properly responds to changed hardware components while running, so one could achieve Hot Plugging support. Thanks again for your great work. I really appreciate it! Cheers, Claudio

Hi all, After years of using the C++ API bindings for my projects, I gave Rust a try some weeks ago. Your API for Rust is just great! Thanks a lot for this! I've ported all of my projects, but I'm missing one last thing: What's the best way to implement the brick and bricklet configurations in the enumeration callback (as described in your rugged approach)? To be able to create bricklet objects, for instance, access to the IpConnection is required. One could use an atomic reference pointer to be able to clone the IP connection as an input for the spawned enumerate callback receiver (to avoid Rusts' "lifetime conflicts"). However, at least at the moment, that doesn't play well with some of my other struct implementations and rustc doesn't like it. It's not unlikely that I'm doing something wrong, given that I started working with Rust only three weeks ago. I'm a very experienced C/C++ developer, but the way Rust does some things is really different! As a starting point, I've used your authenticate example (https://raw.githubusercontent.com/Tinkerforge/generators/master/rust/example_authenticate.rs). In your example in line 8, you used an IpConnectionRequestSender as input for the authenticate callback function. I'm looking for something similar for the enumeration callback. Unfortunately, I can't figure out a good way that is both elegant and thread-safe. How can I get thread-safe access to the IpConnection object in my spawned enumeration callback? Has someone found a good way to do it? I would appreciate any suggestions. Cheers!