photron

Plugin: LED Strip Bricklet 2.0.6 Grünes Aufblitzen nach Reset behoben Support für RGBW LEDs, Channel Mapping und SK6812RGBW (NeoPixel RGBW), LPD8806 und ADA102 (DotStar) Chip Types hinzugefügt FrameRendered callback ist jetzt abschaltbar Download: LED Strip Bricklet Hinweis: Dieses Plugin ist aufgrund seiner Größe vom Flash Transfer Bug betroffen, der in der aktuellen Version der Brick Firmwares behoben wurde. Daher sollte dieses Plugin nur zusammen mit aktueller Brick Firmware verwendet werden.

You get these messages on the desktop if you connect a display to the RED Brick? Do you have access point mode enabled?

Brick Viewer 2.3.6 Improve WIFI Extension 2.0 flashing speed Handle unknown client status for WIFI Extension 2.0 correctly Add moving average length spinbox to Distance US Bricklet plugin Add support for RGBW LEDs, channel mapping and SK6812RGBW (NeoPixel RGBW), LPD8806 and ADA102 (DotStar) chip types to LED Strip Bricklet plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.3.6 WIFI Extension 2.0 Flashing Geschwindigkeit verbessert Unbekannter Client Status der WIFI Extension 2.0 wird korrekt behandelt Spinbox für Moving Average Länge zu Distance US Bricklet Plugin hinzugefügt Support für RGBW LEDs, Channel Mapping und SK6812RGBW (NeoPixel RGBW), LPD8806 und ADA102 (DotStar) Chip Types zum LED Strip Bricklet Plugin hinzugefügt Downloads: Windows, Linux, Mac OS X

Führe mal folgende Befehle in der RED Brick Console aus (benötigt Internetverbindung): sudo -s cd /usr/tinkerforge/bindings wget http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_latest.zip unzip -q -d c tinkerforge_c_bindings_latest.zip cd c/source/ make prefix=/usr make install exit Danach solltest du aktuelle C/C++ Bindings auf dem RED Brick haben. Nachtrag: Das RED Brick Image 1.8 hat C/C++ Bindings die neu genug für das LED 128x64 Bricklet sind. Ich habe es gerade getestet und es funktioniert genauso wie beschrieben. Laut deiner make Ausgabe fehlt der Header nicht. Sondern Symbole/Funktionen in libtinkerforge.a. Das ergibt aber keinen Sinn. Du kannst dennoch versuchen die C/C++ Binding wie beschrieben zu aktualisieren. In der Console kannst du mit "cp <src> <dst>" kopieren. Je nachdem wohin zu kopieren willst muss du das als Root machen: "sudo cp <src> <dst>"

Problem gefunden. Es lag am Initialzustand des Daten Pins zur LED hin. Der war falsch. Das führte dazu, dass die LED beim aller ersten Setzen immer "Grün" verstanden hat. Das Problem ist in RGB LED Bricklet Plugin 2.0.1 behoben. Das LED Strip Bricklet hat das gleiche Problem. Dies wird in der nächsten Plugin Version auch behoben. Danke für den Hinweis Loetkolben!

Plugin: RGB LED Bricklet 2.0.1 Fix green flash after reset Download: RGB LED Bricklet

Plugin: RGB LED Bricklet 2.0.1 Grünes Aufblitzen nach Reset behoben Download: RGB LED Bricklet

Siehe http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html#c-c Speichere folgendes als Textdatei namens Makefile: # Defines CC=g++ CFLAGS=-c -Wall -I/usr/include/tinkerforge LIBS=-ltinkerforge -lpthread EXE=oled SOURCES=oled.cpp OBJECTS=$(SOURCES:.cpp=.o) # Build Rules all: $(SOURCES) $(EXE) .cpp.o: $(CC) $(CFLAGS) $< -o $@ $(EXE): $(OBJECTS) $(CC) $(OBJECTS) -o $(EXE) $(LIBS) clean: rm -f *.o $(EXE) Und lad es zusammen mit oled.cpp als C/C++ Programm auf den RED Brick. die anderen Dateien hat der RED Brick schon. Bei Schritt 3 trägst du oled als Executable ein und setzt den Haken bei "Compile From Source". Den Rest der Einstellungen kannst du dann so lassen.

Du musst deinem Projekt auch noch die ip_connection.c und die bricklet_oled_128x64.c Datei hinzufügen.

Alle paar Wochen ist vielleicht etwas übertrieben, aber durchaus mehrere Tage. Das RS232 Bricklet ist potentiell vom Plugin Ladeproblem betroffen, das in den aktuellen Brick Firmwares behoben wurde. Ich hatte das Bricklet an einem Master Brick mit Firmware 2.4.1 jetzt eine ganze Woche ohne Problem laufen. Das Problem könnte also behoben sein. Bitte testet eure Aufbauen mit der jeweils aktuellen Brick Firmware noch mal. Sorry, dass das hier so schleppend voran geht

