Aktives vs Passives Interface + Sonstige Fragen

Hallo und herzlich willkommen im Forum,
also hier mal die Antworten auf deine Fragen (ich hoffe, ich vergesse nichts).

Zu der Berechnung:
Die Werte, welche ausgegeben werden sollen, werden auf dem PC berechnet. Das macht nicht das Interface. Der Unterschied zwischen aktivem unn passivem Interface ist aber, dass der PC beim Passiven auch noch das DMX-Signal generieren muss (also die genaue Bit-Folge erstellen muss, die dann auf die DMX-Leitung gelegt wird). Bei einer Standard-DMX-Leitung mit 512 Kanälen muss der PC das mit ca. 44Hz erledigen. Da fangen dann die Probleme an, denn das verursacht einfach zusätzliche (und unnötige) Last auf Seiten des PCs. Manche passive Interfaces sind dann auch noch naja, ich sage mal sehr günstig aufgebaut. Es gibt passive Interfaces, bei denen DMXControl das Ausgabeplugin mit etwa 40Hz anspricht, damit hinten am DMX-Out etwa 15Hz ankommen. Außerdem ist die Ausgabe wie du bereits mit der Anspielung auf den Linux rt-Kernel gesagt hast in gewissem Maße zeitrelevant. Das umgeht man eben mit den aktiven Interfaces, denn der PC muss das Interface nur mit neuen Werten versorgen, wenn sich diese auch tatsächlich geändert haben. Sonst gibt das Interface einfach die zuletzt aktualisierten Werte aus.

Artnet:
Auch bei Artnet werden keine Befehle gesendet, sondern nur die Werte der einzelnen Kanäle. Das ist also auch nur ein 8Bit-Wert pro Kanal. UDP wird verwendet, weil das am besten der Art von DMX entspricht. Bei DMX hast du auch keine bidirektionale Verbindung (von RDM mal abgesehen, aber das ist für etwas anderes da). Du hast einen Sender, der stumpf ein DMX-Signal sendet, ob das ein DMX-Gerät mithört der nicht. Deshalb musst du auch die Startadresse am DMX-Gerät einstellen, weil erst dadurch festgelegt wird, auf welche Werte es im DMX-Datenstrom über den Bus hören soll.

Nodle:
Das Nodle und das Digital Enlightenment (kurz DE)-Interface sind darauf getrimmt, dass sie die DMX-Spezifikation einhalten. Am DMX-Ausgang kommt also in der Grundeinstellung ein normgerechtes DMX-Signal heraus (schon das ist bei einigen Interfaces nicht selbstverständlich). Der Clou ist aber, dass man das Signal auch an die eigenen Geräte anpassen kann. Denn leider schaffen es viele günstigere Geräte (vorallem Noname aus dem asiatischen Raum) nicht, ein normgerechtes DMX-Signal zu decodieren. Dementsprechend kann es dann zum Flackern, zu Aussetzern und zu anderen Erscheinungen kommen. Um dem entgegen zu wirken, kann man das DMX-Signal bei diesen beiden Interfaces bei vielen Parametern anpassen. Dadurch hast du die volle Kontrolle und kannst dich auf alle Arten von Geräten einstellen. Mir ist nicht bekannt, dass das auch bei anderen Interfaces geht.

Ein weiteres Merkmal der beiden Interfaces ist die Galvanische Trennung. Dabei sind der DMX-Teil und der PC/Interface-Teil galvanisch voneinander getrennt. Dadurch können defekte DMX-Geräte deinem PC nichts anhaben. Wir hatten hier im Forum vor ein paar Jahren einen solchen Fall. Da hat bei einem User ein defektes DMX-Gerät eine hohe Spannung auf den DMX-Bus gelegt. Dabei hat es zwar die DMX-Seite des Interfaces gegrillt (genauer einer der Bustreiber wurde geröstet) aber der PC ist heil geblieben. Diese galvanische Trennung ist auch besser, als man das von manchen damit beworbenen Interfaces kennt. Ich möchte hier aus verschiedenen Gründen keine Interfacenamen nennen, aber Vereinsmitglieder hatten schon mit galvanischer Trennung beworbene Interfaces in der Hand, bei denen sich beide Teile die selbe Masse geteilt haben "hust". Beim Nodle und dem DE sind beide Bereiche nur über Optokoppler und einem DC/DC-Wandler verbunden. Der Unterschied zwischen dem DE und dem Nodle ist, dass das DE älter ist und nicht direkt von uns stammt. Das Nodle ist eine Entwicklung des Vereins, wodurch wir die Sourcen der Firmware haben (haben wir beim DE nicht) und können so noch ein paar Zusatzfunktionen in Zusammenspiel mit DMXControl einbauen (sind auch schon geplant).

