RDMX ???

Diese Ortung würde auch nicht wirklich das Problem lösen:
Gib drei Operatorn das gleiche Rigg - jeder wird das Rigg nach einem anderen Schema mit IDs versehen, so dass drei verschiedene Lösungen rauskommen. Und die eigenen Präferenzen in für ein Lichtpult verwendbare, eindeutige Regeln zu fassen, wäre umständlicher als einfach dei ID Zuordnung von Hand zu machen.
Ich habe mich für 6 Monate für die Firma mit dem gelben Dreieck das Thema RDM beleuchtet: Ein Operator würde sich niemals dem Schema eines Lichtpults unterordnen und für keinen Operator liegt der zentrale Mehrwert in der Autoadressierung. Remote-Adressierung ja, Autoadressierung nein. Nicht umsonst kennen Lichtpulte auch noch keinen "make art!" Button.

Automatische Adressierung hin oder her - eines muss immer noch gemacht werden:
Die Installation im Rigg. Also es wird immer noch irgend jemanden geben der das Teil irgend wann einmal (meistens nach einem Plan) an die passende Stelle hängt.

Das wäre doch der Ansatzpunkt:
Jedes Gerät bekommt einen kleinen RFID Chip oder was vergleichbares der eine weltweit einmalige ID Nummer enthält.
Derjenige der das Gerät aufhängt und bisher adressiert ließt diesen Chip aus und vermerkt so wo das Gerät hängt. Das geht sogar ohne Strom am Gerät und mit einem kleinen Industrie PDA am Handgelenk.
Postion am PDA anklicken, Gerät anscannen und fertig.

Diese Info geht ans Pult das den Plan aus dem CAD bereits kennt und "bucht" das Gerät dann an der passenden Stelle ein.

Keine falschen Adressen oder falsche patches weil anstelle eines MAC2000 ein MAC250 installiert wurde
Wie der Operator die Geräte dann nennt und auf dem Pult anordnet ist seine Sache.

chws Lösung würde funktionieren.

Interessant finde ich, dass sich hier fast alles um die Funktion des Autoadressing bzw. Autopatching, wobei das eigentlich eines der unwichtigsten Features von RDM ist - zumindest ist das das Resultat von 6 Monate Interviews, Umfragen, Testszenarien etc.
Von schwierigen Geraeten wie Scrollern reicht ein einfaches Highlight fuer die einzelnen Geraete, dass ein Operator die entdeckten Geraete seinem Patch zuordnen kann. Das einzige Alternativszenario, das ueberzeugen konnte - da eben on the road keiner mit Scannern und anderen zusaetzlichen Tools hantieren moechte, die viele neue Fehler durch Fehlbedienung etc. produzieren, hantieren miechte - war die Variante, dass das Pult ueber den Abgleich von Pultpatchmit den ruckgemeldeten Adressdaten eine automatische Zuordnung uebernimmt.
Das entscheidende Feedback war: RDM ist nur dann interessant, wenn zur Konfiguration nicht bestehende Arbeitsablaeufe total ueber den Haufen geworden werden und nicht arbeitsbestimmend fuer den Operator wird.

Interessant.
Würde der Vorgang der Erfassung per Scanner nicht mehr Fehlerquellen
eliminieren als erzeugen? Und dabei nicht auch Zeit und Geld sparen?

Bisher muss ja auch jemand die passenden Adressen aus einem Plan herauslesen und das eingeschaltete Gerät addressieren. Das dauert doch länger und wenn die Adresse falsch eingestellt wurde muss wieder jemand ans Gerät.
Das einfache "anpiepsen" eines Gerätes sollte doch jede angelernte Hilfskraft ohne Fehler hinbekommen.

Das "Autoadressing" ist jedoch sicherlich nicht das wichtigste, Statusmeldungen und aussagekräftige Fehlermeldungen mit passendem Logfile wären gut.

Super wäre die Möglichkeit der Fernkonfiguration (Einstellen der Modi, Lüftersteuerung, Auslesen der Lampen- u. Betriebsstunden usw.)
Es ist ärgerlich wenn man sich mit einer Anleitung durch diverse Menüs kämpfen muss um einen Betriebsmodus richtig einzustellen.

Was soll denn sonst am Wichtigsten sein?

Statusmeldungen?
Wenn das Gerät in der truss hängt und den Geist aufgibt, kann man vielleicht schneller Ersatzteile bestellen - kaputt bleibt es trotzdem.
Und wenn es überhitzt: Was soll man machen? Laufen muss es trotzdem...

Firmware Update?
Die Firmen waren sich nicht einig - deshalb ist keine klaren Vorgaben erhältlich...

