Stapel hängt sich mit LED-Strip auf

[jan]

Wenn ich das LED-Strip am Stapel per USB beteibe -> alles OK.

 

Sobald ich es in mein "TF-Netzwerk" mit einbinden möchte, hängt sich der Stapel an dem es hängt auf.

 

Mein "TF-Netzwerk": einige Bricks die per RS484 miteinander verbunden sind. An den Bricks hängen nur Sensoren, es werden nur Leseoperationen ausgeführt.

 

Das LED-Bricklet sollte jetzt mit darin integriert werden. Aber selbst das lesen des Bricklets funktioniert nicht -> TimeoutExeption -> Stapel hängt sich auf -> ich muss alles reseten 

 

Im BrickV sieht man das LED-Bricklet und kann es auch eine Weile (ein paar Änderungen/Befehle) steuern -> danach tot.

 

Programmierung: PHP, mit python getestet -> geht auch nicht

Rs484: 500000 Baud

[photron]

Wie viele LEDs steuerst du denn mit welcher Framerate an? Möglicherweise reichen 500 kBaud nicht aus, um die Datenmenge schnell genug zu befördern, was dann zu Timeouts führt. Aufhängen sollte sich das System dadurch nicht, sobald du aufhörst mehr Daten zu schicken als dein System verkraften kann sollte es wieder normal reagieren.

 

Was du testen kannst:

 

- Baudrate für RS485 erhöhen

- Weniger LEDs ansteuern

- LEDs mit einer geringeren Framerate ansteuern

- LED Daten nicht als Burst senden, sondern die set_rgb_values Aufrufe über die Länge des Frames verteilen

[jan]

Es sind 32 LED's. Diese werden "nur" per $ledStrip->setRGBValues(0, 16, $r, $g, $b); (2x je 16) angesprochen. Kein Callback, kein Animation, etc...

LED Daten nicht als Burst senden, sondern die set_rgb_values Aufrufe über die Länge des Frames verteilen

Soll das heißen: $ledStrip->setRGBValues(0, 2, $r, $g, $b); und dafür öfter für alle LED's?

Baudrate für RS485 erhöhen

geht leider nicht, sonst fuktioniert das restliche "Netzwerk" nicht mehr richtig.

 

Ich werd es noch mal testen an einem seperatem Brick-RS485-Netzwerk. Ansonsten muss es halt alleine an einen Brickstapel und mit 'nem RasPI dazwischen.

[photron]

Es sind 32 LED's. Diese werden "nur" per $ledStrip->setRGBValues(0, 16, $r, $g, $b); (2x je 16) angesprochen. Kein Callback, kein Animation, etc...

 

Okay, dass heißt du setzt die LEDs einmal und das reicht schon um das Problem zu erzeugen?

 

Ich hatte angenommen du setzt die LEDs immer wieder, um eine Animation zu erzeugen. Wenn das nicht der Fall ist dann sind alle meine Hinweise hinfällig.

 

LED Daten nicht als Burst senden, sondern die set_rgb_values Aufrufe über die Länge des Frames verteilen

Soll das heißen: $ledStrip->setRGBValues(0, 2, $r, $g, $b); und dafür öfter für alle LED's?

 

Nein, ich meinte das bezogen auf Animationen. Das typische Vorgehen hier ist auf den FrameRendered Callback zu reagieren und dann alle LEDs in einem Rutsch (Burst) neu zu setzen. Also ganz viele Setter-Aufrufe auf einmal ohne Pause dazwischen. Das könnte ein Problem sein, die Abhilfe wäre dann zwischen den Setter-Aufrufen kurze Pausen zu machen. Aber wenn du keine Animation machst und nicht ganz viele setRGBValues Aufrufe hintereinander weg machst, dann ist das nicht dein Problem.

 

Baudrate für RS485 erhöhen

geht leider nicht, sonst fuktioniert das restliche "Netzwerk" nicht mehr richtig.

 

Okay, wenn du nur 32 LEDs ab und zu setzt, dann ist der Datendurchsatz eher nicht dein Problem.

 

Wenn ich das LED-Strip am Stapel per USB beteibe -> alles OK.

 

Sobald ich es in mein "TF-Netzwerk" mit einbinden möchte, hängt sich der Stapel an dem es hängt auf.

 

Ist das vielleicht ein Problem mit exakt dem Stapel? Hast du exakt den Stapel mit LED Strip Bricklet dran mal per USB getestet? Oder mal einen anderen Bricklet Port an dem Stapel getestet? Oder ein anderes Bricklet Kabel?