DMXControl:
Das kommt auf die Version an. Wir haben aktuell zwei Versionen, weil wir mit DMXControl 3 ein neues Bedien-Konzept eingefügt haben, aber noch nicht alle Funktionen von DMXControl 2 in DMXControl 3 integriert haben. Das sind insbesondere der Audioplayer und das Textbuch. Wenn du ein paar genauere Anforderungen formulieren könntest, dann kann ich dir auch genauer sagen, ob und wie das mit DMXControl umsetzbar ist (welche Version,...). Du hast aber mit beiden Versionen die Möglichkeit, Szenen / Cues abzuspeichern und diese auszuführen, wobei auch mehrere Szenen, welche unterschiedliche Kanäle beeinflussen parallel laufen können. An den Parametern einer Szene kannst du in beschränktem Maße herumspielen. D.h. du kannst die Einblendzeit und die Haltezeit verändern, aber in der Zeit, in der eine Szene einblendet, haben Änderungen keine Auswirkungen. Erst beim nächsten Einblenden. Steht eine Szene, so kannst du natürlich auch wieder Teile davon mit neuen DMX-Werten überschreiben (kommt aber bei DMXControl 2 z.B. auf das Modul an, weshalb ich da nicht genauer werden kann).

"Low-Level" wie du es nennst kannst du in DMXControl 2 und 3 auf die Kanalwerte zugreifen. Das nennt sich in DMXControl 2 Kanalübersicht und in DMXControl 3 channel overview. Dort siehst du die Werte der einzelnen Kanäle und kannst sie auch anpassen. Wobei das in DMXControl 3 eigentlich nicht vorgesehen ist. Denn dort gibt es den sog. Hardware Abstraction Layer (kurz HAL) der als Bindeglied zwischen dir und den DMX-Geräten dient. Nachdem du einmal die Kanalliste der Geräte in die Gerätedefinitionen gegossen hast (sog. DDFs) braucht es dich nicht mehr zu kümmern, welche Kanäle wie angesteuert werden. Denn du wählst einfach alle Geräte aus, die du nun anpassen möchtest und setzt diese z.B. auf die Farbe Rot. Dass du dabei z.B. einen Washer mit CMY-Mischung, einen Moving Head mit Farbrad und einen LED-Scheinwerfer mit RGB-Farbmischung ausgewählt hast, ist vollkommen egal. Der HAL versucht, die nächstmögliche Entsprechung für die ausgewählte Farbe zu finden (z.B. wenn der MH kein Rot sondern Rosa hat, wählt er das aus, weil es am nächsten zu Rot ist). Gleiches funktioniert z.B. auch mit den Gobos. Natürlich muss ich auch sagen, dass DMXControl 3 noch verhältnismäßig neu ist und so noch der eine oder andere Bug darin steckt, der noch nicht gefixt wurde. Auch das Konzept ist erst ein wenig gewöhnungsbedürftig (gerade für Umsteiger), bietet aber nach einer gewissen Einarbeitungszeit doch deutliche Vorteile.

Weitere Frage:
Zu den Loops kann ich dir nichts sagen, weil ich das nicht genau weiß. Warum interessiert dich das? Mehr als 44Hz bringen aber eigentlich nichts, weil schneller kann DMX (in der Standardkonfig) eh nicht übertragen. Ich kann dir aber aus Erfahrung sagen, dass man z.B. mit der Single-Core-Anwendung DMXControl 2 auf einem halbwegs potenten PC (i5) mit einem DE / Nodle-Interface selbst bei etwa 400 sich gleichzeitig ändernden Kanälen keine durch diese Kombi verursachten Ruckler sichtbar sind.

