[Workshop] Eigenes Lichtsteuerprogramm mit dem Raspberry Pi

[chris_kah]

Neuanschaffung: Raspberry Pi 4 mit Touch Display und Gehäuse (unten links)

Da entsteht gerade ein kompaktes Lichtsteuergerät (und eventuell eine Fernsteuerung (X-Air Edit) für das XR18)

Mit WinSCP und Remote Desktop kann man auf dem Pi komfortabel entwickeln und dann zum Schluss auf dem Toch Display alles testen. Mein Editor (PsPad) läuft auf dem PC und speichert über WinSCP direkt auf dem Raspi. Dort startet man das Programm dann testweise und sieht sofort das Ergebnis.

Das GUI für die Steuerung wurde heute zur Hälfte fertig.
Die Druckknöpfe und Regler funktionieren schon wie gewünscht und liefern Datenwerte, die auf das DMX Pattern geschrieben werden können.
Jetzt kommt die Anbindung an ArtNet, um meinen ArtNet Node im Aufbau fernzusteuern.
Für die ArtNEt Anbindung kann ich gleich die Daten übergeben, um zu schauen, ob es funktioniert. Bisher würde das nur statisch einstellbar für alle Scheinwerfer gehen.
Später kommt die 2. Seite im GUI, um Presets abzufeuern.

Schon vorbereitet ist auch die Hardware auf einem Aufsteck-Proto-Board um die interne serielle Schnittstelle zur direkten DMX Ausgabe zu missbrauchen. Da muss nur noch der RS485 Treiberbaustein eingelötet werden und der Anschluss an die Ausgangsbuchsen.
Das eine Universum soll parallel an ArtNet und an die direkt angeschlossene Hardware ausgegeben werden können, damit ich bei der Verkabelung des Lichts größtmögliche Freiheit habe. So kann z.B. die Frontbeleuchtung am FOH eingesteckt werden, während die bunten Bühnenscheinwerfer am Mixer-Rack abgegriffen werden.

Auf jeden Fall ist noch einiges zu tun.

 

[julianstr]

@chris_kah Wieso nimmst du nicht QLC+ dafür? Warum das Rad neu erfinden wenn es schon fertige gute Software dafür gibt...

 

[chris_kah]

Dafür gibt es mehrere Treiber:

1. will ich mich etwas mit Python und pygames beschäftigen, weil ich das anderweitig auch brauche. Ich habe an einem knappen Tag viel über die Möglichkeiten gelernt, ein User Interface zu bauen.
   
2. ist fertige Software nicht unbedingt zeitsparend. Ich hatte eine Android Software (Art-Net Controller Lite) und habe dort versucht, ein paar Szenen und Chases (langsam durchwaberndes Licht) aufzusetzen. Hat trotz intensiver Recherche keinen Erfolg gebracht. Habe dann selber ein kleines Lichtpult gebastelt und in der Summe weniger Zeit investiert, als ich für die ergebnislose Einarbeitung in die (fertige) Android Software gebraucht habe (da schlechte Dokumentation) und mein Pult kann alles das, was ich bei einem kleinen Gig so brauche.
3. habe ich schon mal versucht QLC+ auf einem Linux Netbook zum Laufen zu bringen - ergebnislos, irgendwas hat nicht gepasst. Ich habe irgendwann frustriert abgebrochen. Es gibt wohl QLC+ auch speziell für den Raspi, aber wie sich das dann mit dem kleinen 7" Touchpad bedienen lässt ...? Ein größerer Bildschirm kommt nicht in Frage, denn es soll ja gerade kompakt sein und meinen Arbeitsplatz auf der Bühne nicht zustellen. Das muss nebenbei an meinen Mikrofonständer passen, an dem auch schon der Kleinmixer bzw. meine BCR2000 Fernbedienung hängt.

Ich habe ein sehr kleines Setup (3 weiße Frontscheinwerfer + 5 bunte Scheinwerfer für die Bühne). Da kann ich alles noch gut selber durch eigene Software handhaben und setze Szenen einfach über Textfiles auf. Da kann ich mit Copy Paste neue Szenen schneller aufsetzen als mit einem fertigen Programm.
Wir mischen uns von der Bühne und da ist vor allem das Abfeuern von Presets gefragt.
Die meisten Programme sind ein Overkill für meine Anwendung. Und wenn ich auch nur einen kleinen Teil nutze, muss ich mich doch in das große Paket einarbeiten.

