DMX RDM - HOW TO USE |
![]() |
RDM-Optionen für Entwickler Unsere Interfaces enthalten einige Funktionen, die Entwickler nutzen können, um Controller-Software anzupassen. Damit lassen sich auch Funktionen einstellen, die Standard-Inkompatibilitäten erzeugen. Gute Controller erkennen das und setzen die Antworten gutmütig dennoch in korrekte Ausgaben um. Die Beispiele sind mit folgenden Controllern erstellt:
Bitte klicken Sie zum Vergrößern auf die Abbildungen
|
RDM options for developers Our interfaces support some functions for software developers. These have been included to improve software development and help designing a more stable controller behaviour. Though some settings may result in slight incompatibility to the RDM standard, a good and forgiving controller should be able to interpret the responses as valid. Descriptions are shown for these controllers:
Please click onto the images to enlarge
|
|||
![]() |
Um die möglichen Optionen zu setzen, schreiben Sie die gewünschten Daten in die SET Eingabezeile. Die Eingabe besteht stets aus 4 Bytes, wobei die Bytes 1-3 eine feste Präambel sind: FF FF 01. Byte 4 wird bitweise zusammengesetzt und besteht aus folgenden Auswahlen:
Minimum- und Maximum-Pegel sind bei DMX RDM als 16 Bit Werte definiert, die je nach verwendeter Auflösung auf die passende Bitzahl maskiert werden müssen. Die Maskierung kann abgeschaltet werden; dann werden stets 16-bit-Werte ausgegeben. Per Broadcast gesendete Kommandos sollten niemals beantwortet werden. Diese Antworten können nicht ausgewertet werden und würden durch Datenkollision mehrerer Responder ohnehin zerstört. Controller sollten die mögliche Antwortzeit frei halten, um nicht neue Telegramme unerwarteten Antworttelegrammen zu überlagern. Bei Footprint "0" soll als Startadresse $FFFF (65535, "ungültig") ausgegeben werden. Controller sollten auch eine Startadresse akzeptieren können, diese aber aufgrund des nicht vorhandenen Footprints ignorieren. Das Kommando führt keine Parameter (es werden keine benötigt). Wäre ein Parameter vorhanden, müßte wegen Formatfehler ein Timeout resultieren. Das ist lästiger, als einen Formatfehler zu ignorieren oder per NACK zu quittieren. Controller sollten all das bearbeiten können. Durch die Statusabfrage mit GET_LAST_MESSAGE kann eine ggfs. verlorene Übertragung erneut abgerufen werden. Der Standard definiert nicht, ob dies wiederholt möglich sein soll. Per Default wird die Sendung so oft wiederholt, wie sie abgerufen wird. Durch das Flag kann der Abruf auf einen einmaligen Abruf reduziert werden. Das Rückstellen der Sensor-Daten erfolgt durch einen SET SENSORS Befehl. Während alle anderen SET Kommandos lediglich ein ACK/NACK zurückgeben, ist der SET SENSORS befehl der einzige, der eine ganze Sensordatenliste retournieren muß. Das ist ein "Guttenberg-Fehler" im Standard (falsches Copy / Paste im falschen Absatz). Controller sollten eine Rückmeldung auch ohne den ganzen Schmus akzeptieren können, wenn dann die Datensatzlänge und die Checksumme stimmt. Personality Null ist nicht definiert. Wir meinen: das ist die aktuell eingestellte Personality. Labels werden meist mit Leerzeichen gekürzt ausgegeben. Der Standard erlaubt, diese jedoch auch mit Leerzeichen zu füllen: aus "DEVICE" wird dann "DEVICE ". Controller sollen beides gleichermassen verarbeiten können. * ab RDM Modul 4.5 verfügbar BEISPIEL: ![]() Per Default sind alle Kontrollbits gesetzt ($FF). Um die Labelausgabe auf Ausgabe mit Leerzeichen umzustellen, muß also Bit 0 nicht gesetzt werden. Daher muss dann die Eingabe lauten: FF FF 01 FE Nach der Eingabe muss das Gerät neu gestartet werden, damit die Einstellungen wirksam werden. Ein WARM RESET genügt. |
To set any options, data must be entered in to the SET parameter field. Entry consists of four bytes with bytes 1...3 forming a fixed preamble: FF FF 01. Byte 4 must be composed bitwise using these selections: (default: all bits set, thus Byte 4 = $FF
Minimum and maximum value setting and declaration are required to be presented in 16 bit format, even for lower resolutions used. Unused bits must then be masked. The masking can be disabled. Commands issued as broadcast commands should never generate an answer. Answers of multiple responders will collide and will be unreadable. Controllers should not start sending new commands within a possible answer time slot as to avoid collision of new commands with unexpected answers. At footprint "0" a start address $FFFF (65535, "invalid") should be issued. Controllers should be able to accept a standard start address and declare this as invalid, if at the same time a footprint zero is detected. This command does not carry any parameters (none needed). If a parameter is present, this would be considered as format error and result in a timeout, since discovery commands should not be NACK'ed. A controller should accept a NACK (Reason) anyhow. Calling QUEUED_MESSAGE using a GET_LAST_MESSAGE parameter retrieves the last message in case a transmission has been lost. The standard does not specify how many times a recall can be done. By default, unlimited accesses to the last command are possible. The flag sets this to single query. Resetting the sensors is done issuing a SET SENSORS command. While all other SET commands only return a ACK/NACK, this SET command has to reply with a list of sensor values. This seems to result from a lazy copy-and-paste error in the original standard. A controller should be able to accept a standard SET command reply (without any sensor data) anyhow, as long as the declared lenght and checksum are correct. A personality zero is not defined. We argue: this is the currently set personality. Labels are mostly returned with trailing spaces removed. The standard says nothing regarding label contents, only label length. Thus it may be possible to fill labels with spaces. A label "DEVICE" would then read "DEVICE ". Controllers should be able to accept any format. * available from RDM Module 4.5 onward EXAMPLE: ![]() All control bits are set by default($FF). To change from truncated output to label output using padded spaces, set bit 0 to 0. Thus the entry must read: FF FF 01 FE Please re-start the device after making configuration changes. Issuing a warm reset will do. |
||
![]() |
||||
![]() |
||||
![]() |
Die Ausführungen geben die Meinung von SOUNDLIGHT wieder. Bitte beziehen Sie sich bei Implementationen stets auf den aktuellen Standard ANSI E1-20 und ANSI E1-37.
Above covers the private opinion of SOUNDLIGHT. Pls refer to the current and official standard ANSI E1-20 and ANSI E1-37 when implementing RDM functionality.
Weitere DMX-512 Produkthinweise:
zurück zur SOUNDLIGHT HOMEPAGE
Letztes Update: 30.06.2016 (C) SLH 1997-2016