Zum Nodle:
Wie fein möchtest du es denn wissen? Mal ganz grob: Das Nodle empfängt bei Werteänderungen in der Software entsprechende Datenarrays vom PC. Die werden in einem Speicher zwischengespeichert. Dann wird der Ausgabespeicher aktualisiert, wenn gerade wieder der DMX-Sendezyklus daran vorbei kommt. Nun wird aus dem neuen Datensatz ein DMX-Signal generiert und auf den Pin gelegt, an dem einer der beiden Optokoppler hängt. Dieser überträgt das Signal an den Bustreiber, der das eigentliche DMX-Signal generiert und dann über den Äther jagt. Der andere Bustreiber ist als Empfänger gesetzt. So wird der ganze Weg zurück zum Prozessor genommen. Der Prozessor packt das Signal aus, speichert das neue Werte-Array und informiert den PC bei einer Änderung eines Wertes im Vergleich zum vorheringen Stand darüber.

Zu den Echtzeitkernel:
Ich weiß nicht in wie weit du dich damit auskennst. Ich habe in der Uni wegen unseren Testsystemen für unsere Flugzeugsysteme damit zu tun und habe z.B. für meine Bachelorarbeit Latzenzmessungen gemacht. Der Echtzeit-Kernel ist nicht schneller als der normale Kernel, ganz im Gegenteil. Systemnachrichten brauchen beim Echtzeit-Kernel länger, als beim normalen Kernel. Der Unterschied ist aber, dass man sich beim Echtzeit-Kernel mehr oder weniger darauf verlassen kann, dass die Latenzen immer in einem gewissen Fenster liegen, wärend dir beim normalen Kernel auch mal ein Prozess dazwischenkrätschen kann und somit die Latenzunterschiede sehr groß sind (oftmals gut, aber einzelne sehr krasse Ausreißer). Es ist also nicht gesagt, dass es mit einem rt-Kernel schneller ist (ich habe meine Messungen dann z.B. auch auf einem normalen Kernel gemacht, weil die Genauigkeit durch andere Maßnahmen deutlich größer war). Wie aber schon weiter oben erwähnt ist eine Updaterate von mehr als 44Hz eh nicht zielführend (eigentlich schon 25Hz, denn das Auge kann ja nicht mehr).

RasPi:
Für diesen gibt es so viel ich weiß schon eine c-Bibliothek, mit der man auch DMX über die GPIOs ausgeben kann. Allerdings fehlt da dann halt die galvanische Trennung. Außerdem weiß ich nicht, wie gut diese Lib ist und wie gut das mit dem RasPi läuft.

Zu den Kabeln:
Ja, für kleinere Dinge gehen auch Mikrofon-Kabel. In meiner ehemaligen Schule, bei der ich noch abundzu aushelfe, verwenden wir nur Mikro-Kabel. Man merkt das auf langen Entfernungen, wenn dann einzelne DMX-Geräte kein sauberes Signal mehr erhalten. Durch die Mikro-Kabel werden die Kanten des Rechtecksignals verschliffen, wodurch die Geräte ab einem gewissen Grad der Signalveränderung die Bits nicht mehr sauber trennen können. Den selben Einfluss hat jedes zusätzliche DMX-Gerät in der Kette. Du kannst also mit DMX-Kabeln tatsächlich 32 DMX-Geräte anschließen, weil da das Signal auch beim 32. Gerät noch so gut ist, dass das Signal fehlerfrei gelesen werden kann. Bei Mikrofon-Kabeln sind das dann halt entsprechend weniger Geräte. Wir hatten bei etwa 100m Kabellänge und um die 20 Geräte Probleme mit den letzten drei Geräten. Wir haben uns dann aber beholfen, indem wir einfach vom verwendeten DMX-Splitter eine weitere Leitung für die letzten 8 Geräte gezogen haben. Man sieht also, es hat einfach einen Einfluss auf die Signalqualität und damit, wie lange die Strecke und wie groß die Anzahl der Geräte sein darf.

Widerstand:
Korrekt, zwischen 2 und 3.

Ich hoffe, ich konnte dir mit dem doch sehr langen Text alle deine Fragen beantworten.
Viele Grüße
JP

zum kabel will ich noch ergänzen, das auch ein dmx-kabel, nur ein xlr-kabel ist.
besser: xlr ist der stecker in 3&5pin-ausführung. idr meint man oft 3pin. die kabel selbst unterscheiden sich in nf und hf. das macht den unterschied aus.
dmx=hf