Das sähe sicher anders aus mit einem großen Setup, Moving Heads und mit eigenem Lichttechniker. Da macht das sicher Sinn.

Bisher habe ich noch eine Lösung mit PC Dimmer auf dem Laptop. Der Vorteil: ich konnte ein Steuerpanel anlegen für die wichtigsten Presets. Durch die LTP Philosophie kann ich dort Szenen verwalten, die nur das Frontlicht oder nur die Bühnenbeleuchtung betreffen und sich gegenseitig nicht stören. Und ich kann das Programm, das auf dem Laptop läuft, per Android fernbedienen (auch da z.B. nur das Kontrollpanel mit den 27 fertigen Szenen zum Abfeuern drauf). Mit diesem Kontrollpanel (auf dem Laptop) konnte das mein damals 13-jähriger Sohn auf Anhieb bedienen. Und das Kontrollpanel passt auf dem Laptop noch neben das X-Air Edit, das gleichzeitig drauf läuft.

Wir haben keinen Lichttechniker und keine ausgefuchste Bühnenshow. Wichtig ist, dass die Bedienung im Ablauf bei der Performance nebenher ohne allzugroße Aufmerksamkeit erfolgen kann. Bei der Front gibt es 2 Grundstimmungen warmes Licht und kühles Licht sowie 3 Presets, um einen Solisten hervorzuheben. Die Bühne hat entweder statisches Stimmungslicht oder langsam durchlaufende Farbverläufe. Es gibt z.B. auch Szenen wie "Moonlight", eher kühl oder "Candelight", eher warm und heimelig, die sowohl Front als auch Bühnenlicht setzen.

Diese neue Lösung ist die etwas komfortablere Alternative zu meinem einfachen Mini-Lichtpult, die auch mit dem ArtNetNode kommunizieren lernen soll.

 

[chris_kah]

So, die Anbindung an ArtNet klappt auch. Gestern ging es nicht weiter, da wir den ganzen Tag weg waren, aber heute hatte ich etwas mehr als eine Stunde Zeit. Ich konnte mit meinen Fadern im GUI über ArtNet die zugehörigen Lampen ansteuern. GUI funktioniert wie gewünscht, DMX über ArtNet auch. Der Rest ist jetzt nur noch Arbeit (Standard-Programmierung).
Falls es interessiert: ich habe die stupid ArtNet libraries verwendet und das klappte auf Anhieb.

 

[chris_kah]

Fertig.

Hier die 2 Panels, die man mit den 2 Knöpfen am linken Rand umschaltet, Faderansicht und Szenenabruf

Aber das ist ein schnuckelig kleines Gerät, das sich ganz einfach per Touch Screen nebenher bedienen lässt:

Im Hintergrund zum Vergleich 19" 3 HE, die Größe von handelsüblichen einfachen Controllern, die aber nicht den mir wichtigen Bediencomfort bieten.

Und natürlich macht es schön bunt

Was man nicht sehen kann, ist die Action, denn das Teil kann statische Szenen, Farbverläufe, Lauflicht und so Spezialitäten wie gleichzeitig laufendes Lauflicht hinten und parallel die weiche Überblendung in der Front. Das kann keiner der einfachen Controller.

Bin sehr zufrieden. Ich habe für die Programmierung und Erstellung der Szenen vermutlich weniger Zeit investiert, als ich bei PC Dimmer gebraucht habe für Einarbeitung und Aufsetzen der Szenen/Chases
Wohlgemerkt, das Teil arbeitet mit Art Net, was die einfachen Pulte auch nicht können. Ich kann das Teil per WLAN betreiben (so wie es hier auf dem Bild auch betrieben wird)

Wenn ich noch Zeit und Lust habe, binde ich das DMX Interface auch noch ein. Hardware ist auch schon fertig und würde erlauben, das Ganze direkt ohne ArtNet zu betreiben.

