Wieso?
Du machst am Pult eine Discovery.
Du erhältst eine Liste der angeschlossenen Geräte (und im besten Fall richtet sich das Pult auch gleich auf die Geräte ein).
Du gibst im Pult für jedes Gerät die Startadresse ein.
Das Pult konfiguriert die Geräte.
Fertig.
Viele Grüße, Hendrik
Du machst am Pult eine Discovery.
Du erhältst eine Liste der angeschlossenen Geräte (und im besten Fall richtet sich das Pult auch gleich auf die Geräte ein).
Du gibst im Pult für jedes Gerät die Startadresse ein.
Und hier ist doch der Knackpunkt: Jetzt weiß ich nur, welche Geräte-IDs und Geräte ich im Rigg habe. Was ich nicht weiß, ist welche ID zu welchem Gerät in meinem 3D-Rigg gehört (zumindest nicht, wenn ich nicht etwas im Kapitel 7 übersehen habe). Aber diese Zuordnung findet ja auch außerhalb des Pults statt, da ja auch mein Pult (ohne Visualizer) nicht weiß, wo das Gerät hängt - und letztendlich leitet sich die Gerätenummer, die ich zur Anwahl im Pult benutze aus der räumlichen Anordnung ab und ist nichts, was das Pult von sich machen kann. Und genau diese Zuordnung ist für mich als Operator von elementarer Bedeutung - schließlich reicht es nicht, dass ich weiß, dass das Gerät mit der UID xyz einen FbET hat, sondern ich muss auch wissen, wo das Gerät im Rigg hängt, um einen Rigger hinzuschicken.
Vielleicht reden wir aneinander vorbei, aber für mich liegt die Unklarheit jenseits der technischen Umsetzung.
Da hast Du Recht.
Einziger Ausweg, den ich seh:
Durchnummerieren der Geräte und die Gerätenummern in dem Plan Deines Riggs festhalten.
Da hast Du Recht.
Einziger Ausweg, den ich seh:
Durchnummerieren der Geräte und die Gerätenummern in dem Plan Deines Riggs festhalten.
Na viel Spaß, wenn jedes Gerät weltweit nen anderen Code hat, sind das mindestens Zahlen in der Länge von Mobiltelefonnummern...
Bevor ich da zu jedem Gerät hin gehe und eine solche abschreibe, adressiere ich das Gerät lieber gleich.
Aber wäre es nicht möglich, wenn man alle Geräte in einer Linie (also nur in/out benutzen, ohne Booster) schalten würde, und dann von der Steuerung aus ein erstes Signal gibt, welches das erste Gerät in der Reihe ließt, ohne dieses auf den Ausgang weiter zu leiten, und dann der Stewuerung seine ID schickt, und erst dann das Signal an das nächste Gerät weiter gibt,...
Wenn das so bei jedem Gerät machen würde, hätte man ja die IDs in der richtigen Reihenfolge.
Würde beim ersten einlesen der Geräte nur etwas dauern.
Bringt nicht wirklich viel, da zu einem schon die von Dir genannte Einschränkung besteht, dass Du keine Booster benutzen kannstn und zum anderen die Zuordnung auch nur bedingt einfacher geht. De facto sieht es in der Realität wohl so aus, dass ich ein RDM-Netzwerk vorerst wohl nur dann in überschaubarer Zeit einrichten lässt, wenn man selbst die zurückgemeldeten Geräte über die manuelle eingestellte DMX-Adresse erkennen kann.
Von diesem Engpass abgesehen halte ich dennoch RDM für eine wertvollle Weiterentwicklung, auch wenn es wie schon mehrmals erwähnt nicht die ganz Branche beeinflusst, sondern nur einen Teil davon.
Zur praktischen Umsetzung: Natürlich muss man nicht zum Gerät hingehen und die Nummer abschreiben, diese meldet das Gerät dem Pult oder RDM-Interface (muss nicht zwangsweise ein Gerät sein), was dann halt Handarbeit bleibt, ist die Geräte auch physisch zu identifizieren (welches Gerät geht an, wenn ich UID xyz auf open white setze. Bei Scrollern, Goborotatoren und anderem Schnickschnack wird es schon schwieriger) und diese dann mit der Geräte-ID (die sich in der Regel aus dem Lichtplan ergibt, z.b. Mac 700 SL nach SR ID 1-16, Mac 250 Wash Floor SL nach SR ID 21-30 usw.), im Patch des Pultes verknüpfen. Diesen Schritt muss ich ja auf jeden Fall machen, denn wenn ich diesen Schritt der pultinternen ID-Vergabe auch automatisch machen lasse, wünsche ich nur viel Spaß beim Geräteanwählen und Gruppen erstellen. Aber diesen Verknüpfung muss ich nur einmal machen und dann habe ich auch ohne Zettel und Stift eine direkt abrufbare Zuordnung von UID und echtem Gerät, da ich ohne Probleme anhand der Pult-ID (die ja meiner Phantasie entsprungen ist) die Rückmeldung dem richtigen Gerät zuordnen kann.
Natürlich muss man nicht zum Gerät hingehen und die Nummer abschreiben, diese meldet das Gerät dem Pult oder RDM-Interface
Dennoch werde ich zuvor die Nummern abschreiben müssen, damit ich weis wenn am Pult 20 Mac2K mit den IDs XYZ ankommen, und ich zuvor die IDs in der physikalisch richtig hängenden Reihenfolge abgeschrieben habe, welches Gerät welchen Platz am Pult einnimmt, damit Reihenfolge am Pult und im Rig übereinstimmen. Oder etwa nicht ?
Nein. Du hast letztendlich im Pult einfach zwei Datensätze, die Du nur gegenseitig zuordnen musst: Die UIDs der einzelnen Geräte, die das Pult per RDM-Discorvery entdeckt hat, und die Pult-IDs, nach denen Du die Scheinwerfer für die Programmierung sortierst. Wie dabei das Vorgehen dann ist, ist genau die Frage für die Entwicklung der RDM-Interfaces:
Entdecke ich die Geräte und weise den UID (nach Identifizieren des Geräts etwa durch HighLight) die Pult IDs zu oder habe ich ein fertiges Patch im Pult, bekomme die UIDs zurückgemeldet und weise dann (wieder nach Identifizieren des Geräts) die UID dem der Pult ID zu (also quasi inverser Weg).
Ein guter Mittelweg wäre, wenn es die Pult oder Interface Entwickler hinbekommen (letztendlich ist es nur ein Stück Software), dass bei fertigem Pult-Patch und fertig adressiertem Rigg, die "RDM-Verwaltungssoftware" (ob im Pult oder als externes Interface) automatisch von den entdeckten Geräten die DMX-Adresse abfragt (problemlos per RDM möglich) und zusammen mit dem Univers automatisch dem passenden Gerät im Pult zuordnet, nachdem aus Startadresse und Univers eine eindeutige Zuordnung möglich ist.
Machbar ist die Einrichtung eines RDM-Netzweks auf jeden Fall, es kostet halt nur eben etwas Zeit, bietet dafür die Kontrolle des ganzen Riggs von einem zentralen Punkt aus.
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.
Und dann fällt das erste Gerät in der Kette aus... :shock:
In der Netzwerktechnik sind ja leider Gottes fast alle Komponenten aktiver Natur, da würde ein Ausfall unter Umständen fatale Folgen haben.
Ich habe mir den Thread hier durchgelesen und verstehe das Problem nicht richtig. Warum vergibt man nicht weltweit eindeutige IDs?
Bsp: Typ, Hersteller, Modell, baureihe, fortlaufende Nr.
Aufgeteilt in mehrere Gruppen, die ersten Ziffern sind fest vorgeschrieben (z.B. für den Typ oder den Hersteller) die letzten kann der Hersteller beliebig vergeben.
Dann braucht es nur noch einen genormten Standart zum Austausch dieser Geräteinformationen und schon funktioniert das. Auf dem Pult/rechner sind diese Informationen hinterlegt, das Pult sendet ein spezielles Signal und alle angeschlossenen Geräte übermitteln Ihre IDs. Dann erscheinen auf einer Liste alle Geräte, sortierbar nach Hersteller, Typ, Modell usw. Die Identifizierung kann dann recht einfach erfolgen, da jedes Gerät eine Weltweit eindeutige ID besitzt die in der Bibliothek im Pult hinterlegt ist. Dem Gerät liegt beim Kauf eine entsprechende Datei bei. Von der Software her könnte man jedem Gerät dann eine eigene Firmeninterne Kennzeichnung verpassen und diese in der Datenbank mit oben genannter ID verknüpfen usw. usf.
In anderen Bereichen funktioniert das so - oder zumindest so ähnlich schon längst (z.B. Profibus oder HART Protokoll in der Messtechnik).
Gegenüber der DMX Verkabelung via XLR DaisyChain hätte es aber einen Vorteil. Störungen aufgrund der Kabellänge könnten nicht auftretten, weil jeder Switch auch ein Verstärker darstellt.
Aber egal ob XLR oder Ethernet, DaisyChain verkabelung hat immer die größere Gefahr eines Ausfalls.
Aber bei Ethernet z.b. könnte man an strategisch wichtigen Punkten beim o.g. Beispiel einfach einen WLAN AP setzen anstatt eines Switches. Hätte den Vorteil dass ab man so ein Backup schaffen kann was auch in beide Richtungen arbeitet.
Ich habe mir den Thread hier durchgelesen und verstehe das Problem nicht richtig. Warum vergibt man nicht weltweit eindeutige IDs?
Das Problem liegt auf einer ganz anderen Ebene: Selbst wenn Du anhand der UIDs wuesstest, dass Du 20 Mac 2000 im Rigg hast, weisst Du noch lange nicht ohne weiteres, welche UID zu welchem der jeweils 20 Mac 2000 im Rigg gehoert und welcher UID welche Geraetenummer des Pults zugewiesen werden soll.
Die UID an sich sind einmalig, aber eine feste Verschluesselung der Geraete wuerde obiges Problem auch nicht loesen. De facto macht RDM das Leben einfacher, nimmt einem aber nicht alle Arbeit ab.
OT: Der einzige Datensatz, der das Problem komplett loesen koennte, waere, wenn die Geraete ihre 3D-Koordinaten senden wuerden, dann koennte ich zumindest auf einen Blick sie physisch zuordnen. Das Problem der Zuordnung von UID auf Pult-ID waere damit aber immer noch nicht geloest (ausser auf den oben beschriebenen Wegen), da jeder Operator seine eigene Art und Weise hat, den Scheinwerfern die Pult ID zuzuweisen.
Hmm .. das Problem lässt sich vielleicht am ehesten am Pult lösen. Selbst wenn man >100 Wackler in der Decke hat, könnte man doch einen Patchmodus laufen lassen in der jede Lampe nacheinander eine bestimmte Position anfährt und man dann die jeweilige Patchnummer eintippt.
Die halbe Stunde kann man doch in Kauf nehmen oder ?
Bevor wir ins Detail gehen, empfehle ich zuerst die Lektuere der ANSI-Norm.
Ansonsten wird es etwas muehsam hier die Engpassfaktoren zu erlaeutern. Alleine schon die Tatsache, dass wegen der Eingliederung des Datenrueckflusses auf Pin 2+3 statt 4+5 die Datenrate wesentlich geringer ist, verlangsamt die Discovery der Geraete schon. Praktische Loesungsmoeglichkeiten gibt es in jedem Fall (und dass es fuer MovingLights am einfachsten ist, habe ich ja schon gleich zu Beginn beschrieben. nur beim Goborotator z.B. muesste der Scheinwerfer dazu schon eingerichtet sein und auch angeschaltet sein, ehe man in irgendeiner Weise ueberhaupt eine Reaktion des Geraets sehen koennte, gleiches gilt fuer Farbwechsler).
Wenn das Thema so einfach waere, gaebe es wohl schon mehr Applikationen als die von Wybron...
Auch wenn es ein recht alter Topic ist und man ja eigentlich nicht schlafende Hunde wecken sollte, erlaube ich mir, da das Thema eher an Aktualitaet gewinnt, ihn noch mal hochzuholen.
Nachdem ja hier auch das Thema der Netzwerkprotokolle angeschnitten wurde und mittlerweile auch ACN den Weg durch die ESTA gefunden hat, hier eine interessante Einschaetzung der USITT zur Zukunft von DMX:
Will ACN replace DMX512?
No. ACN (The ESTA Architecture for Control Networks) is more formally known as ANSI/ESTA E1.17, Entertainment Technology - Multipurpose Network Control Protocol Suite. It is intended to provide the next–generation standard for manufacturer interoperable lighting control over high bandwidth networks that support UDP/IP (like Ethernet) and related protocols.Many of the devices in an ACN system will still be DMX512 devices. At each Lighting Position a gateway (“black box”) converts from ACN to DMX512/RDM to daisy–chained legacy DMX512 devices and RDM enabled devices. While many devices such as Dimmer Racks and Media Servers will accept ACN directly, most end use devices will still be simpler, lower cost DMX512 or DMX512/RDM devices.
Quelle: http://www.usitt.org
Letztendlich sieht ACN zunaechst auch erstmal nichts anderes vor, als die DMX/RDM-Daten -aehnlich wie es jetzt bei Protokollen wie ArtNet geschieht- per Netzwerksignal zu streamen.
Um's mal wieder hochzuholen 
"Henne" hat inzwischen anscheinend was dazu entwickelt, Open RDM!
Was für Geräte unterstützen RDM eigentlich mittlerweile?
ich kenn das von den neueren Robe geräte (Colorspot 700 zB) - dafür haben die ja mitlerweile einen eigenen Dongle entwickelt.
(den gibts aber wohl noch nicht zu kaufen)
Moin,
wo ihr schon meine RDM-Lib entdeckt habt:
Könnte mal jmd. versuchen, mit demPC-Interface ein offizielles RDM-Gerät anzusprechen? Bislang haben sich ja nur Komponeneten von mir miteinander unterhalten, wodurch Denkfehler von mir im Protokoll unentdeckt geblieben sein könnten...
Ach ja: OpenDMX ist nicht kompatibel zu meiner SW, da Enttec die Schaltung verbockt hat. (Das automatische Port-Turnaround bleibt dort ungenutzt...)
Viele Grüße,
Hendrik
Um nochmal zurück zur Zuordnung Mac-im-Rig -> Mac-ID-im-Pult zu kommen:
Um dies zu automatisieren muss entweder das Pult messen wo (welche Entfernung/welche Winkel) die Macs sind oder aber die Macs sagen dem Pult welche geographischen Koordinaten sie haben.
Ersteres wäre z.B. über eine Laufzeitmessung möglich (Mac schickt ein Ultraschall-signal aus, Pult misst mit 2 Sensoren - ähnlich der Ortung von Geräuschen beim Menschen)
Zweiteres könnte mit einem GPS-Empfänger gelöst werden. Das Pult "scannt" die Datenleitung nach Geräten ab und sendet dann jedem gefundenen Gerät den Befehl seine GPS-Daten zum Pult zu senden. Mit etwas intelligenter Software lässt sich dann eine Zuordnung vom Mac zur Mac-mit-position-im-Pult-ID machen.
Problem wird dabei die Ungenauigkeit von GPS und der teilweise recht schlechte Empfang innerhalb von Gebäuden sein. (Allerdings wäre dies ein guter Diebstahlschutz sofern das Gerät seine Position via Handy-netz .ä. ausgeben kann - egal wo das Gerät ist: man findet es!)
Die Umsetzung von so einem Konzept lässt sich natürlich nur machen wenn alle Hersteller sich auf eine Metode & Standard einigen und umsetzen. Daran wird es allerdings definitiv scheitern, da ich kaum glaube, dass Eur*light-Scanner entsprechend teurere Komponenten enthalten werden - und somit wenn überhaupt das ganze konzept für die etwas gehobenere branche ist.
Gruß,
Kachel
Naja die einzelnen Lampen zu Adressieren ist ja nicht das Problem.
Das Pult muss ja nicht die genauen Koordinaten wissen.
Eine grobe Richtung ob Front oder Backtruss langt ja schon.
Vielleicht würde es langen wenn man beim bestücken der Truss, eine Gruppe von Geräten erstellen kann.
Z.b. mit ner Chipkarte oder einem ID-Stick.
So hängt man z.b. in die linke Seite alle Lampen auf einen DMX Kanal und auf der rechten einen anderen.
Dann gibt man einem Gerät was in der Reihenfolge als ersten kommt jeweils eine ID oder Chipkarte (z.b. farblich markiert) und notiert sich dann nur noch im Bauplan welche Truss mit welchem Universe ausgestattet wurde.
Beispielsweise Fronttruss=ID-BLAU, Backtruss=ID-Rot und Dekokram=ID-Grün.
Den Rest kann man dann bequem am Pult machen.
Ein vollständig autages System mit GPS oder sonstiger Ortungstechnik halte ich für utopisch.
Erstens funktioniert GPS nicht in geschlossenen Räumen, GSM wird auf die dauer auch teuer und ansonsten funken schon genug Gerät auf Bluetooth und WLAN herum.
Für die Zuornung bräuchte man die exakte Position und nicht eine grobe Annäherung. Es sei denn jeder Mac der Backtruss macht dasselbe.
Bei dem Einsatz von Chip-Karten etc. könnte man darauf auch die gesamte Parametrierung des Gerätes auslagern und RDM nur noch für status messages nutzen.
Die Auflösung von GPS dürfte zu gering sein. Die Ultraschall Triangulation (?) könnte funktionieren.
Letztlich wird man wohl nach einer vollständigen Discovery alle Geräte identifizieren (nacheinander aufblitzen, wackeln, hupen,...) müssen, um dann richtig patchen und einrichten (Achsen spiegeln, usw.) zu können.
(Die IDENTIFY_DEVICE PID fehlt bei mir sogar glaube ich noch.)
Viele Grüße,
Hendrik