ich selbst verwende überwiegend das sc binary das sowohl als auch für beides geeignet ist. es ist robust/strapazierfähig genug und bisher, bei beiden signalarten, unabhängig von der länge, gab es nie probleme

Ganz so einfach ist das mit den Kabeln dann doch nicht.

Eigentlich ist für DMX ein spezielles Kabel vorgegeben.

Nämlich 2 Aderpaare, verdrillt mit Schirmung und 5 poligem XLR-Stecker.
Das Kabel muss einen Wellenwiderstand von 110 Ohm haben.

oft sind diese auch als AES/EBU Kabel bezeichnet.

Der 3-polige Kram hat sich durchgesetzt, weil es günstiger ist und so auch Mikrofonkabel verwendet werden können.

Hallo!

Ich bin jetzt mal ganz frech: du möchtest dir ein paar Kleinigkeiten an Lichttechnik anschaffen, wie du eingangs schreibst. Dass müssen aber schon ganz besondere Geräte sein, bei den ganzen Fragen die du stellst... Daher: Magst du uns verraten, was du vor hast?

Ich will dir keineswegs verbieten weitere Fragen zu stellen - um Himmels willen bitte nicht falsch verstehen. Ich bin nur echt erstaunt, was für fragen du (bitte ebenfalls nicht falsch verstehen und auch nicht böse gemeint) als "Anfänger" stellst.

Ich denke, wenn du uns sagst, was dein Ziel ist, können wir dir vielleicht auch ein bisschen beratend zur Seite stehen, als "nur" deine Fragen zu beantworten - was wir wie du siehst ja auch gerne machen.

Viele Grüße, Stefan von den LightningBrothers.

So... nochmal ich

Nun, wo ich zu Hause bin, möchte ich dir noch auf ein paar Fragen eine Antwort geben - nämlich hinsichtlich des Programmierens einer Lightshow...

Ob du nachträglich in eine laufende Lichtshow eingreifen kannst, hängt (auch) damit zusammen, wie du dein Projekt insgesamt aufbaust. Ich selbst verwende DMXControl 2 seit Jahren (mit der 3er fange ich jetzt so langsam an) in mehreren Clubs sowie für meine eigene Lichttechnik auf Hochzeiten und privaten Feiern. Alle Projekte habe ich als Baukastenprinzip konzipiert, wodurch es erst mal nicht direkt möglich ist, eine Lichtshow zu Starten. Vielmehr ist es so, dass ich mir meine Show aus einem ganzen Pool von (kleineren) Effekten zusammenbaue und erst die Kombination von verschiedenen Effekten schließlich eine Lichtshow zeugt. Und eine Lichtshow ist es dann insgesamt betrachtet, weil ich selbst als Bediener über den Song hinweg zum Beispiel bei der Strophe ein anderes "Setup" laufen lasse als beim Refrain - sei es nun andere Farben, andere Wechsel, "nur" andere Bewegungen bei den MovingHeads oder halt die Verwendung von unterschiedlichen Gerätegruppen wie nur MovingHead, nur LED-PARs oder halt beide. Zusätzlich untermale ich dass mit Akzent-Effekten wie Blinder- oder Strophe-Effekte, die ich punktuell über ein MIDI-Keyboard bzw. über die Tastatur aufrufe. Wenn der DJ mich dann mal ärgern will, dann spielt er alle 30 Sekunden einen anderen Song bzw. Titel, wo mehrere unterschiedliche Songpassagen relativ schnell aufeinander folgen, sodass ich dann gut ins Schwitzen komme. Am Ende ist es aber eine Sache der Übung. Was ich aber sagen muss - damit es mir nicht zu bunt wird, habe ich gewisse Sachen fest voreingestellt, wie zum Beispiel Gobos in Verbindung deren eigenen Rotation. Damit aber der MovingHead monoton über den gesamten Abend durch das Gobo das gleiche Muster auf den Boden o. ä. projiziert, habe ich wie ich eingangs sagte einen ganzen Pool von solchen Einstellungen.

