RDMX ???

    Doch geht über die normale DMX Leitung, da wird dann ein firmeneigenes Protokoll "eingemischt".
    Dafür benötigst du wahrscheinlich ein spezielles Gerät zum programmieren wie den MP2 von Martin.
    Mit dem lassen sich auch die Macs der Reihe nach Adressieren ...

    Für Rückmeldungen braucht es (leider) nicht mehr die Pins 4+5:
    In der aktuellen Version von RDM werden die Pins 4+5 nicht für die Rückmeldung vorgesehen, da laut Komission zu viele Hersteller diese Pins für eigene Zwecke missbrauchen, sofern sie überhaupt vorhanden sind. Dafür erfolgt die Rückmeldung über die normalen Datenleitungen. Dabei werden die Daten durch einen alternierten Startcode markiert, so dass sie von nicht RDM-Geräten schlicht ignoriert werden. Dies lässt zwar einen wesentlich geringeren Durchsatz an Rückmeldedaten zu, aber scheinbar der beste Kompromiss.
    Inwiefern RDMX aus der Anzeige mit RDM gleichzusetzen ist, weiß ich nicht, zumal ich keine Daten dazu auf der Seite gefunden habe. Letztendlich gehört die Adressierung zu einer der Standardfunktionen von RDM. Es mangelt nur noch (von Wybron abgesehen) an passenden Controllern und Interfaces, die eine intuitive Verwaltung eines RDM-Netzwerks zulassen (davon abgesehen, dass es auch noch nicht allzu viele wirklich RDM-taugliche Geräte gibt).
    Dass sich über firmeneigene Sonderwege auch diese Funktionen abrufen lassen, hat ja Leopold mit dem Verweis auf die MP-2 von Martin, wo ein systemeigenes Signal dafür sorgt, dass auch nur die passenden Lampen in einer DMX-Leitung auf die Anweisungen reagieren, bereits geklärt.
    Für RDM-Spezifisches müsste uns normal Denis Hessberger mehr erzählen können, da er meines Wissen ein wenig beim Wybron-System involviert war.

    Liebe Grüße
    Mathias Burger

    Aber ich kann den sinn einer solchen vorgehensweise nicht erkennen.

    Schön is es zwar, das ich am Pult DMX Adressen einstelle und dann auf die mit RDMX Geräte Verweise. Aber woher soll das Pult wissen, welcher Spot der richtige ist?

    ID Adressen vergeben? Dann könnt ich ja auch wieder gleich die DMX Adresse einstellen,

    Ich hoffe ihr versteht was ich meine.

    Mfg
    Fabian

    RDM geht weit über das Adresseinstellen hinaus. Zur Identifizierung bekommt jedes Gerät weltweit eine einmalige ID (zu dem Zweck bekommen die Hersteller eigene ID-Bereiche zugeteilt). Letztendlich sind in RDM fast alle Informationsrückmeldungen und Einstellungen möglich, die ich bisher am Display vornehmen muss.
    Bei der kleinen Rock'n'Roll-Show mag der zwar der Aufwand der Einrichtung des RDM-Netzwerks den Nutzen übersteigen, aber bei jeder Dauerinstallation (und dazu zähle ich auch größere TV-Produktionen und Festivals, die sich über 7 und mehr Tage von Aufbau bis Showende ziehen.

    Was machst Du bisher, wenn ein MovingLight mit einer Fehlermeldung im Rigg blinkt? Sicher nicht mit dem Fernglas die Meldung am Display auslesen, sondern warten, bis Du einen Rigger hochschicken kannst. Vorher kannst Du aber keine Ersatzteile usw. organisieren. Was machst Du, wenn Du Dein Adressmanagement ändern musst, weil Du die Line-Zuordnung ändern willst oder musst? Warten bis Du einen Rigger hochschicken kannst.
    Mit RDM kannst nach einmaliger Konfiguration jeder Zeit den Status und Fehler von MovingLights (oder anderem RDM-Kram) auslesen und fast sämtliche Einstellungen ändern - und das alles bequem vom RDM-Interface am FOH aus.

    Insgesamt halte ich schon die Durchsetzung von RDM als einen großen Schritt in unserem Bereich. Es sind zwar noch einige Fragen offen (wie sieht ein intuitives RDM-Interface aus?) und nicht jeder kann einen wirklichen Nutzen daraus siehen, aber es gibt sehr viele Bereich, wo RDM den Service und Unterhalt eines Systems entscheidend vereinfacht und beschleunigt. Und wer RDM nicht mag, kann es schlicht ignorieren, da es schlicht ins DMX integriert ist, also keine Entweder-Oder-Lösung ist.

    Liebe Grüße
    Mathias Burger

    Nein, die einzige Gemeinsamkeit ist die Bidirektionalität, aber das sagt alleine nichts für die Funktionalität aus. Bidirektionaler Datenverkehr ist auch im Lichtbereich nichts Neues: diverse Firmen (nicht nur Vari-Lite) haben eigenständische bidirektionale Protokolle entwickelt. So ist die Dimmerüberwachung über das Steuernetzwerk heute eine Standardapplikation in jedem größeren Theaterhaus.

    Dass das Vari-Lite Protokoll im Gegensatz zu RDM überhaupt nichts magisches hat, zeigt alleine dieses Statement von Don Holder (König der Löwen):
    "The moving lights were initially controlled via the Vari-Lite Artisan system. When we upgraded the moving light package, we also made the switch to the Vari-Lite Virtuoso console, which allowed us to control our moving light rig via DMX as opposed to VL protocol. This allowed us to liminate much of the out-of-date Vari-Lite data distribution network and reatly simplified installation and maintenance."

    Warum ist also RDM bis auf die Bidirektionalität nicht mit dem Vari-Lite-Protokoll vergleichbar:
    RDM besitzt nicht nur die Möglichkeit zur Statusrückmeldung, sondern auch zu Lampenkonfiguration.
    RDM kommt ohne spezifische Transmitterhardware aus: einfache Standard-DMX-Verkabelung. Lediglich die Splitter und Booster müssen die RDM-Norm erfüllen, damit sie die Daten mit modifiziertem Startcode durchlassen.
    RDM ist nicht spezifisch, sondern "Allgemeingut" wie DMX, Artnet usw.
    RDM ist DMX-kompatibel, so dass sowohl "intelligente" als auch "dumme, stumme" Geräte gemeinsam auf einer Linie betrieben werden können. Gleichzeitig können die "intelligenten" Geräte sowohl mit als auch ohne RDM betrieben werden.

    Dementsprechend würde ich mich soweit aus dem Fenster lehnen und behaupten, dass Welten zwischen dem Vari-Lite-Protokoll und dem heutigen RDM liegen. Und dass das jenes Protokoll alt, aber nicht wirklich gut war, beweist nicht nur das Statement, sondern auch die Tatsache, dass auch Vari-Lite sich sehr schnell DMX gebeugt hat.

    Liebe Grüße
    Mathias Burger

    Dafür ist ein RDM-Telegramm derart aufgeblasen (ASC, SubSC, Zieladresse, Quelladresse, CMD, Parameter, Checksum...), dass für das Puffern einer Nachricht sehr viel SRAM draufgeht. Ich denke, RDM wird sich daher nur anfangs bei Edelherstellern durchsetzen, wo es nicht auf ein paar Cent in der HW ankommt.

    Ich habe die Spezifikation da und finde sie etwas oversized für die üblichen 8051er, AVRs oder PICs. Niemand wird extra für dieses Feature auf ARM umsteigen...

    Viele Grüße,
    hendrik

    Zitat von "Henne"

    Ich denke, RDM wird sich daher nur anfangs bei Edelherstellern durchsetzen, wo es nicht auf ein paar Cent in der HW ankommt.


    Die eigentlich auch die einzigen sind, die die Märkte bedienen, für die RDM von wirklichem Nutzen ist.

    Liebe Grüße
    Mathias Burger

    Noch mal zum mitkommen.... jedes Gerät hat eine eigene feste ID die ich dann einer DMX Adresse zuordne.... richtig?

    Über den Rückweg bekomme ich dann auch Meldungen aus dem Gerät und kann dieses Konfigurieren.... richtig?

    Wieso verabschiedet man sich nicht direkt vom guten alten XLR Stecker und geht auf Ethernet???

    greetinxx

    Toto

    die Gründe sind doch klar: du kannst das auf kleineren Baustellen auch mal komplett ohne Rückkanal benutzen - Old School DMX quasi.

    Denn: auch was ich im Audio Bereich zum absoluten Erbrechen finde: Egal ob das Neutrik Kondom übem Stecker ist oder nicht - es geht viel zu schnell kaputt; viel zu anfällig... und wenn man nicht mindestens den Stecker austauscht, wird sich da in naher Zukunft auch wohl nichts bei ändern.

    Als ich mich da einmal ein bisschen drüber schlau gemacht habe, finde ich diese Erweiterung eigentlich sehr sinnvoll ... Das hat so ein bisschen was wie den Umstieg von USB 1.1 auf 2.0 ;)

    Du brauchst nicht wirklich dafür neue Lampen und Pulte.
    Teilweise sind die aktuellen MovingLights schon auf RDM vorbereitet, alte lassen sich zumindest im Grundumfang mit einem Chip von z.B. Wybron nachrüsten. Hinsichtlich der Pulte sehe ich auch nicht wirklich die Probleme, da zum einen eine Verwaltung des RDM-Netzes über einen Laptop außerhalb des Pultes vorstellbar ist und die Pulte, die die RDM-Verwaltung selbst übernehmen wohl schon in der Größenordnung einer GrandMA, Maxxyz, Hog usw. sein zu müssen, um überhaupt die notwendige graphische Oberfläche zu bieten. Und in dem Moment reden wir eigentlich mehr über die Software, die geschrieben werden muss als komplett neue Hardware.
    Letztendlich ist mit ACN auch ein entsprechendes Netzwerkprotokoll auf dem Weg in unsere Branche, allerdings wird dieser Umstieg weit komplexer und schwieriger - alleine weil es dann wohl kein einfaches Daisy-Chaining wie zu DMX-Zeiten geben wird (davon abgesehen, dass ich die roadtauglichen Netzwerkkabel, wie ich sie bisher für die Artnet-Verkabelung eingesetzt habe, ungern fürs Verkabeln im Rigg benutzen würde).

    Liebe Grüße
    Mathias Burger

    eine kleine anmerkung zum thema "daisy chain" bei netzwerkprotokollen:
    das kann bzw. könnte auch so gelöst werden wie es ADB gerade beim warp-profiler vormacht - es ist in jedes gerät einfach ein 2-port-switch integriert und schon kann man einfach schön von jedem gerät zum nächsten durchlinken - quasi ein uplink nach dem anderen. das erste gerät in der strecke könnte somit auch einfach als dhcp konfiguriert werden und vergibt dann auch noch die adressen an die nachfolgenden geräte. funktioniert beim warp angeblich noch nicht sooo toll, aber es geht wohl... vom prinzip her ja auch recht logisch

    Damit haetten wir dann ja schon eine der Herausforderungen von ACN geloest - wenn es dann mal endgueltig als Standard verabschiedet wird...
    Fuer mich das groesste Fragezeichen - egal ob RDM oder ACN - ist nachwievor die Zuordnung von interne Geraete-ID und DMX-Adresse bei RDM bzw. IP-Adresse und Geraete-ID im Pult bei ACN. Bei Moving Lights kann ich mir noch eine Art Highlight-Funktion vorstellen, bei Scrollern, Goborotatoren usw. wird die Identifzierung des Geraets schon schwieriger. Die Herausforderung bei der Umsetzung ist ja, dass der Aufwand fuer das Einrichten eines RDM-/ACN-Netzwerks nicht hoeher als der praktische Nutzen aus den neuen Protokollen - und daran zerbrechen sich wohl momentan so einige bei den Herstellern ihren Kopf...

    Liebe Grüße
    Mathias Burger

    LightFaden:

    Das Pult grenzt die Geräte-Adressen (können als MACs interpretiert werden) über Discovery-Messages immer weiter ein und mutet eindeutig identifizierte Geräte.

    Am Ende bleibt eine Liste der MACs der angeschlossenen Geräte übrig.

    Diese können nach Name, DMX-Footprint, Status, etc. abgefragt werden.

    Zum Ändern der Startadresse schickst Du dann eine Message an das Gerät mit zuvor identifizierter MAC mit der neuen Startadresse.

    Kapitel 7 der E1.20 beschreibt eigentlich recht ausführlich das Device Discovery...

    Viele Grüße, Hendrik

    Wie das theoretisch erfolgt, habe ich mir schon mühsam mit dem schönen ANSI-Heftchen reingezogen. Einfach ist das Prozedere aber nur, wenn ich bereits richtig adressierte Lampen und ein passenden Patch im Pult habe, denn dann ist die Zuordnung zwischen gepatchtem Gerät und echtem Gerät "da draußen" einfach. Wie aber eine Remote-Konfiguration eines Riggs, bei dem die Lampen frisch aus dem Check alle mit Startadresse 1 versehen sind, ist leider nicht mehr ganz so trivial. Das wird zwar nicht die Standardanwendung sein, da es wohl schneller sein wird, die Geräte per Hand zu adressieren, aber eine Herausforderung für die Entwickler von RDM-Interfaces.

    Liebe Grüße
    Mathias Burger