Dimmer Selbstbau

We proudly present: The release of DMXControl 3.3.3!


On September 29, 2026, we held our release show for DMXControl 3.3.3. During our usual “hour-long” session, we showed you all the new features in this version and what it now has to offer.
Read all about it in the corresponding news article: We proudly present: The release of DMXControl 3.3.3!


  • Quote

    Mir ist der Ansatz, nur 512 8bit-Werte zu übertragen einfach zu flach und die "Probleme" von DMX auf die Hardware zu reduzieren - das ist IMHO nicht das, was ich mit Innovationsgeist verbinde.


    Ok, vielleicht hab ich mich da schlecht ausgedrückt. Deine Aussage war, dass man erstmal aufwendig OSI Layer 3-7 einprogrammieren müsste und das wollte ich mit dem Beispiel verneinen, dass man im einfachsten Fall einfach das DMX Universe ins Ethernetframe legt und es dann immerhin schonmal wie DMX Funktioniert. Natürlich hätte das noch keinen Innovationsgeist wäre aber total simpel und schonmal deutlich besser als aktuelles DMX. Was ich mit Problemen bei DMX meinte sind unvorhergesehene Störfälle, nicht systemimmanente Probleme wie z.B. fehlende 16 Bit Kanalunterstützung. Und diese sind bei Ethernet sicherlich deutlich seltener als bei DMX (zumindest ist das meine Erfahrung).
    Das man es, wenn man sich schon was neues ausdenkt, es gleich richtig machen sollte, also mit einem gescheiten protokoll, darin stimme ich mit dir vollkommen überein. Wie komplex es sein muss und sein kann, da kann man wohl drüber streiten. Aber alleine eine Festlegung auf einen Layer 1/2 Standart, bei dem bereits Paketgrössen und Fehlerkorrektur klar vorgegeben sind vereinfacht schon einiges. Z.B. wäre eine Fragmentierungsfunktion wie bei IP unnötig und auch eine komplexe Transferwindowsteuerung wie bei TCP überflüssig weil in einem LAN die Delayzeiten sehr klein sind und eine Fehlübertragung nur sehr selten auftritt. Da reicht ein ACK am Ende eines Kommandos.
    Wobei ich der Meinung bin, ein solches Protokoll sollte auch die (Grund-)Funktionen der Lampen festlegen. Z.B. alle Kanäle 16 bit (Bandbreite haben wir ja nu genug), eindeutige ID für Funktionen, Vereinheitlichung (keine Mischung von Schutter und Dimmer mehr usw.). Das würde auch den Steuerungsherstellern sehr helfen...
    Ich seh gerade, dass du das eventuell mit

    Quote

    Für ein vernünftiges Neukonzept wären Strukturen, vergleichbar (oder identisch?) mit einem aktuellen Automatisierungsnetzwerk nötig. ...

    meintest. Ich hatte da irgendwie Netzkonzept statt Neukonzept gelesen und dachte du meinst die Art wie Daten im LAN verteilt werden, aber so muss ich dir hier natürlich recht geben.

    Quote

    Vernünftige Fehlermeldungen z.B. von Wackellampen halte ich durchaus für einen Nutzen


    Exakt, und damit sind wir wieder beim Kern der Sache: Genau das will RDM einführen und es macht sicherlich Sinn, aber eben auf in meinen Augen veralteter technischer Basis.

    Dass es im Prinzip Lösungen für sämtliche Kommunikation im VA Bereich für Ethernet gibt stimmt schon, aber es ist reinstes Chaos, jeder macht was anderes, wie in der 0-10V Zeit. Es fehlen die Standards, wie DMX derzeit einer ist. Ich würd mich ja bereit erklären mir über sowas mal Gedanken zu machen, glaub aber nicht, dass das irgendwen dadraussen ausser vielleicht ein paar Leuten hier im Forum interessiert. ;)

    Quote

    Ach übrigens: Stichwort Sicherheit: Die Fehlererkennungswahrscheinlichkeit die die Standard-Ethernet-Protokolle mitbrignen ist zu schwach, um darüber sicherheitsgerichtete Übertragung entsprechend Maschinenrichtlinie zu realisieren. Es gibt aber Techniken, um auch sichere Antriebstechnik über Ethernet zu machen - dann haben wir aber endgültig das verlassen, was Du als kostengünstiges Standard-Ethernet kennst.


    Naja, die Wahrscheinlichkeit, dass ein fehlerhaft übertragenes Frame korrekt erkannt wird liegt bei 1 zu 4 Milliarden (2^32). Dazu wird sichergestellt, dass gewisse häufige Fehlergruppen wie Einbit-Fehler oder Burst-Fehler zuverlässig immer erkannt werden. Wenn das nicht reicht kann man im übergeordneten Protokoll beliebig weitere Prüfmechanismen einbauen, das ist nur Software und kostet im Prinzip nix. Absolute Übertragungssicherheit gibt es nicht, selbst wenn du die Daten digital signierst gibts eine gewissen Wahrscheinlichkeit, dass jemand die passenden Schlüssel errät. ;)

  • Hi!

    Finde es sehr spannend was hier so diskutiert wird. Danke für die Einblicke in die grundlegenden Techniken, die Geschichte und die Ideen!

    Quote

    Original von Michael_D
    Und die Kosten für nen Ethernetswitch hat man heute ja fast schon durch die billigen Kabel wieder raus ;)
    Den einzigen wirklichen Nachteil sehe ich aktuell in der Sterntopologie, aber auch nur auf den ersten Blick: Ob ich nun ein Kabel von Splitter nach A, dann nach B und dann nach C lege oder von Switch nach A, von Switch nach B, von Switch nach C lege ist auch egal. Vorteil wäre aber ein kaputtes Kabel lässt nur eine Lampe ausfallen. Zum Switch könnte man z.B. zwei unabhängige Kabel legen von denen durchaus eins ausfallen dürfte.

    :D Da hätt ich sogar 'ne Lösung dazu: Wenn man schon dabei ist, könnte man doch gleich jedes Gerät mit einem 3-Port-Switch intern versehen. Ein Port geht intern in's Gerät und zwei nach draußen. Dann hat wieder jedes Gerät zwei Buchsen und es ist dann sogar nahezu total egal wie die Geräte verstöpselt sind solange jedes Kabel an beiden Enden irgendwo drinsteckt. Verkabeln für jeden noch so dummen Aufbauhelfer... :D
    Noch ein Problem weniger, oder? ;)

    Hoc

    Mein Equipment:
    1x Hirn | 2x Augen (leicht defekt) |2x Ohren | 1x Mund |32x Zahn (zum Teil V1.5) | 1x Handundfuß-Interface
    *SCNR*

  • Quote

    Original von Michael_D
    [...]
    Wobei ich der Meinung bin, ein solches Protokoll sollte auch die (Grund-)Funktionen der Lampen festlegen. Z.B. alle Kanäle 16 bit (Bandbreite haben wir ja nu genug), eindeutige ID für Funktionen, Vereinheitlichung (keine Mischung von Schutter und Dimmer mehr usw.). Das würde auch den Steuerungsherstellern sehr helfen...
    Ich seh gerade, dass du das eventuell mit

    Quote

    Für ein vernünftiges Neukonzept wären Strukturen, vergleichbar (oder identisch?) mit einem aktuellen Automatisierungsnetzwerk nötig. ...

    meintest. Ich hatte da irgendwie Netzkonzept statt Neukonzept gelesen und dachte du meinst die Art wie Daten im LAN verteilt werden, aber so muss ich dir hier natürlich recht geben. [...]

    Dass es im Prinzip Lösungen für sämtliche Kommunikation im VA Bereich für Ethernet gibt stimmt schon, aber es ist reinstes Chaos, jeder macht was anderes, wie in der 0-10V Zeit. Es fehlen die Standards, wie DMX derzeit einer ist. Ich würd mich ja bereit erklären mir über sowas mal Gedanken zu machen, glaub aber nicht, dass das irgendwen dadraussen ausser vielleicht ein paar Leuten hier im Forum interessiert. ;)


    Letzeres fürchte ich auch - aber solche akademischen "Fingerübungen" sind doch auch was ;) Und ich sehe, dass uns beide der Austausch doch schon sehr auf eine Linie gebraucht hat, was die Vorstellungen vom allumfassenden VA-Netzwerk betrifft.
    Daß ich durch meine Erfahrungen in der Automatisierungstechnik da leider etwas ernüchtert bin, was Standardisierungswillen und Kosten angeht, ist ja nicht Deine Schuld... Glaube mir, es wird sich in der Richtung nichts bewegen, solange nicht irgendjemand bereit ist, dafür Zeit, Geld und Hirnschmalz reinzuhängen - und dazu gehört auch der Nutzer, der den Mehrwert mit barer Münze vergilt.

    Quote

    Original von Michael_D
    Naja, die Wahrscheinlichkeit, dass ein fehlerhaft übertragenes Frame korrekt erkannt wird liegt bei 1 zu 4 Milliarden (2^32). Dazu wird sichergestellt, dass gewisse häufige Fehlergruppen wie Einbit-Fehler oder Burst-Fehler zuverlässig immer erkannt werden. Wenn das nicht reicht kann man im übergeordneten Protokoll beliebig weitere Prüfmechanismen einbauen, das ist nur Software und kostet im Prinzip nix. Absolute Übertragungssicherheit gibt es nicht, selbst wenn du die Daten digital signierst gibts eine gewissen Wahrscheinlichkeit, dass jemand die passenden Schlüssel errät. ;)


    Die Fachliteratur und - was noch wichtiger ist - prüfende Stellen für solche Anlagen sind sich absolut einig, dass die Sicherheit, die der Standard-Ethernet-Stack bietet, nicht ausreicht für sicherheitsgerichtete Anwendungen. Das im Detail auszudiskutieren bin ich nicht kompetent genug - ich glaube einfach mal, was mir mehrere TÜV-Prüfer und Software-Fachleute erzählt haben.

    Und das mit dem "kostet im Prinzip nix" ist eben leider total falsch. Das Thema "Safety over (jetzt eine Liste sämtlicher verfügbarer Netzwerktechniken)" beschäftigt aktuell Horden von Soft- und Hardware-Entwicklern (so auch einige meiner Kollegen, die damit ihre Familien ernähren). Damit man für ein Übertragungsverfahren, ein Stück Hardware oder sonst was eine SIL3-Zertifizierung bekommt fließt ziemlich Kohle, selbst wenn man die eigene Arbeitszeit nicht rechnen würde. Der Clou an den Lösungen ist, dass ein nahezu beliebig unsicheres Medium durch die von Dir richtig erwähnte Weiterverarbeitung so aufgebohrt wird, dass die erforderlichen Fehlererkennungswahrscheinlichkeiten erreicht werden. Dass kein System absolut sicher ist weißt Du, weiß ich und jeder der mit Technik zu tun hat. Das Stichwort ist das tolerierte zivilisatorische Restrisiko.

    Warum glaubt denn immer alle Welt, dass Software nix kostet? 8o Weil ich die bit und Byte ressourcenlos beliebig kopieren kann?
    Nur weil es Altroisten wie unseren verehrten DMXC-Guru gibt, die die Früchte ihrer Arbeit für lau zur Verfügung stellen heißt es doch nicht, dass Software keinen Aufwand bedeutet.

    Spätestens beim Thema sicherheitsgerichtete Anwendungen hört der Spaß auf - da kann ich nicht in irgendwelchen Lizenzbedingungen jegliche Verantwortung abschieben. Bei Sicherheitstechnik geht es ganz konkret darum: Wer zahlt wenn was passiert? Würdest Du als Entwickler, Applikateur, Zertifizierer Deinen Kopf hinhalten ohne dafür nicht mindestens Deinen Lebensunterhalt auf dem Konto zu sehen?

    Verzeihe, aber das ist ein touchy point bei mir, der davon lebt, dass er Werbung für Produkte macht, in denen eben die Software - die "im Prinzip nix kostet" - genau den Mehr- und Nährwert bietet. Die Hardware kostet nämlich im Prinzip auch fast nix und das bissel Bestücken, Montieren, Testen, Justieren, Soften, Entflechten, Musterbauen, EMV-Prüfen, Dokumentieren, Lagern, Verpacken, Verschicken und so macht man ja in der Freizeit - ist ja alles für Hobby und dafür Geld zu nehmen wäre Wucher.
    Für die ganzen Techniken, die wir da für wenig/kein Geld nutzen hat irgendjemand mal bezahlt. Und heute erwarten wir Innovation für lau...
    Und dann klagen wir darüber, dass niemand mehr technische Berufe lernen will - in allen Foren wird genau die Leistung, die ein Softer, ein Hardwareentwickler... erbringt mit dem Stempel "kostet fast nix" versehen.

    So, Blutdruck wieder herunterfahren und weiter mit der fachlichen Diskussion.
    Mahlzeit =)

  • Quote

    Original von Hoc
    [...]
    :D Da hätt ich sogar 'ne Lösung dazu: Wenn man schon dabei ist, könnte man doch gleich jedes Gerät mit einem 3-Port-Switch intern versehen. Ein Port geht intern in's Gerät und zwei nach draußen. Dann hat wieder jedes Gerät zwei Buchsen und es ist dann sogar nahezu total egal wie die Geräte verstöpselt sind solange jedes Kabel an beiden Enden irgendwo drinsteckt. Verkabeln für jeden noch so dummen Aufbauhelfer... :D
    Noch ein Problem weniger, oder? ;)

    Hoc

    Gut, aber leider nicht ganz neu, die Lösung - ist Standard im Bereich Industrial Ethernet, wo man das mit der Sternverkabelung nicht immer haben will - die sind halt auch ihre Linien bei Profibus und CAN... gewöhnt.

  • Stagemanager75:

    ist zwar alles irgendwie richtig was du sagst, aber du vergisst, was eigentlich die Zielgruppe von uns ist. Wir wollen mit unserer Freeware/OpenSource (ich beschränke mich jetzt auf die Lichttechnik) vor allem Hobbylichtlern und Freizeittheatern eine Möglichkeit geben, gutes Licht zu machen (teilweise ist die Software/Hardware sogar nur für die Entwickler gedacht, aber werden dann auch publiziert). Professionelle Lichtler, die damit entsprechend Geld verdienen, werden in der Regel entsprechend bezahlte Software wegen der Sicherheit und dem Service verwenden.

    Außerdem haben Stefan, Michael und alle anderen, die Hardware/Software frei ins Internet stellen einfach Spaß am Entwickeln und zu zeigen, was man kann ist sicher auch kein unbedeutender Faktor :)

    Quote

    Und das mit dem "kostet im Prinzip nix" ist eben leider total falsch. Das Thema "Safety over (jetzt eine Liste sämtlicher verfügbarer Netzwerktechniken)..."

    Sicherheit spielt schon eine Rolle, aber wenn mal die DMX-Übertragung mal nicht richtig läuft, ist das zwar Ärgerlich, aber ist nicht mit Kosten wie im professionellen Bereich verküpft.

    Quote

    Verzeihe, aber das ist ein touchy point bei mir, der davon lebt, dass er Werbung für Produkte macht, in denen eben die Software - die "im Prinzip nix kostet" - genau den Mehr- und Nährwert bietet. Die Hardware kostet nämlich im Prinzip auch fast nix und das bissel Bestücken, Montieren, Testen, Justieren, Soften, Entflechten, Musterbauen, EMV-Prüfen, Dokumentieren, Lagern, Verpacken, Verschicken und so macht man ja in der Freizeit - ist ja alles für Hobby und dafür Geld zu nehmen wäre Wucher. Für die ganzen Techniken, die wir da für wenig/kein Geld nutzen hat irgendjemand mal bezahlt. Und heute erwarten wir Innovation für lau... Und dann klagen wir darüber, dass niemand mehr technische Berufe lernen will - in allen Foren wird genau die Leistung, die ein Softer, ein Hardwareentwickler... erbringt mit dem Stempel "kostet fast nix" versehen.

    Ich verstehe irgendwie gerade nicht wirklich, warum du dich hier so aufregst. Sei doch froh, dass wir Software frei ins Internet stellen. Musst sie ja nicht verwenden :D

    bis dann,
    Christian :)

    Mein aktuelles Video auf Youtube: Movingheads ohne Kopfschmerzen!

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

  • Da liegt ein kleines Mißverständnis vor:

    1. Im Bezug auf "Sicherheit" habe ich sachlich auf
    "
    eventuell Integration von Sicherheitskritischen Anwendungen dank vorhandener Fehlererkennung
    "
    geantwortet. Da geht es um Antriebe, Sicherheitsvorhänge, Notfallkommunikation.
    Für die Übertragung von Steuersignalen für Lampen, Beamer u.s.w. langt DMX, Ethernet und Co. locker aus.
    (Du kannst Dir kaum vorstellen, welche schwindeligen Ideen manchmal aufkommen - nicht hier, andere Foren...- , über DMX und Switchpacks Riggingantriebe per Lichtstellwerk zu fahren - da geht es um Sach- und Personensicherheit. Da musst Du mir schon etwas Vehemenz zugestehen)

    2. Ich kritisiere nicht, dass jemand seiner Früchte Arbeit mit anderen teilt - das habe ich gelobt, ich kritisiere die Erwartungshaltung, die bei manch anderen daraus erwächst zusammen mit dem schiefen Bild, das von zulässigen Kosten für neue Schnittstellen, Protokolle... dadurch entsteht. Es ist aller Ehren wert, was im Freeware / Open Source Bereich geht!
    Wüsste allerdings nicht, ob es eine Möglichkeit gibt, sich bei den Entwicklern von DMXC erkenntlich zu zeigen - und wieviele davon Gebrauch machen würden. ;)

    Michael_D und ich führen hier einen akademischen Disput über das V-Technik-Netzwerk der Zukunft, diskutieren dabei eine "ganz große Lösung" und sind uns am Kostenpunkt nicht einig. Dass es aktuell bereits sehr viel davon (gerade aus dem OpenSource-Bereich) gibt kannst Du in meinem Post ja lesen - den Wildwuchs inclusive. Und es ist auch legitim, dass man als (Freeware-)Entwickler erst mal sein Problem so singulär wie es beliebt löst. Wer dann andere an der Lösung partizipieren lässt ist ein ganz ein feiner Mensch, dem nur Lob zu zollen ist.
    Dass solche "Insellösungen" (funktionierend, zielgerichtet, stabil...) selten die Qualität oder die Durchsetzungskraft eines umfassend erarbeiteten Standards haben zeigt uns die Vergangenheit.

    Zur Erinnerung: Wir sind vom Standard RDM ausgegangen - warum machen nicht alle mit, warum macht man es nicht gleich "richtig"...

  • Quote

    Original von Blackout-Chris
    Sicherheit spielt schon eine Rolle, aber wenn mal die DMX-Übertragung mal nicht richtig läuft, ist das zwar Ärgerlich, aber ist nicht mit Kosten wie im professionellen Bereich verküpft.


    Noch dazu laufen im professionellen Betrieb im Theater immer zwei Lichtpulte parallel, ein "normales" Pult, und ein "Havarie"-Pult, damit, falls das Haupt-Pult mal ausfallen sollte, sofort ein weiteres Pult zur Verfügung steht, welches die Aufführung ohne Unterbrechung weiterführen kann. Der Zuschauer darf eigentlich garnicht merken, dass da das (Haupt-)Lichtpult ausgefallen ist.

  • Stagemanagers Punkt mit dem Wildwuchs kann ich leider bestätigen.

    Ich habe auf einer der letzten Pro Light&Sound mit Karl Ruling von der ESTA gesprochen. Ich wollte ein paar Dimmer-PIDs für Preheat, Curves, etc. erfahren, die noch nicht in die Norm eingeflossen sind - er meinte, wir könnten froh sein, dass überhaupt so viel Brauchbares rausgekommen ist und ich sollte für zusätzliche offizielle PIDs ordentlich Zeit einplanen. Da jeder größere Hersteller im Kommitee schon sein eigenes Süppchen kochte, muss es bei der Standardisierung wohl auf Hauen und Stechen gegangen sein...

    Von daher ist Michaels Ansatz technisch gesehen sehr interessant - die Probleme liegen wo anders :rolleyes:

    Ach ja: ArtNet hat RDM-Funktionalität. Das eine schließt also das andere nicht aus. (Man könnte sogar Stefans Ethergate auf RDM aufrüsten, wenn ich mal die Discovery auf einem AVR implementiert habe...)

    VG,
    Hendrik

  • Hoc:
    3 Port Switch in jedem Gerät find ich eigentlich unpraktisch, denn man hat dann wieder das Problem, dass wenn eine Leitung irgendwo kaputt is, is gleich der Rest der Kette tot, dann sind viele kleine Switches teurer als ein grosse, zumal man mit switch im Gerät noch ein paar Ports mehr hat, und zu guter letzt könnt ich mir vorstellen, dass sehr viele Switches in Serie das Signal doch soweit verzögern, dass vielleicht einige Protokolle ein Problem damit hätten.

    @Stageboss:
    Du scheinst da wirklch n bischen Automatisierungstechnik geschädigt zu sein ;)
    Aber mag schon sein, dass du recht hast, auch wenn ich glaube, dass der VA Markt noch n bischen grösser ist als der Automatisierungsmarkt. Bei DMX hat die Standartisierung ja auch geklappt und alle haben sich gerfreut, dass das Chaos der 0-10V Technik endlich vorbei ist. Scheinbar erinnert sich da jetzt wieder keiner dran...
    Und was die Fehlersicherheit von Ethernet angeht, vermute ich, dass wir da verschiedene Dinge meinen:
    Es gibt zwei Sicherheitskritische Anforderungen an ein Netz:
    1. Es dürfen keine falschen Informationen übertragen werden.
    2. Es muss immer möglich sein, gewisse Informationen zu übertragen. (geht Richtung Realtimefähigkeit)
    1 wird von Ethernet erfüllt, 2. nicht (dank CSMA/CD), CAN erfüllt teilweise auch 2.
    Ob beide oder nur Punkt 1 erfüllt sein müssen hängt von der Anwendung ab: Wenn z.B. ein Sensor per Netzwerk angebunden wird und der Walze stopp melden soll, wenn da statt Stahl ein Finger gewalzt wird, dann muss diese Nachricht natürlich auch garantiert ankommen, also is Punkt 2 wichtig.
    Für ne Feuerwerkszündung würde aber 1 reichen, denn die Zündmeldung nicht ankommt startet halt keine Rakete. Aber auch bei Flammensäulen, die man wieder ausschalten will könnte man das so abwandeln, dass ein Paket die Flamme nur für z.B. 0.2s einschaltet, d.h. der Sender muss hier dann laufen Pakete senden, damit die Flamme nicht aus geht.
    Was da jetzt für kriterien bei offiziellen Zulassungen gelten weiss ich nicht, aber ich könnte mir vorstellen, dasses eben genau das ist.
    Und was "kostet im Prinzip nix" angeht: Ich hab extra noch ein "im Prinzip" dabei geschrieben, weil ich beim drüber nachdenken überlegt hab, wieviel zusätzliche Rechenleistung wohl nötig wäre um ein paar ganze besonders kritische Pakete nochmal mit ner 64 Bit Checksumme in Software zu überprüfen und wie komplex der Code dazu wohl wäre und kam zu dem Schluss, dass man so ne 64 Bit Addition wohl in ein paar Minuten hingeschrieben hätte, daher dacht ich, ich setz noch ein "im Prinzip" davor, dann kann keiner mehr meckern... denkste... ;)
    Dass die Zertifizierung Geld kostet geb ich dir recht, kosten aber heutige Systeme doch auch. Und wenn alle VA Welt mal auf Ethernet fährt und nur die Pyrotechnik nicht mitmachen darf, weil der Hersteller leider kein Geld mehr für ne Zertifizierung von nem Protokoll hat, dann muss man halt noch n extra Kabel legen, bis die Konkurrenz genug Geld dafür hat. ;)
    Und wenns um "Software kostet nix" im allgemeinen geht, dann seh ich das ehr als einen Punkt für Ethernet statt dafür DMX aufzubohren, denn wenn ich was neues implementiere wie RDM, dann ist das doch sicherlich auf nem sichereren Übertragungsmedium, welches Funktionen wie CRC und Adressfilter usw. schon in Hardware macht einfacher.

    Quote

    Für die ganzen Techniken, die wir da für wenig/kein Geld nutzen hat irgendjemand mal bezahlt.


    Richtig, aber in den seltensten Fällen wurde die Entwicklung von VA Firmen bezahlt. Das einzig wirklich innovative (im Lichtbereich) sind doch da die Lichtsteuerungen und vielleicht noch paar vereinzelte Dinger, an die ich gerade nicht denke. Alles andere (Datenübertragungen, Schrittmotorsteuerungen, Audio/Videocodecs, Lampentechnik, Dimmer, ...) wurde doch in anderen Zusammenhängen von viel grösseren Märkten entwickelt.

    Quote

    Und heute erwarten wir Innovation für lau...


    Naja nicht für lau, aber dass jemand bereits seit 20 Jahren fertig entwickelte und im einsatzbefindliche und Technik nutzt, weil sie der aktuellen Technik weit überlegen ist. Da da natürlich noch ein bischen was anzupassen ist, darfs ja auch n bischen was kosten. Aber diese Kosten könnten sich doch ziemlich in Grenzen halten, wenn sich die Grossen zusammen tun würde. Zumal wenn man überlegt, dass die Grossen im Moment dabei sind diese "Anpassungen" zu machen, nur halt jeder für sich, dass es nacher halt x-mal teuer is und dafür auch x-mal inkompatibel.

    Quote

    Noch dazu laufen im professionellen Betrieb im Theater immer zwei Lichtpulte parallel, ein "normales" Pult, und ein "Havarie"-Pult, damit, falls das Haupt-Pult mal ausfallen sollte, sofort ein weiteres Pult zur Verfügung steht, welches die Aufführung ohne Unterbrechung weiterführen kann. Der Zuschauer darf eigentlich garnicht merken, dass da das (Haupt-)Lichtpult ausgefallen ist.


    Wobei ich mich da immer frage, was passiert denn, wenn mal was anderes als das Lichtpult ausfällt, ein Kabel oder ein Splitter oder oder oder...
    Haben die dann jede menge Merger rumstehen, deren Eingänge parallel zu beiden Pulten verkabel sind und nur noch der letzte Meter geht zu den Lampen? Wär mir Ethernet halt auch alles viel einf... ok ich lasses... *g*

    Quote

    Von daher ist Michaels Ansatz technisch gesehen sehr interessant - die Probleme liegen wo anders Augen rollen


    Da magst du vollkommen recht haben. Aber in der Automobilindustrie isses nicht anders, nur dasses da der Enduser nicht so mitbekommt... ;)

    Quote

    Ach ja: ArtNet hat RDM-Funktionalität.


    Wobei ich ArtNet nicht wirklich als innovatives Protokoll sehen würde. Das kapselt ja nur DMX und broadcastet alles tot... Gut fänd ich, wenn jede Lampe mit der eigenen MAC-Adresse angesprochen wird, die natürlich mit ner logischen Bezeichnung verbunden is (so dass man beim Patchen kein 48 Bitzahlen sortiert ;)). Dann können sich die Switches im LAN mal so richtig austoben und man könn von verschiedenen Stellen direkt ohne irgendwas umzustellen verschiedene Lampenbereiche steuern usw...

  • Quote

    Original von Michael_D
    Wobei ich mich da immer frage, was passiert denn, wenn mal was anderes als das Lichtpult ausfällt, ein Kabel oder ein Splitter oder oder oder...
    Haben die dann jede menge Merger rumstehen, deren Eingänge parallel zu beiden Pulten verkabel sind und nur noch der letzte Meter geht zu den Lampen? Wär mir Ethernet halt auch alles viel einf... ok ich lasses... *g*


    Hm, die Frage hätte etwas früher kommen müssen, dann hätte ich nachfragen können :)
    Ich würde aber mal davon ausgehen, dass da entsprechend hochwertige Hardware verwendet wird, wo die Ausfallswahrscheinlichkeit sehr gering ist - und sonst kann sich der Dimmer ja immernoch melden, bevor er ausfällt, oder wenn eine Lampe kaputt ist - dann kann man schnell reagieren. Die haben schon gemeint, wenn fünf Minuten vor Vorstellungsbeginn eine Birne ausfällt, dann hat man halt Pech (wenn man nicht hinkommt, ohne dass es ein Zuschauer merkt), aber sonst ist es kein Problem die noch zu wechseln.

    Der Merger hängt meines Wissens recht bald nach den Pulten - ab da ist alles fest verkabelt. Wenn da ein Kabel ausfällt, dann ist die Wahrscheinlichkeit, dass noch was viel wichtigeres ausfällt genauso groß, denn dann ist irgendwas schlimmes wie ein Nagetier, ein Feuer oder ein Erdbeben unterwegs.

  • Quote

    Original von Michael_D
    [...]

    @Stageboss:
    Du scheinst da wirklch n bischen Automatisierungstechnik geschädigt zu sein ;)
    Aber mag schon sein, dass du recht hast, auch wenn ich glaube, dass der VA Markt noch n bischen grösser ist als der Automatisierungsmarkt. Bei DMX hat die Standartisierung ja auch geklappt und alle haben sich gerfreut, dass das Chaos der 0-10V Technik endlich vorbei ist. Scheinbar erinnert sich da jetzt wieder keiner dran...


    Öh - kann mich nicht erinnern, dass ich was gegen DMX gesagt hätte - meine das eher bei Dir verortet zu wissen.
    Ob jetzt pro Jahr weltweit mehr mit dem Kauf von Automatisierung oder V-Technik umgesetzt wird müsste man anhand von Zahlen belegen, insofern kann ich da kein wasserdichtes Statement abgeben (In mir nagen aber Zweifel an Deiner Einschätzung - ich hab nur den Katalog einer klassischen Automatisierungsmesse (SPS in N) und den einer klassischen VA-Messe (Prolight&Sound ohne Musikmesse in F) im Schrank hinter mir stehen - der erstere ist nahezu doppelt so dick...).

    Quote

    Original von Michael_D
    Und was die Fehlersicherheit von Ethernet angeht, vermute ich, dass wir da verschiedene Dinge meinen:


    Die Anforderungen von und marktgängige Lösungen über Ethernet für Pyro kenne ich nicht - ich dachte da an die ganzen Bühnenmaschinen wie Versenkungen, Züge... Die nutzen dann eben die Technologien "safety over ..." bzw. proprietäre Protokolle, die der TÜV abgenommen hat.

    Quote

    Original von Michael_D
    Und wenns um "Software kostet nix" im allgemeinen geht, dann seh ich das ehr als einen Punkt für Ethernet statt dafür DMX aufzubohren, denn wenn ich was neues implementiere wie RDM, dann ist das doch sicherlich auf nem sichereren Übertragungsmedium, welches Funktionen wie CRC und Adressfilter usw. schon in Hardware macht einfacher.


    Da bin ich absolut auf Deiner Seite! Wenn was neues, dann kann das nur auf einer modernen Plattform passieren (und Ethernet ist bei den aktuellen Techniken in der Tat das bezahlbarste), die dann auch moderne Zugriffsverfahren wie Multimasterfähigkeit, Nachrichtenorientiertheit, Anwendungsoffenheit... liefert.
    Das mit RDM ist halt nicht auf der "grünen Wiese" entstanden, sondern der Versuch, die bereits getätigten Investitionen zu schützen und trotzdem eine neue Funktion hinzuzufügen. Dafür finde ich es echt pfiffig.

    Quote

    Original von Michael_D

    Quote

    Für die ganzen Techniken, die wir da für wenig/kein Geld nutzen hat irgendjemand mal bezahlt.


    Richtig, aber in den seltensten Fällen wurde die Entwicklung von VA Firmen bezahlt. Das einzig wirklich innovative (im Lichtbereich) sind doch da die Lichtsteuerungen und vielleicht noch paar vereinzelte Dinger, an die ich gerade nicht denke. Alles andere (Datenübertragungen, Schrittmotorsteuerungen, Audio/Videocodecs, Lampentechnik, Dimmer, ...) wurde doch in anderen Zusammenhängen von viel grösseren Märkten entwickelt.


    Was wiederum für die Größe der Märkte spricht (so in Kohle ausgedrückt)... Der Automatisierungsmarkt hat in den letzten 5 Jahren mindestens 5 standardisierte "Industrial Ethernet" hervorgebracht (und hat dafür der so schön standardisierten Hardware industrietaugliche Kabel, Switches, Stecker... hinzufügen müssen) - und die funktionieren sogar und Knoten damit werden in Stückzahlen vertickt. Da ist doch die Innovationsfreude im Bereich Netzwerke für VA-Technik etwas lendenlahm:D - vielleicht liegt's ja doch an der Bereitschaft, Kohle in die Hand zu nehmen??? Oder der zu erwartende Nutzen rechtfertigt nicht die erforderlichen Mittel.

    Quote

    Original von Michael_D

    Quote

    Und heute erwarten wir Innovation für lau...


    Naja nicht für lau, aber dass jemand bereits seit 20 Jahren fertig entwickelte und im einsatzbefindliche und Technik nutzt, weil sie der aktuellen Technik weit überlegen ist. Da da natürlich noch ein bischen was anzupassen ist, darfs ja auch n bischen was kosten. Aber diese Kosten könnten sich doch ziemlich in Grenzen halten, wenn sich die Grossen zusammen tun würde. Zumal wenn man überlegt, dass die Grossen im Moment dabei sind diese "Anpassungen" zu machen, nur halt jeder für sich, dass es nacher halt x-mal teuer is und dafür auch x-mal inkompatibel.


    Den VA-Technik-Herstellern fehlt an der Stelle vielleicht der Innovationsdruck. Wie geschrieben fühlen sich die Profis ja recht wohl in ihrer Welt, wo der eine ein Audio-Multicore zum FOH zieht, der andere eine 4-universige-DMX-Leitung. Beide kriegen dann noch eine Intercomleitung. Der Videomensch legt "das grüne Spinnenetz" aus... Und warum? Weil jeder für sein Gewerk verantwortlich ist und daher ungern den Kopf hinhält, wenn er durch Benutzung "fremder" Technik irgendwelche Schwierigkeiten kriegt. Am liebsten jeder über ne eigene Türe.
    Andererseits wäre es ein neues Berufsbild: Der VA-Netzwerktechniker - der legt jedem die V-Technik-Dose an seinen Platz und kümmert sich darum, dass dazwischen alle Informationen transparent fließen - ich beginne zu träumen...

    Quote

    Original von Michael_D

    Quote

    Noch dazu laufen im professionellen Betrieb im Theater immer zwei Lichtpulte parallel, ein "normales" Pult, und ein "Havarie"-Pult, damit, falls das Haupt-Pult mal ausfallen sollte, sofort ein weiteres Pult zur Verfügung steht, welches die Aufführung ohne Unterbrechung weiterführen kann. Der Zuschauer darf eigentlich garnicht merken, dass da das (Haupt-)Lichtpult ausgefallen ist.


    Wobei ich mich da immer frage, was passiert denn, wenn mal was anderes als das Lichtpult ausfällt, ein Kabel oder ein Splitter oder oder oder...
    Haben die dann jede menge Merger rumstehen, deren Eingänge parallel zu beiden Pulten verkabel sind und nur noch der letzte Meter geht zu den Lampen? Wär mir Ethernet halt auch alles viel einf... ok ich lasses... *g*


    Nicht mein Zitat - die Redundanzen wird man wohl nach Ausfallwahrscheinlichkeit festlegen. Je komplexer ein Teilsystem ist, desto höher im Prinzip die Ausfallwahrscheinlichkeit (here we go..).
    Also eine PC-Basierte-Lichtkonsole wird voraussichtlich eher mal aussteigen als ein einfaches Stück DMX-Kabel oder ein DMX-Splitter, der ja erst mal nur aus Hardware besteht. Daher ja auch die Affinität der Profis zu Pulten, die wie Pulte aussehen und nicht dauern Treiberupdates von Microbensoft anfordern =)
    Also würde ich persönlich die zwei Pulte irgendwie sync-en, also jedes GO auf dem einen würde die gleiche Szene auf dem anderen aufrufen. Zu Dimmer-City hätte ich dann zwei getrennte DMX-Leitungen und dort einen HTP-Merger. Hängt sich ein Pult auf, geht im besten Fall sein Ausgang auf 0. Sollte die Stimmung stehen bleiben müsste man das "spinnende" Pult vom Strom trennen bzw. DMX abziehen. Wackellampen ggf. verspringend aus 2 Strängen versorgen, die ich aus einem Splitter rausgeholt habe. Dann geht wenigstens die Hälfte noch, wenn sich ein Kabel verabschiedet oder einer in der Kette per Kurzschluß die absolute Datensenke markiert. Die Dimmer hätte ich so intelligent gepatcht, dass der ausfall einer Phase oder eines Dimmerpacks nur einen Teil der Leuchten dunkel werden lässt.
    Aber in Wahrheit hab ich das noch nie gemacht - nur beim ersten Einsatz von DMXC hatte ich noch ein Handpult am Dimmer für Grund- und Saallicht. Leider hab ich's auch gebraucht...

    Quote

    Original von Michael_D
    Da magst du vollkommen recht haben. Aber in der Automobilindustrie isses nicht anders, nur dasses da der Enduser nicht so mitbekommt... ;)


    Das Bild hinkt. Dein Auto stellst Du auch nicht vor jeder Fahrt neu zusammen, also da mal mit 2 Motoren und 4 Gaspedalen, dafür aber nur 1 Scheinwerfer...
    Und in der V-Technik wollen wir eben das. Jede VA sieht anders aus, andere Kabellängen, Kabelwege, benötigte Geräte. Es ist erstaunlich, wie selbst in Häusern mit Dauerstücken (Musical-Halls) alles mit Standardkomponenten gemacht wird (Intercom-Leitungen auf Kabelbrücken quer durch die Flure statt die vorhandene strukturierte Gebäudeverkabelung zu nutzen...), obwohl sich da proprietäre Lösungen manchmal anbieten würden - aber was machste mit 32 kundenspezifisch entwickelten Moving Lights, wenn die Show abgespielt hat?

    Quote

    Original von Michael_D
    Wobei ich ArtNet nicht wirklich als innovatives Protokoll sehen würde. Das kapselt ja nur DMX und broadcastet alles tot... Gut fänd ich, wenn jede Lampe mit der eigenen MAC-Adresse angesprochen wird, die natürlich mit ner logischen Bezeichnung verbunden is (so dass man beim Patchen kein 48 Bitzahlen sortiert ;)). Dann können sich die Switches im LAN mal so richtig austoben und man könn von verschiedenen Stellen direkt ohne irgendwas umzustellen verschiedene Lampenbereiche steuern usw...


    Meine Rede (das mit dem "nicht innovatives Protokoll";). Und das andere, was Du da erwähnst: Klasse Idee! scheib Sie in den Anforderungskatalog für das V-Netz 2015!

    Fehlt eigentlich nur ein kühles Bierchen - solche Gespräche würde ich gerne live führen! Da kommt doch richtig was rum.

  • So, die Antwort hat zwar bischen gedauert, aber jetzt kommt se ;)

    Was die Ausfallsicherheit bei grossen Events angeht:
    Klar nimmt man da gute Komponenten, aber das würde mir bei Events mit mehreren Millionen Zuschauern nicht reichen ;) Auch hochwertige Netzteile und Stecker können mal kaputt gehen. Aber ich erinner mich gerade an die Aktion bei der letzten EM beim Türkei-Deutschland Spiel... Is zwar nicht Lichttechnik, aber so ähnlich. Wenn selbst da kein n-1 Kriterium erfüllt wird, dann isses vermutlich Anderorts auch nicht viel anders. Auch auf den geposteten Bildern gibts ja n paar Single Points of Failure...

    " Bei DMX hat die Standartisierung ja auch geklappt" war nur auf die Standartisierung bezogen, den Rest halt ich nach wie vor für Murks ;)
    Was die Marktgrösse von automatisierungstechnik und VA Technik betrifft geb ich dir recht. Da is die VA Technik wohl doch kleiner.

    Quote

    Das Bild hinkt. Dein Auto stellst Du auch nicht vor jeder Fahrt neu zusammen, also da mal mit 2 Motoren und 4 Gaspedalen, dafür aber nur 1 Scheinwerfer...


    Ich meinte das ehr in die Richtung, dass bei jedem Modell z.B. die CAN Nachrichten anders aufgebaut sind und damit die Seuergeräte der Einzelserien inkompatibel zueinander sind usw.

    Quote

    Ich bin begeistert! Ob man in so einem (schon für Licht) komplexen Netzwerk gerne die Ton- und Videoleute mit drin hat weiß ich nicht.


    Stell dir einfach vor, das wär alles mit Ethernet vernetzt, dann könnte man einfach ne Wolke machen in der Ethernet drin steht und um die sich der VA Netzwerktechniker kümmert und nicht nur Licht sondern auch Ton und Video könnten sich da einstöpseln wo se wollen ;)

  • Quote


    [...]

    Quote

    Ich bin begeistert! Ob man in so einem (schon für Licht) komplexen Netzwerk gerne die Ton- und Videoleute mit drin hat weiß ich nicht.


    Stell dir einfach vor, das wär alles mit Ethernet vernetzt, dann könnte man einfach ne Wolke machen in der Ethernet drin steht und um die sich der VA Netzwerktechniker kümmert und nicht nur Licht sondern auch Ton und Video könnten sich da einstöpseln wo se wollen ;)

    Das wäre ein Fortschritt - allerdings müsste so was nicht nur technisch laufen sondern auch in den Köpfen der verschiedenen Gewerke müssten ein paar "protokollarische" Hürden fallen.

    Weiß jemand etwas mehr über ACN?
    Die DTHG macht während der ShowTech in Berlin eine Vortragsrunde dazu.
    Das scheint so was in der Art sein zu wollen.

  • Newly created posts will remain inaccessible for others until approved by a moderator. The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.