Damit einhergehend habe ich auch deine Frage beantwortet, wieso man Effekte von seitens der Software vorausberechnet ans Interface schicken kann - weil die Software nicht erkennen kann, wann ich als Bediener einen Akzent-Effekt starten will. Um dass zu können, müsste ich bereits vorher wissen, welche Titel der DJ an diesem Abend spielen möchte und dann noch wie lange und wie schnell, womit wir eigentlich bei einem absoluten Ausschlusskriterium wären, spätestens aber dann, wenn es ums Programmieren der Lightshows geht. Da gehen durchaus Stunden ins Land, wenn man einen Song vernünftig "verlichten" möchte.

Ich hoffe, ich konnte ein wenig Lichts ins Dunkle bringen. Bis dahin - viele Grüße, Stefan von den LightningBrothers.

Das DMX mit 44Hz sendet wurde mal in einer Spezifikation festgeklopft. Warum das nun genau 44 sind kann ich dir leider nicht sagen. Ich weiß nur, dass es so ist. DMX sendet ständig, um auch eine Art "Keep Alive" zu haben. Denn sonst kannst du nicht detektieren, dass die DMX-Verbindung abgerissen ist. Daher wird dauerhaft gesendet. Das der Unterschied zwischen den Datenraten bei diesem einen Interface so groß ist können wir uns auch nicht erklären. Wir wissen nur, dass es so ist. Es zeugt halt nicht gerade von Qualität. Da ist auch nichts gebuffert. Das ist einfach ein USB-Serial-Chip, der das vom PC generierte Signal ausgibt. Letztendlich ist dieses Interface vergleichbar mit den USB-RS232-Interfaces vergleichbar. Für normale DMX-Geräte brauchst du einen konstanten Datenstrom, denn wie gesagt musst du detektieren, ob ein DMX-Signal da ist oder nicht.

Zu deiner Vorausberechnung:
In Einzelfällen mag das zutreffen, dass man das vorberechnen kann. Im Allgemeinen ist das aber nicht der Fall, denn du kannst nicht nur eine Szene laufen lassen, sondern mehrere parallel. Auch können sich unterschiedliche Szenen überlagern (z.B. per HTP). Und wenn dann noch eine Eingabe durch den User kommt, kannst du deine ganzen vorberechneten Daten vergessen. Außerdem: Woher nimmt das Interface die Zeitbasis? Du müsstest das Interface so aufbohren, dass es die komplette Intelligenz z.B. des DMXControl 3 Kernels hat + die Ausgabe in einer vernünftigen Zeit realisieren. Da ist es doch einfacher, alles auf dem PC vorzuberechnen und dann die berechneten Werte an das Interface zu schieben.

Mit den Interrupts hast du recht, aber mit aktiven Interfaces fällt zumindest schonmal eine gewisse Systemlast weg, was auch etwas ausmacht. Und nicht zuletzt ist die Wahrscheinlichkeit geringer, dass es hier zu Problemen kommt, weil du nur punktuell Daten überträgst im Gegensatz zu der dauerhaften Übertragung bei passiven Interfaces. Denn bei den Änderungen musst du bei einem aktiven Interface nur ein Array mit den entsprechenden Werten ausgeben (was man eh schon hat), bei den passiven Interfaces muss man immer den kompletten Datenstrom generieren.

Zu DMXControl 3:
Ein gleichzeitiges Verbinden mit mehreren Kerneln wird es nicht geben (laut Aussage der Entwickler). Denn da sind ja auch noch andere Dinge wie Projektverwaltung etc. die vom Kernel abgewickelt werden. Das wird einfach ein unnötiger Overhead, den man nicht braucht. Ich meine, probiere es aus. Wie gesagt habe ich mit DMXControl 2 schon Projekte gehabt, bei denen ich 400 Kanäle benutzt und etwa 200 Kanäle geleichzeitig geändert habe. Das lief auf ganz gut, ohne dass man Ruckler gespührt hat. LighningBrothers hat in den Discos, die er betreut vermutlich noch mehr Kanäle, die er gleichzeitig ändert. Auch er hat (so wie ich es mitbekommen habe) keine Probleme gehabt (Stefan, kannst ja dazu noch was sagen ). Ich denke man kann vielleicht noch das letzte bischen herausholen, wenn man das nach deinem Ansatz auf die Interfaces verteilt, aber der Preis dafür ist eben auch entsprechend hoch (API komplett zu definieren, Interface mit entsprechender Rechenleistung erforderlich, schwerer zu warten / debuggen, ....). Daher ist die Lösung so schon ganz gut, wie sie sind (sonst würden es die anderen Lichtsteuersoftware-Hersteller auch anders machen).

