I didn’t know RDM could do that!
Milton Davis (Doug Fleenor), Robert Tooker (PRG), Scott Blair (Chair of the RDM task group), Ulrich Kunkel (E3), Robert Goddard (Goddard Design)
This was a great session with a variety of interesting demos. Here are my notes.
Remote Device Management ANSI E1.20 is done, it’s here, and it’s being rolled out right now.
RDM is a protocol that coexists with DMX512. All DMX512 compliant devices are completely functional when RDM is present. Note: The word Compliant is critical. Anything that sort of uses DMX but isn’t truly compliant may not work correctly.
What does RDM do?
-RDM eliminates climbing up to the device to configure DMX address settings.
-RDM helps to continue the use of DMX512 in environments where an Ethernet control system is not justified.
-RDM gives standardized feedback which is accessible from all remote devices.
-RDM gets you remote configuration and device management.
-RDM is command based but still run on DMX512’s streaming data structure.
Note: If your DMX network has a splitter, the splitter needs to be RDM compliant so you may need to upgrade.
Myths about RDM
#1 There are not many people really building RDM products. From Altman to Wybron, there are over 40 major manufacturers now starting to use RDM in their products. It’s not just “I can do DMX” or “ACN ready”, people are actually installing RDM in their gear right now. We are at a real tipping point where RDM is coming to life. Mostly it’s being implemented on the end devices at this point as this is fairly easy for the manufacturers to do. At this point there are RDM consoles from: Martin, Zero88, ETC, and Ma (very soon).
#2 RDM Discovery is too slow. This depends on the implementation. Many optimizations are built into the standard but are not widely utilized yet. Also depends on the number of device queries after initial discovery of the device (how many questions does the controller ask the device after it discovers the device). Remember that discovery only needs to happen upon setup. As long as your rig doesn’t change, you don’t have to keep running discovery. If you know the manufacturer you can cut the discovery time quite a bit. Because you could tell the console to only search a certain manufacturer’s range. A demonstration was done showing the full discovery process for a screen with 64 RDM devices on it. This took about 2 minutes. A second demonstration with a carefully configured discovery process (the console knew exactly what it was looking for) took about 3 seconds to find the same 64 devices.
How RDM discovery works.
Every device has a 16 bit manufacturer ID followed by a 32 bit device ID. The console sends out a command calling for devices to self Identify. All the devices respond. It then splits the call in half again and again.
For example:
Are there any devices out there?
Devices 2, 49, 76, and 100 respond
The console says, are there any devices below 50?
2 and 49 responds
The console says are there any devices below 25?
2 responds.
The console mutes 2 and then asks if there are any devices below 50.
49 responds and get’s muted... and so on
Note: The Doug Fleenor RDM coffee pot was the first commercially available RDM product. They sold a lot of them very quickly for testing purposes.
Messaging
There is a great deal of information coming back on a Get Command: What class of device are you, what is your manufacturer, do you have any accessories, what is your position, wattage, voltage, temperature, error messages. Do you have subdevices (a scroller power supply is one device with sub devices), what are your sub devices?
Manufacturers can create their own specific commands as needed.
Most RDM communication happens in the idol time between DMX messages. Unlike DMX, there is a pause and careful regulation of the speed of message transmission in RDM. You can still maintain about 32hz of DMX update rate with RDM talking in between. While it’s not 44hz max for DMX, you typically only need DMX to maintain a speed in the mid 20mhz range . Remember RDM really is meant to be a setup tool. So yes it does slow down the DMX stream but if that’s a problem shut it off during performance.
Coming soon in consoles is Auto Patch
You will be able to setup your rig the way you like on the console. Press Auto patch and the console will go find all the devices and patch them so that your preferred patch works.
Queued Messages
This allows a device to tell the console about a parameter change that the controller didn’t ask it make. So a person walks by and changes the DMX address on a device. The console can be told to ask the rig do you have any messages for me? The device will notify the console. There is potentially a lot of information that could come back so this is a feature that has to be triggered from the console in order to prevent bad things from happening mid Que.
Status Messages
Status messages are similar to Queued messages. They allow devices to report errors or warnings back to the console. For example Overtemp, Lamp Out, or Homing Errors.
Sensor Messages
Similar to the messages above. You can have messages about temperature, position, humidity. Many options here all are manufacturer customizable.
Manufacturer Specific Messages
There is a space in the protocol that allows manufacturers to install a variety of custom feedback settings. For example the HES ShowPIX can have images uploaded via RDM.
What’s Next?
The RDM standard is expandable. So as new toys are added a wide variety of messages can be added. There are several new revision/additions to RDM already in the works. So this is not a static protocol it is growing rapidly. One new addition will allow RDM over Artnet.
RDM Protocol forums for more information: E1.20 RDM (Remote Device Management) Protocol Forums - Powered by vBulletin
Milton Davis (Doug Fleenor), Robert Tooker (PRG), Scott Blair (Chair of the RDM task group), Ulrich Kunkel (E3), Robert Goddard (Goddard Design)
This was a great session with a variety of interesting demos. Here are my notes.
Remote Device Management ANSI E1.20 is done, it’s here, and it’s being rolled out right now.
RDM is a protocol that coexists with DMX512. All DMX512 compliant devices are completely functional when RDM is present. Note: The word Compliant is critical. Anything that sort of uses DMX but isn’t truly compliant may not work correctly.
What does RDM do?
-RDM eliminates climbing up to the device to configure DMX address settings.
-RDM helps to continue the use of DMX512 in environments where an Ethernet control system is not justified.
-RDM gives standardized feedback which is accessible from all remote devices.
-RDM gets you remote configuration and device management.
-RDM is command based but still run on DMX512’s streaming data structure.
Note: If your DMX network has a splitter, the splitter needs to be RDM compliant so you may need to upgrade.
Myths about RDM
#1 There are not many people really building RDM products. From Altman to Wybron, there are over 40 major manufacturers now starting to use RDM in their products. It’s not just “I can do DMX” or “ACN ready”, people are actually installing RDM in their gear right now. We are at a real tipping point where RDM is coming to life. Mostly it’s being implemented on the end devices at this point as this is fairly easy for the manufacturers to do. At this point there are RDM consoles from: Martin, Zero88, ETC, and Ma (very soon).
#2 RDM Discovery is too slow. This depends on the implementation. Many optimizations are built into the standard but are not widely utilized yet. Also depends on the number of device queries after initial discovery of the device (how many questions does the controller ask the device after it discovers the device). Remember that discovery only needs to happen upon setup. As long as your rig doesn’t change, you don’t have to keep running discovery. If you know the manufacturer you can cut the discovery time quite a bit. Because you could tell the console to only search a certain manufacturer’s range. A demonstration was done showing the full discovery process for a screen with 64 RDM devices on it. This took about 2 minutes. A second demonstration with a carefully configured discovery process (the console knew exactly what it was looking for) took about 3 seconds to find the same 64 devices.
How RDM discovery works.
Every device has a 16 bit manufacturer ID followed by a 32 bit device ID. The console sends out a command calling for devices to self Identify. All the devices respond. It then splits the call in half again and again.
For example:
Are there any devices out there?
Devices 2, 49, 76, and 100 respond
The console says, are there any devices below 50?
2 and 49 responds
The console says are there any devices below 25?
2 responds.
The console mutes 2 and then asks if there are any devices below 50.
49 responds and get’s muted... and so on
Note: The Doug Fleenor RDM coffee pot was the first commercially available RDM product. They sold a lot of them very quickly for testing purposes.
Messaging
There is a great deal of information coming back on a Get Command: What class of device are you, what is your manufacturer, do you have any accessories, what is your position, wattage, voltage, temperature, error messages. Do you have subdevices (a scroller power supply is one device with sub devices), what are your sub devices?
Manufacturers can create their own specific commands as needed.
Most RDM communication happens in the idol time between DMX messages. Unlike DMX, there is a pause and careful regulation of the speed of message transmission in RDM. You can still maintain about 32hz of DMX update rate with RDM talking in between. While it’s not 44hz max for DMX, you typically only need DMX to maintain a speed in the mid 20mhz range . Remember RDM really is meant to be a setup tool. So yes it does slow down the DMX stream but if that’s a problem shut it off during performance.
Coming soon in consoles is Auto Patch
You will be able to setup your rig the way you like on the console. Press Auto patch and the console will go find all the devices and patch them so that your preferred patch works.
Queued Messages
This allows a device to tell the console about a parameter change that the controller didn’t ask it make. So a person walks by and changes the DMX address on a device. The console can be told to ask the rig do you have any messages for me? The device will notify the console. There is potentially a lot of information that could come back so this is a feature that has to be triggered from the console in order to prevent bad things from happening mid Que.
Status Messages
Status messages are similar to Queued messages. They allow devices to report errors or warnings back to the console. For example Overtemp, Lamp Out, or Homing Errors.
Sensor Messages
Similar to the messages above. You can have messages about temperature, position, humidity. Many options here all are manufacturer customizable.
Manufacturer Specific Messages
There is a space in the protocol that allows manufacturers to install a variety of custom feedback settings. For example the HES ShowPIX can have images uploaded via RDM.
What’s Next?
The RDM standard is expandable. So as new toys are added a wide variety of messages can be added. There are several new revision/additions to RDM already in the works. So this is not a static protocol it is growing rapidly. One new addition will allow RDM over Artnet.
RDM Protocol forums for more information: E1.20 RDM (Remote Device Management) Protocol Forums - Powered by vBulletin