Welche Fehlermeldung bekommst du denn? Du musst das Problem schon genauer beschreiben. Meine Glaskugel ist gerade zur Inspektion

ln -s: Das ist okay. Das build_environment_setup.sh Skript legt das exemplarisch schon für eine Firmware an. Ich habe das in der Dokumentation jetzt zu ln -sf geändert, das überschreibt dann den existierenden Symlink einfach. make: Das ist auch genau richtig so. Wenn du make das zweite mal aufrufst ohne Änderungen am Code gemacht zu haben, dann erkennt make, dass nichts zu tun ist weil du nichts geändert hast. Statt alles zu löschen kannst du aber einfach "make clean" aufrufen, damit make alle erzeugen Dateien löscht. Wenn du dann wieder make aufrufst wird die Firmware wieder neu kompiliert da make clean sie zuvor gelöscht hat.

Ups, die Dokumentation ist veraltet und sollte es eigentlich nicht mehr geben. Da muss ich gleich mal aufräumen. Sorry für die Verwirrung. Der aktuelle offizielle Weg ist der hier: http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Build_Environment/Tutorial.html

13 (0-12) characters by 6 (0-5) lines is correct. I'll fix the documentation.

Okay, hier für dich eine Version des LED Strip Bricklet Plugins 2.0.5 ohne den Frame Rendered Callback. Die in Kürze erscheinende neue Version des Plugins wird wahrscheinlich erst mit Master Brick Firmware 2.4.1 funktionieren, wegen des Bugs der in 2.4.1 behoben wurde. Die neue Version wird dann aber auch eine Option haben den Frame Rendered Callback abzustellen. led-strip-bricklet-no-callback.bin

Okay hier eine neue Version der C# Bindings. Im source/Tinkeforge Verzeichnis gibt jetzt es ein TinkerforgeUWP.csproj Datei. Diese in Visual Studio 2015 öffnen und kompilieren. Dabei kommt dann eine TinkerforgeUWP.dll heraus die in einer UWP App funktioniert. tinkerforge_csharp_bindings_2_1_11_rc1.zip