Zum Nodle:
Naja, jeden einzelnen Widerstand kann ich dir nicht erklären (bin auch kein Elektrotechniker). Den groben Aufbau habe ich dir mal gesagt. Es würde aber glaube ich den Rahmen sprengen, den Grund für alle Bauteile zu erklären. Die Vorteile sind eben eine sehr hohe Stabilität (was bei passiven Interfaces manchmal nicht gegeben ist) und das anpassbare DMX-Signal. Diese Funktion haben nicht viele Interfaces.

Zu DMXControl:
Ja, du kannst in bestehende Lichtstimmungen eingreifen. Schau dir dazu doch einfach mal die Berichte von Stefan zum York in Kassel an (in unserem Wiki). Dort siehst du, wie so etwas live aussehen kann.

RasPi:
Leider kann ich dir nicht sagen, wie gut der ist. Aber es ist vermutlich ein geringerer Aufwand, die ein ArtNet-Node oder ein DE-/Nodle-Interface zusammen zu bauen, als da etwas zu programmieren

Viele Grüße
JP

Hi,
ein Hinweis zu der Übertragungsgeschwindigkeit von 44 Hz:
Die Bitfrequenz (Baudrate) ist 250000 kHz.
Jedes übertragene Byte benötigt 11 Bit (1 Startbit, 8 Datenbit, 2 Stopbit).
Macht 22727,27 Bytes/sec
Ein DMX-Zyklus umfasst 512 Kanäle.
22727,27 / 512 = 44,389 Hz
Und jetzt kommen noch ein Break hinzu (etwas mehr als 11 Bit) und vielleicht eine winzige Reserve.
Und dann haben wir 44 Hz. Das ist also die "Schallmauer", wenn ohne Pause ein Byte nach dem anderen übertragen wird.
Asynchrone Übertragung lässt Pausen zu. Auch unterschiedlich lange zwischen den einzelnen Bytes. Wenn also ein PC nicht mit dem Senden nachkommt, geht es eben etwas langsamer. Es dürfte aber nichts verloren gehen.

Das DMX-Konzept stammt aus der Zeit, zu der Elektronik noch dumm war. Nichts wird gespeichert, nichts wird irgendwo automatisch erledigt. Deshalb wird bis zum Umfallen gesendet. Ja, Computer gab es damals schon, das waren aber teure, große Kästen.
Ich habe mich mal über das historischen Verfahren ausgelassen: http://www.radonmaster.de/dancingwater/dmx-extension/

Ist es tatsächlich üblich, dass DMX-Empfänger prüfen, ob Daten ankommen? Was passiert, wenn die Übertragung abreißt? In einem Beispielprogramm für einen Arduino-Empfänger hat der Autor eine Reaktionszeit vom 5 sec eingebaut. Dann geht der farbige Strahler als "Fehlermeldung" auf konstantes Rot. Das ist auf einer Bühne sicher keine gute Lösung. Während der Installationsphase kann es natürlich hilfreich sein.

Gruß RoBernd

Hallo,
ja, das ist üblich, dass die DMX-Geräte erkennen, ob ein Signal ankommt oder nicht. Allerdings ist es nicht üblich, dass die Scheinwerfer auf rot schalten. Viel mehr kommt es ich sage mal auf die Preisklasse an. Einfache Scheinwerfer mit Mäuseklavir gehen oft einfach aus, weil das die am wenigsten störende Methode ist. Andere halten den letzten DMX-Wert, sprich die letzte Intensität. Bei teureren Scheinwerfern gibt es dann LEDs, die Blinken und anzeigen, dass ein Signal anliegt oder nicht. Bei den ganz teuren Scheinwerfern blinkt die Displaybeleuchtung um schnell identifizieren zu können, bei welchen Geräten das DMX fehlt. Bei diesen Scheinwerfern kann man dann normalerweise im Menü auch einstellen, wie sie auf einen Signal-Verlust reagieren sollen (Aus, Default, letzter Wert halten).

