borg

Inwiefern springen die Werte denn hin und her? Wenn du im Brick Viewer die 3D-Ansicht anmachst, springt diese auch hin und her?

Wenn du den Master Brick per USB anschließt, leuchtet dann die blaue LED?

I think i misunderstood your problem. I changed something to make sure that the first edge in the edge count is always counted. That has nothing to do with interrupts, there is no edge count interrupt. The normal "value changed interrupt" always uses both edges. Maybe it is a problem with the debounce time? What debounce time are you using?

It looks like the current state of the edge count was not set when the configuration was set. Can you test the attached firmware? bricklet_industrial_digital_in_4_firmware_v2_0_3_beta1.bin

Firmwares: Thermocouple Bricklet 2.0 2.0.1, RGB LED Button Bricklet 2.0.1, Industrial Digital In 4 Bricklet 2.0 2.0.1, NFC Bricklet 2.0.2, PTC Bricklet 2.0 2.0.1, Remote Switch Bricklet 2.0 2.0.2, LED Strip Bricklet 2.0 2.0.1, Temperature IR Bricklet 2.0 2.0.2, Solid State Relay Bricklet 2.0 2.0.1, Humidity Bricklet 2.0 2.0.2, Outdoor Weather Bricklet 2.0.1, IO-4 Bricklet 2.0 2.0.1, RS485 Bricklet 2.0.2, Particulate Matter Bricklet 2.0.1, Industrial Quad Relay Bricklet 2.0 2.0.1, GPS Bricklet 2.0 2.0.4, Real-Time Clock Bricklet 2.0 2.0.3, Motion Detector Bricklet 2.0 2.0.1, Analog In Bricklet 3.0 2.0.2, RGB LED Matrix Bricklet 2.0.1, CAN Bricklet 2.0 2.0.1, Sound Pressure Level Bricklet 2.0.2, Industrial Dual Relay Bricklet 2.0.1, Thermal Imaging Bricklet 2.0.2, Voltage/Current Bricklet 2.0 2.0.1, DMX Bricklet 2.0.1, RS232 Bricklet 2.0 2.0.1, Motorized Linear Poti Bricklet 2.0.3, Load Cell Bricklet 2.0 2.0.1, Industrial Counter Bricklet 2.0.1 Fix für Race Condition mit potentiellem Buffer Overflow (über bricklib2) Download: Thermocouple Bricklet 2.0, RGB LED Button Bricklet, Industrial Digital In 4 Bricklet 2.0, NFC Bricklet, PTC Bricklet 2.0, Remote Switch Bricklet 2.0, LED Strip Bricklet 2.0, Temperature IR Bricklet 2.0, Solid State Relay Bricklet 2.0, Humidity Bricklet 2.0, Outdoor Weather Bricklet, IO-4 Bricklet 2.0, RS485 Bricklet, Particulate Matter Bricklet, Industrial Quad Relay Bricklet 2.0, GPS Bricklet 2.0, Real-Time Clock Bricklet 2.0, Motion Detector Bricklet 2.0, Analog In Bricklet 3.0, RGB LED Matrix Bricklet, CAN Bricklet 2.0, Sound Pressure Level Bricklet, Industrial Dual Relay Bricklet, Thermal Imaging Bricklet, Voltage/Current Bricklet 2.0, DMX Bricklet, RS232 Bricklet 2.0, Motorized Linear Poti Bricklet, Load Cell Bricklet 2.0, Industrial Counter Bricklet

