conference session: I didn't know RDM could do that!

gafftaper

Senior Team
Senior Team
Fight Leukemia
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
 
More on this self-discovery thing...
Okay, so the grandPA (doubles as a sound desk) console finds that it has fifty Mario3000s attached. But the fixtures have no idea where they are in the rig. How do I find the unit farthest USR and make that #301, and the next one onstage #302, etc.? If I have to turn on only one light, hunt it down and determine that it's #347, then repeat 49 times until all fifty are assigned user #'s, it's going to be faster to set a DMX address before the light is hung. Also, 331, 333, 337, & 339 have custom corporate logo gobos in them, so those must be prepped in the shop, and must be hung in specific places, so there goes the "just hang any light in any position and the console will figure it out" theory.
Also, since I'm still limited to 512 addresses per universe, I still have to pay attention to how many parameters each fixture uses and what mode, and plan my data distribution accordingly.
I just don't see all that much benefit to "auto discovery."
 
The remote addressing thing does not really intrest me. However, the remote management does. I work in a world that fixtures go into the air and stay there more weeks or months. If the fixture has an error, knowing what the error is would be nice. I still think RDM is going to get leapfrogged by ACN by the time everything talks RDM, ACN will be standard issue. My other issue is that it takes an upgrade of every piece of gear that talks DMX, including Optos from what I have been told.
 
There's an ESTA Protocol magazine article that details Wybron and ETC doing an ACN to RDM connection so that part of the data stream can live on a Cat5 network to gateways/nodes and then talk/listen RDM from the gateway/node out to the devices. The advantage to the ACN to/from RDM link is you can have the Cat5 backbone present as far as you need it then do DMX and RDM to the devices, eliminating the issue of having Cat5/RJ45 jack on the devices and needing a star topolgy Cat5 distribution system out to all the devices.



http://isquint.net/wp-content/uploads/2009/05/protocol_spring09-acnrdm_article.pdf
 
I still think RDM is going to get leapfrogged by ACN by the time everything talks RDM, ACN will be standard issue.

I think you are right and wrong here. The newest version of the ACN standard which is beginning the approval process, creates RDM over ACN. This will pretty much wipe out RDM over DMX, BUT the way I under stand it, it really is RDM, it's just delivered on a network. So it's more a matter of RDM being adopted by ACN than being wiped out.

My other issue is that it takes an upgrade of every piece of gear that talks DMX, including Optos from what I have been told.

According to the session, the RDM standard states that if a device IS DMX COMPLIANT but isn't RDM compliant it must still be able to function normally with RDM present on the system. If a device is not DMX compliant there are no guarantees of anything. They mentioned this in the session as a very common misconception. However, in order for everything else to work all DMX distribution equipment must be RDM compliant. So all the old Optosplitter's must be replaced as they can't listen for RDM's return signal coming back down the line.
 

Users who are viewing this thread

Back