Also nach der Anleitung da treten bei mir Fehler auf z.B. weil der Treiber annimmt es gäbe einen PCI Bus den der RED Brick aber nicht hat. Folgendes funktioniert bei mir: sudo apt-get install libpopt-dev wget http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver-8.1.tar.gz tar xf peak-linux-driver-8.1.tar.gz cd peak-linux-driver-8.1/ make PCI=NO_PCI_SUPPORT sudo make install Damit sollte der Treiber jetzt installiert sein. Dann musst du noch in /etc/udev/rules.d/45-pcan.rules einige Zeilen bearbeiten. Laut Kommentar in dieser Datei müssen für Kernel älter als 3.11 (RED Brick hat 3.4) einige Zeilen einkommentiert werden. Du muss in der Datei das Kommentarzeichen (#) vor allen Zeilen löschen in denen WAIT_FOR steht. Jetzt den RED Brick neustarten und den USB-to-CAN Adapter anschließen. Wenn ich es richtig verstehe sollte das jetzt funktionieren.

Das kannst du so leider nicht abfragen. Wenn sich Brick Viewer noch verbinden kann über WLAN, dann hast du noch nicht alle WLAN Verbindungen aufgebraucht. Denn sonst könnte sich Brick Viewer auch nicht mehr verbinden. Wie setze du denn in deinem Programm die LEDs? Setzt du vielleicht ganze viele LEDs ohne Pause hintereinander weg? Vielleicht versucht du mehr Aufrufe pro Sekunde zu machen als die WIFI Extension schafft. Test mal ob es was bringt zwischen dein einzelnen setRGBValues() aufrufen ein paar Millisekunden zu warten. Kannst du den Code vorzeigen, der das Setzen der LEDs macht?

Hast du das Makefile, so abgeändert, dass es "Pedal_Test1" als Programm erzeugt? Wenn ja dann muss du in Schritt 3 "Pedal_Test1" statt "Test" als Executable angeben.

Dein ursprüngliches Problem war doch, dass dein kleiner Linux PC nicht mit der Menge an Frame Rendered Callbacks parat kommt, wenn du das Bricklet "normal" benutzt, oder nicht? Das hast du versucht zu umgehen, in dem du die Frame Duration passend änderst in der richtigen zeitlichen Abfolge. Das können wir verbessern indem wir z.B. den Frame Rendered Callback abstellbar machen oder eine Render Frame Funktion hinzufügen. Wir haben das gerade noch mal besprochen und denken, das ein abstellbarere Frame Rendered Callback die einfachere und bessere Lösung ist. Dein Skript würde einfach den Chip Type setzen, den Frame Rendered Callback abstellen und die zu setzenden LEDs setzen. Dein Server A/B Problem kann ich nicht nachvollziehen, weder mit abschaltbarem Frame Rendered Callback noch mit extra Render Frame Funktion. Das Bricklet speichert sich welche Farben du für die LEDs gesetzt hast und rendert diese dann jede Frame Duration auf die LEDs, sofern seit dem letzten Rendern die Farben geändert wurden. Es spielt also keine Rolle in welcher Reihenfolge das Rendern und das Setzen passieren, solange nicht Server A und B versuchen die gleiche LED zu setzen. Ablauf 1: 1. Server A setzt LED 1 auf grün -> Bricklet Speicher [grün, schwarz, ...] 2. Frame Duration abgelaufen / Server A ruft Render Frame auf -> LEDs [grün, schwarz, ...] 3. Server B setzt LED 2 auf rot -> Bricklet Speicher [grün, rot, ...] 4. Frame Duration abgelaufen / Server B ruft Render Frame auf -> LEDs [grün, rot, ...] Ablauf 2: 1. Server A setzt LED 1 auf grün -> Bricklet Speicher [grün, schwarz, ...] 2. Server B setzt LED 2 auf rot -> Bricklet Speicher [grün, rot, ...] 3. Frame Duration abgelaufen / Server A ruft Render Frame auf -> LEDs [grün, rot, ...] 4. Frame Duration abgelaufen / Server B ruft Render Frame auf -> keine Änderung Beides führt zum gleichen Ergebnis. Was übersehe ich?

Loetkolben, du willst eigentlich einen Single-Shot Modus haben oder nicht? Die API des LED Strip Bricklets ist im Moment auf Animationen ausgelegt. Sprich, du stellst über die Frame Duration die Frame Rate ein. Dann wird alle X ms der Frame auf die LEDs geschrieben und der Frame Rendered Callback ausgelöst. Auf den Callback hin hat dein Programm dann bis zu X ms Zeit den nächsten Frame an das Bricklet zu schicken. Wenn ich dich aber richtig verstehe dann willst du die LEDs nicht in dem Sinne animieren. Sondern nur einmal setzen. Du brauchst also keine Frame Duration, die ist dir nur im Weg. Du willst eigentlich Frame Duration auf 0 setzen, aber dann wird nichts angezeigt. Wie wäre es hier mit: Setup: - set_frame_duration(0), weil sie initial 100 ms ist LEDs setzen: - set_rgb_values(...) - render_frame(), neue Funktion, erzwingt das sofortige Senden der Daten an die LEDs Damit hättest du dann volle Kontrolle wann die Daten anzeigt werden. Das ist es was du eigentlich haben möchtest, oder?

Oh, the OLED Bricklets were completely missing in the proxy. I've fixed that now!

Okay, du hast also nur Test.cpp und sonst Dateien aus den C/C++ Bindings. Dann speicher folgendes mal als Datei namens "Makefile" und lad es zusammen mit deiner Test.cpp Datei also C/C++ Programm auf den RED Brick: # Defines CC=g++ CFLAGS=-c -Wall -I/usr/include/tinkerforge LIBS=-ltinkerforge -lpthread EXE=Test SOURCES=Test.cpp OBJECTS=$(SOURCES:.cpp=.o) # Build Rules all: $(SOURCES) $(EXE) .cpp.o: $(CC) $(CFLAGS) $< -o $@ $(EXE): $(OBJECTS) $(CC) $(OBJECTS) -o $(EXE) $(LIBS) clean: rm -f *.o $(EXE) Die Bindings Dateien kannst du weglassen, die sind schon auf dem RED Brick. Im Programm Uplaod Wizard wählst du dann in Schritt 3 "Test" als Executable und aktiviert die "Compile From Source" Option. Den rest des Wizards kann du auf den Standardwerten lassen.

Auf dem RED Brick ist standardmäßig das Python3 Development Package nicht installiert. Du musst also zuerst über die Console python3-dev nachinstallieren. Am einfachsten geht das wenn der RED Brick Internetverbindung hat: sudo apt-get install python3-dev Dann kannst du das python3-config Tool nutzen, das dir sagt wo die Header und Libs sind und welche C- und LD-Flags zu setzen sind. Dazu einfach die CFLAGS und LIBS Zeilen in deinem Makefile so abändern: CFLAGS=-c -Wall -I/usr/include/tinkerforge $(shell python3-config --cflags) LIBS=-ltinkerforge -lpthread $(shell python3-config --ldflags) Auf dem RED Brick wirst du allerdings Python 3.4 haben, nicht 3.5.