Firmwares: Thermocouple Bricklet 2.0 2.0.1, RGB LED Button Bricklet 2.0.1, Industrial Digital In 4 Bricklet 2.0 2.0.1, NFC Bricklet 2.0.2, PTC Bricklet 2.0 2.0.1, Remote Switch Bricklet 2.0 2.0.2, LED Strip Bricklet 2.0 2.0.1, Temperature IR Bricklet 2.0 2.0.2, Solid State Relay Bricklet 2.0 2.0.1, Humidity Bricklet 2.0 2.0.2, Outdoor Weather Bricklet 2.0.1, IO-4 Bricklet 2.0 2.0.1, RS485 Bricklet 2.0.2, Particulate Matter Bricklet 2.0.1, Industrial Quad Relay Bricklet 2.0 2.0.1, GPS Bricklet 2.0 2.0.4, Real-Time Clock Bricklet 2.0 2.0.3, Motion Detector Bricklet 2.0 2.0.1, Analog In Bricklet 3.0 2.0.2, RGB LED Matrix Bricklet 2.0.1, CAN Bricklet 2.0 2.0.1, Sound Pressure Level Bricklet 2.0.2, Industrial Dual Relay Bricklet 2.0.1, Thermal Imaging Bricklet 2.0.2, Voltage/Current Bricklet 2.0 2.0.1, DMX Bricklet 2.0.1, RS232 Bricklet 2.0 2.0.1, Motorized Linear Poti Bricklet 2.0.3, Load Cell Bricklet 2.0 2.0.1, Industrial Counter Bricklet 2.0.1 Fix race condition with potential buffer overflow (through bricklib2) Download: Thermocouple Bricklet 2.0, RGB LED Button Bricklet, Industrial Digital In 4 Bricklet 2.0, NFC Bricklet, PTC Bricklet 2.0, Remote Switch Bricklet 2.0, LED Strip Bricklet 2.0, Temperature IR Bricklet 2.0, Solid State Relay Bricklet 2.0, Humidity Bricklet 2.0, Outdoor Weather Bricklet, IO-4 Bricklet 2.0, RS485 Bricklet, Particulate Matter Bricklet, Industrial Quad Relay Bricklet 2.0, GPS Bricklet 2.0, Real-Time Clock Bricklet 2.0, Motion Detector Bricklet 2.0, Analog In Bricklet 3.0, RGB LED Matrix Bricklet, CAN Bricklet 2.0, Sound Pressure Level Bricklet, Industrial Dual Relay Bricklet, Thermal Imaging Bricklet, Voltage/Current Bricklet 2.0, DMX Bricklet, RS232 Bricklet 2.0, Motorized Linear Poti Bricklet, Load Cell Bricklet 2.0, Industrial Counter Bricklet

Ich kann das leider nicht reproduzieren. Hab alle möglichen Firmwares getestet, inklusive der aktuellen Master Brick Firmware 2.4.9 (mit Barometer Firmware 2.0.2). Hast du bereits überprüft ob vielleicht ein Pin im Bricklet Stecker krumm ist oder ähnliches?

Eine Kurze Erklärung des SPITFP (Tinkerforge Protocol over SPI) findest du hier: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c Der Payload der Pakete ist der gleiche wie bei TCP/IP, siehe hier: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Funktionen des Sound Pressure Level Bricklets im Protokoll gibt es hier: https://www.tinkerforge.com/de/doc/Software/Bricklets/SoundPressureLevel_Bricklet_TCPIP.html

Das ist leider nicht möglich. Bricks wissen nicht welche Bricklets angeschlossen sind. Die Daten werden lediglich zum PC weitergeleitet.

Das muss ich ausprobieren, es gibt auf jeden Fall keinen Grund dafür warum das nicht funktionieren sollte.

Das war im Prinzip meine Frage. In diesem Fall würde ich empfehlen ein Bricklet daraus zu machen. Die neuen Bricklets haben ja alle Co-Prozessoren und könnten entsprechend die Vorverarbeitung machen. Die Möglichkeit größere Datenmengen verarbeiten zu können war ein Grund des Umstiegs von EEPROMs auf Co-Prozessoren.

Die 1000 Nachrichten pro Sekunde kommen ursprünglich durch die USB-Kommunikation. Der USB-Host pollt 1000x pro Sekunde. Das ganze System ist allerdings darauf ausgelegt mit internen Ticks die 1x pro ms laufen etc. Die 64 Byte entsprichen der maximalen Payload-Größe unseres Protokolls: https://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Die WIFI Extension wird vermutlich keine 1000 Pakete pro Sekunde übertragen können, die Ethernet Extension schon eher.

Die maximale Datenmenge die du mit unserem System übertragen kannst ist 1000 Nachrichten pro Sekunde mit jeweils 64 Byte. Das gilt eigentlich sowohl für Bricklets als auch für Extensions. Kannst du die Daten denn direkt schon auf dem Brick/Bricklet irgendwie verarbeiten und dann weniger übertragen?

In your stack the Master Brick needs to be at the bottom and the Master Brick needs to be connected via USB. The Bricklets can be connected to any of the Bricks. If this doesn't work i have three ideas: 1. Is the firmware on all of the Bricks and Bricklets up-to-date? If not please update and try again. 2. Can you check if maybe on of the pins in the Bricklet connector of the Stepper Brick is bend? This could explain why there is no connection. 3. The Bricklets are not hotplug capable. So you have to connect them to the Bricks first and then connect the Brick via USB.