die beiden Lötpunktreihen beim grünen Pfeil sind die RS485 Signale für DMX und eine rechts davon ist Masse -> nur noch an XLR Buchsen führen und schon ist der Anschluss da.
Der Software- Teil wird spannender - aber erst mal mache ich Pause und nehme mir mehr Zeit zum selber Musik machen.

 

[chris_kah]

Da dieses Thema aus dem "Neuanschaffungs- und Berichte" Thread im PA Bereich hierher als eigenes Thema ausgelagert wurde, von mir noch einige Anmerkungen:

Für das GUI verwende ich die pygames Library von Python. Beim Raspberry Pi ist die per Default drauf, ebenso Python.
Damit lassen sich nicht nur Spiele programmieren sondern auch User Interfaces.
Knöpfe und Schieberegler sind Bilder. Die Druckknöpfe 2 verschiedene, die jeweils gedrückt und nicht gedrückt darstellen. Durch schwarze bzw. weiße Kanten kann man die Knöpfe erhaben oder gedrückt darstellen.
Die Fader sind auch Bilder (alle die gleiche Source)
Anfangs hatte ich die bunten Faderbahnen im Hintergrundbild, aber ich bin einfach auf ein graues Rechteck im Hintergrund umgestiegen und habe die Bahnen als 5 Punkt breite Rechtecke gezeichnet, die an der Y-Position der jeweiligen Fader hängen. Damit kann ich die Fader auch seitwärts umpositionieren, indem ich dem Fader einfach einen anderen Y-Wert gebe (Man sieht das beim ersten Post, wo die Fader alle noch den gleichen Abstand haben, später sind die anders positioniert.
Die Fader haben eine Bahnlänge von 256 Pixeln - passt wunderbar zu den 0 .. 255 Werten bei DMX, kannn einfach 1:1 verwendet werden.
Ist ein Fader ausgewählt, so wir bis zum Loslassen nur noch die Y-Position der Maus/Touch verwendet.

Die bunten größeren Taster mit Bildern im 2. Screen sind einfach kleine Bildchen mit 80 x 80 Pixel Größe. Die sind algorithmisch auf der Fläche verteilt, was die Abfrage der Mausklicks bzw. Touch Event einfach macht. Die ganzen Farben sind gezeichneteQuadrate der entsprechenden Farbe.

---

Die DMX Werte verwalte ich nach dem LTP (Latest Takes Precedence) Prinzip. Es gibt ein Array für alle aktuellen DMX Werte und eines für die neuen DMX Werte. Dazu gibt es ein Array mit Steps, die bis zum Erreichen des neuen Werts herunter gezählt werden. Und es gibt ein Delta, das bei jedem Step dazu gezählt oder abgezogen wird, je nach Vorzeichen. Errechnet wird das quasi rückwärts vom Endwert: Endwert - Step * Delta, wobei ja Step rückwärts bis 0 zählt.
Vorteil dabei: unabhängig von Rechenungenauigkeiten wrid derneue Endwert genau getroffen, denn der ist ja schon als Zielwert hinterlegt, und von dem wird ja rückwärts gerechnet.

Auf diese Weise kann sogar mitten im Farbverlauf einfach ein neuer Zielwert überschrieben werden, denn da wird vom gerade aktuellen Wert weiter gemacht und die neuen End, Step und Deltawerte errechnet. Bei Kanälen, die nicht betroffen sind, läuft das einfach so weiter bis zum Endwert.

Somit ist jeder DMX Kanal unabhängig und macht sein Ding bis ein neuer Ziel - und Step-Wert kommt.
Ein Lauflicht kann mit harten Übergängen laufen (z.B. alle bunten auf der Bühne) während gleichzeitig weiche Überblendungen in der Front verarbeitet werden.

Auch noch ein Detail: jeder DMX Wert, der geschrieben wird, durchläcuft ein Clipping: Werte keliner als 0 werden zu 0 und werte größer als 255 werden zu 255. Sollte mal im Programm versehentlich ein Überlauf passieren, wird der einfach "gerichtet".


---

Das Interface zum DMX Bus geht per LAN/WLAN über ArtNet.

Ich habe dafür die Stupid Art Net Library von Github genutzt, Link ist weiter oben im Text.

Das Beispielprogramm, das da mitgeliefert wurde, hat praktisch auf Anhieb funktioniert. Ich habe nur noch die Adresse des Art Net Nodes auf die von meinem Node geändert und die Patternlänge angepasst.

Mit diesem Beispiel als Vorlage, war das dann ganz schnell in mein Programm eingebaut.

---

Jetzt fehlt nur noch die gleichzeitige Ausgabe des Patterns auf den seriellen Port des Raspberry Pi. Wie schon oben erwähnt ist der RS485 Treiber schon auf dem Proto-Board aufgelötet. Da muss ich mich noch schlau machen, wie ich da an die serielle heran komme und zwar "low level" genug. Das DMX Pattern hat ja ein langes Break/Reset Muster, für das man am besten die Baudrate entsprechend tief programmiert, dann eine 0 sendet und wieder auf die DMX Baud Rate von 250 kBaud zurück stellt.

Ich mache hier aber mal Programmierpause, denn ich will wieder mehr Musik machen und Mikrofone testen.

 

[L(az)E]

Da dieses Thema aus dem "Neuanschaffungs- und Berichte" Thread im PA Bereich hierher als eigenes Thema ausgelagert wurde, von mir noch einige Anmerkungen:
Jetzt fehlt nur noch die gleichzeitige Ausgabe des Patterns auf den seriellen Port des Raspberry Pi. Wie schon oben erwähnt ist der RS485 Treiber schon auf dem Proto-Board aufgelötet. Da muss ich mich noch schlau machen, wie ich da an die serielle heran komme und zwar "low level" genug. Das DMX Pattern hat ja ein langes Break/Reset Muster, für das man am besten die Baudrate entsprechend tief programmiert, dann eine 0 sendet und wieder auf die DMX Baud Rate von 250 kBaud zurück stellt.

Da gibt's als Inspirationsgrundlage das uartdmx-Plugin in OLA . OLA an sich ist auch eine Überlegung wert, um den gesamten DMX-Output darüber zu machen und die Anwendung nur per OLA-API anzukoppeln.

 

[chris_kah]

Interessant. Das ist allerdings alles in C. Müsste ich mich schlau machen, wie das mit der Entwicklungsumgebung / Compiler aussieht. C selber ist keine Hürde, denn damit programmiere ich ständig, allerdings in der Entwicklungsumgebung von Atmel (AVR) - jetzt Microchip.
Aber vielleicht kann ich da abschauen, wie der UART da angesprochen wird, vor allem, wie die Baudraten programmiert werden. Der Rest ist ja einfach sequentielles Abschicken von Zeichen über den UART.

 

[L(az)E]

Das Break-Handling erledigt der UartDmxThread: Break-Condition auf der Schnittstelle setzen, warten, Break aufheben. Der Rest ist termios/termios2 und ioctl, das müsste entsprechend auch als Python-Library verfügbar sein. Die Baudrate wird einmal fest auf 250kbaud gesetzt und dann so gelassen. Dazu ist dann termios2 nötig, weil das keine Standard-UART-Baudrate mehr ist und spezielle Treiber-Unterstützung benötigt. Die ist beim RasPi aber gegeben.

 

[chris_kah]

Zum seriellen Interface auf dem Raspi bin ich noch nicht gekommen, aber ich habe gerade Python und Pygames auf dem Laptop installiert und das oben vorgestellte Programm dort zum Laufen gebracht. Ich musste im Programm einen Pfad anpassen (der war fix eingetragen) und bei 2 Beschreibungsfiles den Zeilenumbruch auf UNIX Format umstellen, dann lief es.

Jetzt muss ich da den PC Dimmer gar nicht mehr bemühen.

Mal sehen, ob ich noch an die serielle Schnittstelle komme.
Die aktuelle Idee ist, einen ArtNet Node Thread auf dem Raspi laufen zu lassen, der die DAten per ArtNet empfängt und auf die serielle Schnittstelle ausgibt. Dann könnte mein Steuerprogramm die ArtNet Daten auf den externen und den internen Node (localhost) schicken. Und der Raspi könnte als alleinstehender ArtNetNode ferngesteuert werden, wenn das Steuerprogramm nicht läuft. Das wäre die maximale Flexibilität.

 

[chris_kah]

Noch ein kleiner aber feiner Umbau für den Laptop.
Allein durch Editieren einiger Zahlen in Tabellen habe ich mein User Interface als Alternative schlank und hoch gemacht, so dass es jetzt haarscharf neben mein X-Air Edit passt, Funktionalität ist die gleiche wie bisher, nur dass jetzt die Schaltflächen anders angeordnet sind. Bisher 6 Schaltflächen breit und 4 hoch, jetzt 3 breit und 8 hoch.

Auch die Fader in der anderen Ansicht sind dichter zusammen gerutscht und die Steuerknöpfe anders sinnvoll verteilt. Passt aber jetzt genau von der Breite rein.
Ich muss das einfach so links ein bisschen rausschieben, komme aber an alle Bedienelemente.
Damit kann ich jetzt den PC Dimmer für meine Auftritte in Rente schicken, wobei ich damit schon auch noch arbeiten werde, wenn's nur um Licht geht.

 

[Rebel!]

Hut ab.

Mein Respekt,
tolle Arbeit, schönes Projekt
Halte uns generell auf dem laufenden.

LG Rebel

 

[chris_kah]

Danke für die Kekse @Rebel!

Falls jemand einen ArtNet Node für den Raspi entwickelt hätte, oder eines kennt, wäre ich dran interessiert.
Sollte so funktionieren:

• Eigenes Programm (Thread)
• Sollte ArtNet Daten per LAN/WLAN empfangen
• Sollte DMX auf dem eingebauten seriellen Port des Raspi ausgeben (1 Universum reicht dicke)

(Also nichts, bei dem man noch ein externes Interface dranhängen muss. Das interne ist schon per HW Treiber DMX vorbereitet)

Falls jemand meinen Code für das Projekt oben gerne haben will als Vorlage, stelle ich den gerne zur Verfügung. Ich habe ja auch mit einfachen Beispielen aus dem Netz als Vorlage angefangen und dann alles zu meiner Lösung zusammengetragen und komplettiert. Nur allzuviel Support kann ich aus Zeitgründen nicht geben.

 

[L(az)E]

@chris_kah klingt, als wäre OLA das Mittel der Wahl mit dem UART DMX Plugin.

 

[chris_kah]

Danke, das schaue ich mir mal an, wenn ich Zeit habe.

 

[SB]

Muss es ein RasPi sein? Irgendwann hatte ich mal was für den Arduino Mega mit Ethernet-Shield zusammengezimmert. MAX485 dran und los gehts. Kann sogar IP-Merge, funktioniert aber nur mit bis zu zwei Quellen (keine Ahnung warum, wahrscheinlich geht ihm der RAM aus). Subnet/Uni hatte ich hardgecoded, genauso wie das IP-Setting. Kann ich die Tage mal raussuchen.

 

[chris_kah]

Ja, es sollte der Raspi sein, denn auf dem läuft ja schon das Steuerprogramm. Auf dem soll dann auch dazu der ArtNet Node laufen, der das umsetzt (localhost).
Vorteil:
Ich müsste das nicht ins Steuerprogramm integrieren (was vermutlich aber die einfachste Variante wäre). Mit dem gesonderten Thread wäre das entkoppelt.
Der Raspi wäre dann auch alternativ als ArtNet Node fernsteuerbar, wenn das Steuerprogramm nicht auf dem Raspi läuft.

Anwendung: Wenn ich Licht von der Bühne mache, dann direkt über den Raspi.
Ansonsten das Steuerprogramm am Raspi schließen und von einem anderen Rechner über das gleiche Interface ohne Umstecken das Licht steuern.

So ähnlich mache ich das bisher mit dem vorhandenen ArtNet Node, der in meinem XR18 - Rack mit integriert ist. Mal von der Bühne per Raspi, oder wenn ich am Laptop am FOH sitze, dann vom Laptop (Raspi aus).
Es sollten nur nicht beide Programme gleichzeitig laufen, sonst gibt es Kuddelmudel, daber das bekomme ich hin.