www.radonmaster.de/dancingwater/uebertragung/         Stand: 31.10.2016

home             Übertragungskonzepte

Ein Master-Controller legt die Wasser-Choreographie fest und übermittelt Kommandos an viele Slave-Controller. Zur Realisation sind zwei unterschiedliche Konzepte denkbar:
Das erste Übertragungskonzept verwendet komplexe, übergeordneten Kommandos, die wir als Makro-Kommandos bezeichnen.
Im zweiten Konzept überträgt der Master eine sehr große Anzahl einfacher Steuergrößen, die wir als Basis-Kommandos bezeichnen. Damit verlangt es praktisch keine Intelligenz der Slave-Controller.

Makro-Kommandos
Das erste und naheliegendste Übertragungskonzept verwendet übergeordnete Kommandos. Das sind Anweisungen, die die Slaves in eine Folge Basis-Kommandos auf Hardware-Niveau auflösen (z.B. laden der PWM-Register). Die Anforderungen an den Master-Controller sind dabei recht klein, sodass auch er durch einen Arduino-Controller realisiert werden kann. Dazu gehören Aufträge wie:

- Fontänenhöhe innerhalb von 3 sec auf 120 cm einstellen.
- äußerer Fontänenring periodisch auf und ab zwischen Höhe 50 cm und Höhe 80 cm im Abstand von 870 ms.
- Strahler 15 innerhalb von 5 sec auf 100 Skalenteile (Skt) Gelb einstellen.
- Strahler 21 bis 32 innerhalb von 8 sec auf maximales Rot (255 Skt) einstellen.

Basis-Kommandos
Das zweite Konzept gibt es bereits als fertigen Standard DMX512 (DIN 56930). Dieser Standard wurde ursprünglich für die Lichtsteuerung in Theatern entwickelt. Inzwischen verwenden auch die Hersteller großer Brunnenanlagen DMX zur Steuerung ihrer Pumpen, Ventile und Servoeinrichtungen. Eine große Anzahl Basis-Kommandos wird in schneller Folge übertragen. Die Slaves haben in diesem Fall lediglich die Umsetzung in die Steuergrößen (Einschaltzeit, Spannung, Position) der angeschlossenen Geräte wie Pumpen und Lampen zu übernehmen. Dazu gehören Aufträge wie:

- Pumpe 07, Fontänenhöhe 120 cm einstellen.
- Strahler 10 Weiß, 100 Skt einstellen.
- Strahler 15 Rot, 100 Skt (3 Basis-Kommandos für gelbes Licht des Strahlers 15).
- Strahler 15 Grün, 100 Skt.
- Strahler 15 Blau, 0 Skt.

Die Auflösung eventuell ursprünglich vorhandener Makros übernimmt der Master-Controller, der deshalb eine größere Rechenleistung vorhalten muss. Im Fall dieser Beispiele erfolgt die Einstellung einer Fontänenhöhe oder Helligkeit schlagartig. Meistens ist ein langsamer Übergang auf die vorgegebenen Werte gewünscht. Damit vervielfacht sich der Aufwand. Jeder einzelne Zwischenwert wird vom Master-Controller berechnet und durch den DMX-Bus geschickt. Zusätzlich müssen alle Werte wiederholt werden, die sich nicht verändern. Der gesamte Datenstrom von bis zu 512 aufeinanderfolgenden Bytes wird ständig ohne Pause wiederholt.

DMX hat einige Vorteile, aus meiner (technischen) Sicht jedoch überwiegend Nachteile.

Vorteile von DMX:
- Vorhandene Editor-Programme zur Erzeugung ganzer Licht-Szenarien mit einem PC.
- Reaktion mehrere Geräte auf dieselben Kommandos.
- Viele standardisierte Geräte erhältlich.
- Signalpegel (RS485) für lange Übertragungswege (über 1000 m) geeignet.
- Vorhandene Arduino Bibliotheken zur Behandlung von DMX-Kommandos.
- Programmentwicklung der Slave-Prozessoren kostet wenig Zeit.

Nachteile von DMX:
- Übertragung der Steuersignale im exotischen Datenformat. Eine normale serielle Übertragung wäre ohne Spezialprogrammierung zu handhaben.
- Spezielles Interface zwischen Master und DMX-Bus erforderlich.
- Keine vernünftige Adressierung der gesteuerten Geräte, anfällig für Übertragungsfehler.
- Übertragung extrem großer, redundanter Datenmengen.
- Relativ schlechtes zeitliches Auflösungsvermögen (20 bis 30 ms, jedoch völlig ausreichend für Wasserfontänen). Weniger Redundanz und 5 ms Auflösung wären günstiger.
- Ständige Wiederholung der Übertragung, kein Einfluss des Anwenders auf die Häufigkeit einer Sendung.
- Eigene Programmierung eines PC als Master für den Nutzer kaum möglich.

Weil es für das aus meiner Sicht elegantere Konzept mit Makro-Kommandos weder einen Standard noch eine Software zur Programmierung der Fontänen gibt, müsste beides selbst entworfen werden. Das ist nicht durchführbar, weil der Zeitaufwand dafür zu groß wäre.

Das zweite Konzept (DMX) ist sehr primitiv, weil es noch aus Hardware-Zeiten stammt. Um zu einer fertigen Choreographie zu kommen, scheint es aber der einzig gangbare Weg zu sein. Weil ich das DMX-Verfahren mit eigenen DMX-Receivern (Slave-Controllern) aufbaue, bietet sich theoretisch die Möglichkeit, den DMX-Standard durch eigene Makro-Kommandos zu erweitern. Das habe ich anfangs tatsächlich realisiert, indem ich z.B. eine dynamische Zuordnung der DMX-Adressen zur Drehung ganzer Fontänenbilder eingeführt habe. In der Praxis hat sich das jedoch nicht bewährt.

Mehr zu DMX gibt es auf einer eigenen Seite: DMX und Erweiterungen

home