Habs gefunden, das "entpacken" von Bool-Arrays funktionierte nicht wenn das Array in ein einzelnes Byte passt. Hier ist der Fix: https://github.com/Tinkerforge/generators/commit/cd530f5c5fac87a5e6fcd450b3578734a91f1c09 Wird dann mit dem nächsten Bindings-Release gefixt. In der Zwischenzeit kannst du aber das diff im Link einfach schonmal auf deine IPConnection.php anwenden, sind nur 3 zusätzliche Zeilen.

Ich kann das reproduzieren, da ist ein Bug in den Bindings . Ich kümmere mich drum.

Schwer zu sagen was da jetzt genau der Flaschenhals ist. Grundsätzlich sind über USB 1000 Nachrichten pro Sekunde möglich. Darauf ist das System ursprünglich ausgelegt. Das hängt aber natürlich trotzdem vom Betriebssystem usw ab. Ein RPi schafft tendenziell über USB keine 1000 Nachrichten pro Sekunde (hängt aber auch wieder von der exakten Konfiguration usw ab). Ich würde mal ein bisschen rumprobieren (per USB direkt am PC, per USB am RPi, per Ethernet am PC, etc). Um zu sehen wo der Durchsatz am höchsten ist, da sieht man dann auch wo der Flaschenhals ist und kann dann dort versuchen zu optimieren.

You can find the Silent Stepper Brick code of the Brick Viewer here: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/silent_stepper/silent_stepper.py I don't know how many steps 0.1mm are in your application, it depends on the motor you use and so on.

Was heißt sind nicht vollständig? Sind die Daten in einem Paket kaputt oder werden die 3ms nicht erreicht? Um die Werte immer zu bekommen kannst du ein Threshold Callback nutzen und den Threshold einfach so setzen das er immer auslöst. Zum Durchsatz: Ist der Master Brick auf dem aktuellsten Stand? Was ist alles am Master Brick/Stapel angeschlossen? Was verwendet ihr zum auslesen (Raspberry Pi oder RED Brick oder PC)?

Die erste Idee die ich dazu hab: Die WIFI Extension hat nur eine begrenzte Anzahl von Sockets die geöffnet werden können. Kann es sein dass ein Programm neue IPConnections aufmacht ohne die alten zu schließen? Kann man die WIFI Extension wenn sie nicht mehr erreichbar ist noch pingen?

The governor will automatically scale between 432 MHz and 1 GHz depending on the load, so it should run with 1 GHz even if the governor is configured as "on demand". The idea was that maybe the scaling doesn't work properly with OpenHAB. I will put it on the todo list to test it again with the newest RED Brick image and OpenHAB version to see if it is so slow for us too. But it will be a few days until i can work on it.

With RED Brick image version 1.10 we updated the Linux kernel as well as OpenHAB to the newest version. Unfortunately the scheduling in the Linux kernel got less efficient for our single core processor (that is what you see with the 30% cpu time taken by brickd) and at the same time the new OpenHAB version is slower... That probably explains why everything is a bit slower, however it should work in principle and the site-map should show up etc. With the new image we also introduced support for the cpu-scaling governor. By default it is configured as "ondemand", which means that the cpu is scaled down to 432 MHz and only increased to the full 1GHz if necessary. You can change it to always use the full 1GHz with Does that help for your use case?

Oh, da gibt es ein Missverständnis. Das Bricklet selbst hat eine UID die du Ändern kannst. Die nutzt du wenn du das Objekt für das Bricklet erstellst. Die Wetterstationen selbst haben auch eine eindeutige ID (in diesem Fall eine zahl zwischen 0 und 255). Diese wird von der Wetterstation vergeben und kann leider nicht geändert werden. Da haben wir keinerlei Kontrolle drüber Du kannst in deinem Programm die IDs per get_station_identifiers() anfragen und daraus dynamisch die ID nutzen zur Verfügung stehende ID nutzen. Wenn in deiner Umgebung mehrere Wetterstationen musst du leider einmal händisch die korrekte neu hinzugekommene ID auswählen.

The 1-Wire Bricklet is on the next production panel. It will be released in 2-3 weeks.

Die Standardeinstellungen sind eigentlich schon OK. Wie schnell dreht denn der Motor wenn er aufhört zu laufen? Du könntest noch einmal "Interpolate" ausstellen damit er auch wirklich Vollschritte macht und im Zweifelsfall die "Thresholds" alle auf 0 setzen damit er nicht den Stealth-Modus verwendet. Ansonsten ist es wenn hohe Geschwindigkeiten/Drehmomente erreicht werden sollen immer vom Vorteil eine möglichst hohe Spannung zu nutzen. Wenn du die Möglichkeit hast könntest du also auch eine höhere Spannung testen (bis zu maximal 46V).