Dimmerkurven, Min. und Max.-Begrenzungen?
Auch hier nichts klares, so dass jede Fa. wohl spezifische PIDs einsetzen wird.

Ein Gespräch mit K. Ruling (Schreibweise?) hat mich ziemlich desillusioniert bzgl. RDM.

Wo Du schon schreibst, Mathias:
Wie empfindlich sind eigentlich Eure Geräte hinsichtlich der Time-Outs bei RDM-Paketen? Mit den üblichen FTDI-Wandlern hat man dank Windows Schwankungen von >1ms wodurch ich teilweise gegen die Spezifikation verstoße...

Viele Grüße,
Hendrik

Also diese ganzen Ideen mit GPS oder irgendeiner anderen automatischen Positionserkennung halte ich für Quatsch!

Die Autoadressierung ist nur dahingehend interessant, als dass die Geräte nicht vorher oder im Rigg adressiert werden müssen. Ich gehe ans Pult, starte die Erkennung der Geräte und die Lampen melden sich am Pult an und ich muss den Lampen nur noch die IDs zuordnen. Das passiert dann vorzugsweise dadurch, dass eine Lampe blinkt und ich die ID zuweise. Dann passiert das gleiche mit der nächsten usw.

Ob das wirklich Zeit spart oder wirklich praktikabel ist, kann ich nicht sagen. Wo es sicherlich hilfreich ist, wenn zwei Geräte versehentlich auf die gleiche Adresse gepatcht wurden und ich das nachträglich ändern möchte.

Auch sinnvoll halte ich Rückmeldungen wie Lampenstunden und anderer Statusmeldungen. Gerade bei Festinstallationen.

Mal eine andere Frage:

Was für Pulte/Controller auf dem Markt sprechen denn bereits RDM?
Derzeit seh ich da nur das RDM-Dongle von Enttec, das ich mit 400EUR etwas unverschämt finde...

Ich würde gern meine Arbeit mal verifizieren.

Zitat von "jamhot"

Die Autoadressierung ist nur dahingehend interessant, als dass die Geräte nicht vorher oder im Rigg adressiert werden müssen. Ich gehe ans Pult, starte die Erkennung der Geräte und die Lampen melden sich am Pult an und ich muss den Lampen nur noch die IDs zuordnen. Das passiert dann vorzugsweise dadurch, dass eine Lampe blinkt und ich die ID zuweise. Dann passiert das gleiche mit der nächsten usw.

Ob das wirklich Zeit spart oder wirklich praktikabel ist, kann ich nicht sagen. Wo es sicherlich hilfreich ist, wenn zwei Geräte versehentlich auf die gleiche Adresse gepatcht wurden und ich das nachträglich ändern möchte.

stell dir vor, 120 lampen bewegte lampen, dazu noch diverse farbwechsler und so weiter, die blinken nun alle mal durcheinander auf und du musst ne adresse vergeben, erst zählen, dann im plan nachsehen welche lampe die adresse haben soll.. das dauert deutlich länger als die vorher kodiersten lampen aufzuhängen bzw bein hängen die ID zu vergeben!

statusmeldungen der lampen am pult zu sehen, hat vorteile, jedoch sitzt am pult ein operator, der das wiederum zum tec weitergeben muss, besser wenn sich der tec mit einem service system ins netz klinken könnte.

Also im Prinzip genau das, was ich gesagt habe.

Eine remote-Verbindung im Internet wäre nicht unmöglich. Oder war nur ein eigenständiger RDM-Controller gefragt?

Bleibt die Frage nach verfügbaren RDM-Pulten/-Dongles.

Zitat von "jamhot"

Also im Prinzip genau das, was ich gesagt habe.

jups, das würde einfach nur stressn.

Zitat von "Carm"

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

Das funktioniert leider nicht so, wie wir das alle gern hätten weil es bei mehr als ein paar Lampen gegen die 5-4-3-Regel in der Ethernet-Spezifikation verstößt und zu exzessiven Resends und Timing-Chaos führt.
Häng mal 10 Barco-Projektoren (bei denen das mMn schon recht gut implementiert ist) so zusammen und versuche sie per Projector Toolset möglichst schnell hintereinander zu zünden (Szenario Stromausfall...). Da hat es teilweise Verzögerungen von bis zu 10 Sekunden, und die Geräte starten auch nicht mehr zwangsläufig in der Reihenfolge in der die Befehle gegeben wurden.
Ethernet mit seiner inhärenten Sternstruktur passt halt nicht zur heute üblichen Busverkabelung in der Lichttechnik. Und ohne QoS gibts auch keine garantierten Höchstlaufzeiten...