Zu DMX: Mag sein, das DMX eine alte Technik ist und sich die Geräte mittlerweile weiterentwickelt haben. Sie hat aber auch viele Vorzüge, die DMX immernoch zum Hauptmedium für die Veranstaltungstechnik macht. Vorallem mal ist DMX sehr robust. Da muss schon ein bischen was passieren, bis bei DMX Probleme auftreten. Dann vorallem, wenn man sich nicht an die Spezifikationen hält (Mikro-Kabel statt DMX-Kabel, mehr Geräte in der Kette als erlaubt,...). An sonsten halten die Kabel + Stecker im Road-Einsatz einiges aus, Fremdsignale stören so gut wie garnicht. Beides kann ich von manchen Netzwerkkabeln nicht sagen.
Außerdem kommt noch hinzu, dass alle anderen heutigen Methoden (vorallem ArtNet, also letztendlich LAN-Netzwerk) für die Veranstaltungstechnik ungünstige Topologien verwendet. An einer Truss hängen die Scheinwerfer nunmal in Reihe und da macht eine daisy chainTopologie deutlich mehr Sinn, als die Sterntopologie heutiger Netzwerksysteme. Das geht sogar so weit, dass mitlerweile in den teuren ArtNet-Scheinwerfern extra Drei-Port-Switches (zwei für "in" und "out" und einen für das Gerät selbst) verbaut werden, damit der Techniker weiter seine daisy chain hat. Das bekommt man bei DMX geschenkt.
Nicht zu letzt stellt sich die Frage: Muss ein Scheinwerfer wirklich intelligent sein? Wenn ich eine hochintelligente Steuerung habe, die alle beliebigen Funktionen vereint. Warum sollten dann die Scheinwerfer noch intelligent sein? Das ist in meinen Augen ehr sogar schädlich, denn so kann schon kein Gerät dazwischenfunken, weil es meint, ein Muster erkannt zu haben, was man dann in etwas abbilden müsste. Nur so am Rande: Ich bin übrigends mit dieser Meinung nicht alleine. An dem Institut, an dem ich arbeite, wird versucht, Luftfahrtsystemplattformen so zu gestalten, dass wenige Systeme die Entscheidung tragen, diese dann auch hochkomplex und "intelligent" sind, während andere Systeme möglichst dumm sein sollen. Das reduziert die Kosten und erhöt die Flexibilität.
Viele Grüße
JP

Hi,
die Zeiten, zu denen ich über DMX die Nase gerümpft habe, sind längst vorbei. Zu der Zeit habe ich noch nicht einmal gewusst, dass es DMX-Editoren gibt.
Längst habe ich gelernt, dass wir an DMX nicht vorbei gehen können. Zumal es keine Alternative gibt.

Wie robust diese Technik ist, haben uns schon die alten Fernschreibsysteme gezeigt, welche letztlich das Vorbild für DMX waren (allerdings mit Stromschleife und nicht RS485).
Ich habe Spaß am Tüfteln und versuche das eine oder andere etwas intelligentere an das System anzuhängen. Inzwischen kommen mir aber immer mehr Zweifel, ob das sinnvoll ist. Richtig schlimm wird es in der Tat, wenn sich Intelligenz verselbstständigt und gar ungefragt zu senden beginnt.

Gruß RoBernd

Hi!

Es gibt übrigens noch eine weitere Art mit dem "nicht vorhandenen" DMX umzugehen: Die Geräte gehen dann auf Sound-to-Light.
Oder noch viel schlimmer: Sie beginnen je nach Einstellung dann sogar selbst DMX-Werte zu senden um als "Master" andere "Slave" Geräte gleichen Typs auf Sound-to-Light oder vorprogrammiertes wildes Geblinke zu steuern.
Das macht sich wunderbar wenn in einer Kette so ein Gerät sitzt und dann davor ein Kabelbruch oder Wackelkontakt die Linie unterbricht. Viel Spaß mit dem Chaos...

Hoc

. . . Naja ??
Wenns ganz dunkel wird hinter dem Kabelbruch (Unterbrechung) ist es auch nicht besser !!

Bei ungebetenen S2L ist aber wenigstens noch der Fluchtweg besser Beleuchtet als mit einem Blackout !
(Je nach Lokation)
Hat man Kabel oder Sendeprobleme ist es meiner Meinung nach am "Sichersten" die letzte Einstellung aufrecht zu halten !
Das ist "berechenbarer".

Probleme mit der Signalführung sind dann eben (Selbstverschuldet oder nicht) ein anderes Problem.

Gruß Ralf