QuoteMir 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
QuoteFü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.
QuoteVernü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. ![]()
QuoteAch ü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. ![]()