202 lines
9.5 KiB
TeX
202 lines
9.5 KiB
TeX
\documentclass[11pt,ngerman,a4paper,chapterprefix]{scrartcl}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{graphicx}
|
|
\usepackage[ngerman]{babel}
|
|
\usepackage{fancyhdr}
|
|
\usepackage{hyperref}
|
|
|
|
\usepackage{geometry}
|
|
\geometry{bottom=30mm}
|
|
|
|
\usepackage{nomencl}
|
|
\makenomenclature
|
|
|
|
\title{DMX512-RDM}
|
|
\author{Jens Ullmert}
|
|
|
|
|
|
\newcommand{\abbr}[2]{\textit{#2} (#1)\nomenclature{#1}{#2 \nomrefpage}}
|
|
\newcommand{\source}[1]{ {\scriptsize Quelle: {#1} } } %command definition for sources in figures
|
|
|
|
\begin{document}
|
|
\pagestyle{fancy}
|
|
\setcounter{section}{7}
|
|
|
|
|
|
\section{DMX 512 - RDM}
|
|
|
|
Die in Abschnitt 4 vorgestellte Hardware kann durch den \textit{GPIO18} zwischen Lese- und Schreibfunktionalität umgeschaltet werden.
|
|
Diese Funktion ermöglicht es theoretisch, die \abbr{RDM}{Remote Device Management} Erweiterung des DMX Protokolls zu nutzen, womit sich der folgende Abschnitt näher befasst.\\
|
|
|
|
RDM wird im Live-Bereich der Veranstaltungstechnik sehr selten bis nicht verwendet und grundsätzlich während der Show deaktiviert.
|
|
Da dieses Feature nur von hochpreisigen Endgeräten angeboten wird, ist die Wahrscheinlichkeit groß, dass sich ebenfalls Geräte ohne RDM im Strang befinden.\\
|
|
|
|
Durch den Zugriff mehrerer Sender auf den gleichen Bus muss ein passendes Buszugriffsverfahren gewählt werden, bei dem die rückmeldenden Pakete den Datenfluss vom Mischpult an die Endgeräte nicht stört.
|
|
Der Reset zur Einleitung jeder Übertragungssequenz setzt mithilfe des \abbr{CSMA/CA}{Carrier Sense Multiple Access / Collision Avoidance} Zugriffsverfahrens eine Priorität, sodass alle Endgeräte ihre Übertragung im Sinne der Kollisionsvermeidung abbrechen und den Bus freigeben.\\
|
|
|
|
Dies setzt zusätzlich voraus, dass jedes Endgerät in der Lage ist, einen vom Lichtpult gesendeten Reset zu detektieren.
|
|
Alte oder nicht standardkonform programmierte Geräte können hier möglicherweise aufgrund falscher Interpretationen ein Fehlverhalten aufweisen.\\
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics*[scale=0.3]{img/c2-1-1_dmx_timing.PNG}
|
|
\caption{Timing bei DMX}
|
|
\label{fig:timing}
|
|
\source{https://wiki.production-partner.de/licht/lichtsteuerung-mit-dmx-512/}
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
~\\
|
|
\subsection{Aufbau der RDM Pakete}
|
|
Die Kommunikation im RDM-Fall ist vergleichbar mit \(I^2C\).
|
|
Das Lichtpult fungiert als Master und fragt gezielt eine Information an einer Lampe an, welche daraufhin antwortet.
|
|
Zur Adressierung wird eine 48 Byte UID verwendet, welche stark an die MAC-Adresse bei Ethernet erinnert.
|
|
Die ersten 16 Byte geben Aufschluss über den Hersteller, die restlichen 32 Byte können individuell vergeben werden.\\
|
|
Die UID FF.FF.FF.FF.FF.FF wird als Broadcast verwendet.\\
|
|
|
|
Um eine eindeutige Unterscheidung zwischen DMX- und RDM-Paketen zu gewährleisten wird als abweichender Startcode 0xCC anstelle 0x00 verwendet.
|
|
Bei einer korrekten Implementierung des DMX Protokolls sollte das empfangene Paket verworfen werden, wenn keine RDM Funktionalität im Endgerät verfügbar ist.\\
|
|
An den Startcode wird der sogenannte Substartcode Byte 0x01 angehängt.
|
|
Dieses dient als Platzhalter für zukünftige Protokollerweiterungen.\\
|
|
|
|
Befehle und Antworten setzen sich aus drei Byte zusammen.
|
|
Das erste Byte ist die Befehlsklasse, siehe Tabelle \ref{tab:klassen} die anderen beiden die Befehls-ID, siehe ausschnittsweise Tabelle \ref{tab:id}. \\
|
|
|
|
\begin{table}[!h]
|
|
\centering
|
|
|
|
\begin{tabular}{|r|l|}
|
|
\hline
|
|
\textbf{Klasse} & \textbf{Funktion} \\
|
|
\hline
|
|
0x10 & Discovery Befehl \\
|
|
0x11 & Discovery Antwort \\
|
|
\hline
|
|
0x20 & Leseanforderung \\
|
|
0x21 & Antwort mit angefordertem Wert \\
|
|
\hline
|
|
0x30 & Schreibbefehl \\
|
|
0x31 & Antwort auf Schreibbefehl \\
|
|
\hline
|
|
\end{tabular}
|
|
|
|
\caption{Befehlsklassen bei RDM}
|
|
\source{https://www.soundlight.de/techtips/dmx512/dmx\_rdm.htm}
|
|
\label{tab:klassen}
|
|
\end{table}
|
|
~\\
|
|
|
|
\begin{table}[!h]
|
|
\centering
|
|
|
|
\begin{tabular}{|r|l|}
|
|
\hline
|
|
\textbf{Befehls-ID} & \textbf{Befehl} \\
|
|
\hline
|
|
0x0001 & Discovery \\
|
|
0x0002 & Mute für Discovery \\
|
|
0x0003 & Unmute für Discovery\\
|
|
\hline
|
|
0x0050 & Liste unterstützter Parameter \\
|
|
0x0051 & Parameterbeschreibung \\
|
|
0x0060 & Geräteinformationen \\
|
|
0x0081 & Herstellername \\
|
|
0x00C0 & Softwareversion \\
|
|
0x0400 & Betriebsstunden \\
|
|
0x0401 & Lampenstunden \\
|
|
0x0402 & Lampenzündungen \\
|
|
0x0403 & Lampenstatus \\
|
|
\hline
|
|
\end{tabular}
|
|
|
|
\caption{BefehlsID bei RDM}
|
|
\source{https://www.soundlight.de/techtips/dmx512/dmx\_rdm.htm}
|
|
\label{tab:id}
|
|
\end{table}
|
|
~\\
|
|
|
|
|
|
Durch die Mute- bzw. Unmute Funktion wird der Buszugriff zusätzlich unterstützt.
|
|
Erhält man auf einen Discovery-Broadcast eine Antwort, kann aus dieser die UID des Endgerätes entnommen werden.
|
|
Wird im Anschluss gezielt an dieses Gerät ein Mute-Befehl gesendet, antwortet es nicht auf künftige Discovery-Broadcasts.\\
|
|
|
|
Da alle Hersteller unterschiedliche Befehle unterstützen oder teilweise umfunktionieren, ist es erschwert, einen einheitlichen Monitor oder Interpreter zu entwickeln.
|
|
Der individuelle Funktionsumfang muss lampenspezifisch der Anleitung entnommen werden.
|
|
Der Lampenhersteller Robe beschreibt im Handbuch des BMFL Blade die BefehlsIDs \textit{ROBE\_DMX\_INPUT} oder \textit{ROBE\_WIRELESS\_UNLINK} und gibt ebenfalls in dieser Liste durch eine Fußnote an, andere Optionen für gewisse BefehlsIDs zu verwenden. \source{https://www.robelighting.de/res/downloads/user\_manuals/User\_manual\_Robin\_BMFL\_Blade.pdf}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
~\\
|
|
\subsection{Praxistest}
|
|
|
|
Die Veranstaltungssicherheit und -technik hat dankenswerterweise den Audimax der Technischen Universität Kaiserslautern zur Verfügung gestellt, um das RDM Protokoll in der Praxis testen zu können.
|
|
Hierzu wurde die bestehende Verkabelung aufgelöst, da sich zwischen Regiekabine und Beleuchterzug ein nicht-RDMfähiger DMX-Splitter befindet.\\
|
|
|
|
Im Beleuchterzug wurden zwei RDM kompatible Robe BMFL Spot und vier Eurolite ML56 LED Par ohne RDM Funktion verbunden.
|
|
Nach dem Aktiviern der RDM Funktion am grandMA 2 Steuerpult konnte hier direkt ein Fehlverhalten der ML56 beobachtet werden, welches sich ähnlich wie ein Busfehler zeigte.
|
|
Der Versuchsaufbau wurde daraufhin so verändert, dass lediglich die beiden BMFL an die grandMA angeschlossen worden sind.
|
|
Eine erste Spekulation ist die Missinterpretation des geänderten Startcodes von 0xCC für RDM anstelle des standardmäßigen 0x00.\\
|
|
|
|
Im veränderten Aufbau wurden beide BMFL nach einiger Zeit korrekt detektiert.
|
|
Auch wenn die grandMA einen limitierten Umfang der eigentlichen Möglichkeiten unterstützt konnten einige Sensorwerte gelesen und händisch interpretiert werden.
|
|
Alternativ wäre mit dem Robe RDM Communicator eine einfache herstellergebundene Möglichkeit gegeben, fertig interpretierte Werte zu erhalten.\\
|
|
|
|
Der Testaufbau hat gezeigt, dass es in diesem Fall nicht möglich ist, beliebige Lampen in einer einzigen DMX-RDM-Kette zu betreiben.
|
|
Würde man im Audimax die RDM-fähigkeit der BMFL nutzen wollen, müsste ein weiterer DMX-Strang in die Beleuchterzüge eingebracht werden.
|
|
Dieser Aufwand ist im Vergleich zu einer Ethernetverkabelung so verschwindend gering, dass es wirtschaftlich nicht zu vertreten wäre, DMX statt Ethernet zu verwenden.
|
|
Ethernet bietet im Vergleich zudem weitere Vorteile und Möglichkeiten wie beispielsweise eine Überwachung der Lampen über \abbr{SNMP}{Simple Network Monitoring Protocol} oder das Verbinden weiterer Geräte über trunk Ports.
|
|
Da eine Ansteuerung der Lampen aus der bestehenden Peripherie über sACN oder ArtNet problemlos möglich ist, entfällt die Notwendigkeit der klassischen DMX Verkabelung.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\newpage
|
|
\section{Hardware- und Softwareanpassung}
|
|
Der in der ursprünglichen Projektarbeit beschriebene DMX-Hat für den Raspberry Pi wurde modifiziert und ist verfügbar unter \url{https://git.agg-hosting.de/Erwin/DMX-Hat\_RasPi}\\
|
|
|
|
Einige Hardwareanpassungen wie eine zusätzliche galvanische Trennung des DMX Ausgangs, eine Erhöhung der Busspannung auf 5V und eine Montagemöglichkeit für einen 20mm Lüfter wurden einbezogen.\\
|
|
Die aktuelle Platine ist als Projekt für KiCad 6.0 verfügbar.\\
|
|
|
|
Softwareseitig wurde ein Lesen für eingehende Pakete implementiert, eine Auswertung wurde aufgrund der sehr Herstellerspezifischen Interpretationsweisen von RDM nicht durchgeführt.
|
|
|
|
|
|
|
|
|
|
~\\\\
|
|
\section{Fazit}
|
|
Insbesondere der Praxistest hat gezeigt, dass das Remote Device Management zwar viele Funktionen bietet, welche das Leben erleichtern, bei inhomogen Systemen aber oft zu Fehlern führt.
|
|
Gepaart mit einer Wünsch-Dir-Was Mentalität der Hersteller wurde hier jegliche Innovation bereits im Keim erstickt. \\
|
|
|
|
Der erste Versuchsaufbau im Praxistest konnte musste bei einer überschaubaren Menge an Endgeräten abgebrochen werden, was bei einer Skalierung in große Systeme nicht unbedingt Besserung vermuten lässt.
|
|
Auch wenn die Kommunikation im zweiten Versuch erfolgreich war, bleibt eine gewisse Skepsis gegenüber dem Protokoll.
|
|
Im Live-Betrieb wäre eine Lampenüberwachung zwar wünschenswert, unterliegt aber der Störungsresistenz des Gesamtsystems. \\
|
|
|
|
Im Ausblick auf die nächsten Jahre verschwinden hoffentlich immer mehr Endgeräte, die aktuell nicht in der Lage sind, RDM von DMX Paketen zu unterscheiden.
|
|
Mit ausbleibenden Störungen auf dem Bus könnte RDM allmählich Fuß fassen.
|
|
Ein vollständiger Ersatz durch Ethernet ist jedoch nicht zu vernachlässigen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\end{document} |