RDM verwendet das jemand von euch ?

Warum nutzt ihr es und weshalb ewt. nicht ?

Ist eure Hardware, Geräte ,Splitter etc. RDM tauglich ?

Das mit den Splitter ist nicht so das Problem. Man muss eben nur nach dem Frame Ende die Richtung umschalten. Da immer nur ein Device abgefragt wird kann man die Ports verodern . Man braucht bloß eine Logik die das Framende erkennt und dann die Richtung dreht. Das könnte man sehr einfach bauen.

Wenn man es besser machten will nutzt man die Proxy Funktionalitäten von RDM.

Das größere Problem ist das die Daten auch in die andere Richtung laufen und somit der Busabschluss an beiden Seiten erforderlich ist. Mikrofonkabel macht garantiert ärger.

Das ist wohl in der Hardware nicht berücksichtigt worden. Auch Artnet bzw. ACN kann mit RDM umgehen. So wirklich viel kann das Gerät ja nicht. Geil finde ich auch wenn mal Artnet empfangen wurde das die DMX Eingänge tot sind bis man das Gerät ausschaltet. Als Projekt Leiter hätte ich den Programmierer blöd angeschaut .

Die Funktionalitäten diesen Gerätes kann schon das Projekt zur Verfügung stellen an dem ich momentan arbeite. Deswegen frage ich ja ob das überhaupt jemand benutzt

Mal ein kleiner Einblick was daraus geworden ist.

Der RDM Code ist fast fertig und Unterstützt auch SubDevices.

Fast alles ist implementiert.

Auf den Gerät läuft noch ein Artnet 4 Stack mit 2048 Channels die auf ws2812b ausgegeben werden. Dieser ist auch HTP/LTP kann also mit 2 Controllern arbeiten.

Eigentlich war nur gedacht das Discovery zu Implementieren im Devices zu finden und das Get/SET per Artnet durch zureichen. Nunja nun ist doch geworden

Jetzt habe ich etwas mehr Zeit etwas mich etwas zu dem Projekt zu Äußern.

Es gibt zwei Projekte, Artnet und RDM. Eigentlich sollte der Artnet Code um RDM Fähigkeiten erweitert werden.

Hier wäre deutlich weniger nötig gewesen, die Node fungiert nur als Gateway und muss bis auf das finden der Geräte wenig unterstützen. Nun wurde doch ein RDM Code für Devices geschrieben. Dies unterstützt momentan alle Spezifikationen die das Paper E1.20 u. E1.37 vorsieht. Auch Subdevices, Messages Cues, Status Messages,Sensoren etc. und auch eigene RDM PIDs können zur Laufzeit angehängt werden und werden automatisch unter Support Parameter gelistet.

Die Unterstützung durch Controller ist teilweise mit Fehlern verbunden. Einige Bugs die ich gefunden habe wurde durch die neue Version von Sympholight behoben. Teilweise waren sogar einige Telegramme Käse . Die Unterstützung von RDM funktioniert in Sympholight besser als bei e:cue.

Mit zunehmenden Anzahl an Geräten und Parametern die über den Bus kommen wird die Geschichte immer langsamer. Teilweise hängt das auch mit den Controllern zusammen die unnötiger weise die Parameter immer wieder abfragen. Eigentlich nicht nötig wenn man die queued Messages benutzt. Über ein Messages Count wird der Controller benachrichtigt das dass Gerät eine Nachricht besitzt. Diese holt diese dann ab. Z.Bsp bedient man am Gerät den DIP Schalter um die Adresse zu verstellen erzeugt das Geräte eine queued Messages. Der Controller muss somit nicht dauernd die Startadresse abfragen. Die Buslast wird somit reduziert. Allerdings machten die Geräte die ich habe davon keinen Gebrauch und auch e:cue fragte alle Parameter immer wieder ab.

So ist RDM ganz praktisch auch für nicht DMX Geräte. So ist eine einheitliche Schnittstelle zur Konfiguration vorhanden.

Der Code läuft momentan auf einen ARM. Da das Timing kritisch ist wurde diese sehr schlank gehalten. Das meiste läuft in der ISR ab und das Gerät muss unter 2,8ms Antworten. Mit dem ARM klappt das je nach Telegramm in 50µS für die Norm allerdings zu schnell hier sollten es min 176µs sein .

Es ist vollbracht die beiden Projekte sind verbunden. RDM läuft nun auch über Artnet. So wirklich habe ich noch keine Verwendung, Hardware hierzu zu Entwickeln ist mir zu risikoreich . Zumal es in dieser Richtung ja schon wenige Sachen gibt. Wenn jemand Ideen hat immer her damit. Machen kann man vieles Hier sind alle 3 Projekte dran beteiligt. RDM Device, RDM Controller, ArtnetNode. Das Device wäre mit Einschränkungen auch auf einen AVR lauffähig., bei den anderen Projekten ist der Speicherverbrauch zu hoch. Gerade das Discovery benötigt je nach Baumstruktur Speicher, aber wir reden hier über byte bis kbyte . Beim AVR ist davon als Sram zu wenig vorhanden, für die suche wie auch das speichern der UID Liste.

Ein Splitter wäre auch sehr leicht möglich hier muss man aber unterscheiden.

A: billige Lösungen die die Richtung nur Umkehren.

B: aufwändige mit eigenen Discovery auf jeden Port.

Das mit der Richtung umkehren klappt mit einen AVR und etwas Logik.
Die andere Lösung ist aufwändiger und je nach RAM und Uarts am µP begrenzt auf ewt. 8 Ports.
Ewt. Portiere ich das auch auf den Xmos. Dann sind ohne weiteres 32 Universen und mehr möglich

So ich habe das mal auf einen 8bit AVR portiert und einen LED Dimmer gebastelt . Die Hardware stammt aus einen damaligen Projekt.

Universal Arduino shield

Siehe da auch das läuft ...