RDM?

Hey guys/gals, back again with a whole topic that I know very little about. RDM. I understand it in concept, but I can't see it ever actually working in reality. I'd love some real-world examples of how it could be used if you don't mind. And I'd also love to know which boards support it, like the T2 that I currently use. Thanks for helping dumb it down for me

I dont understand it but it works great. A plot of LEDs and other devices and fixtures get hung and connected, now the console or laptop "discovers" them and knows what they are and allows you to patch them. I mostly see it in LED hoyselights that each are to get an address. Turn the rig on and tell each one its address. No having to get to the fixture. So, it really does work. Im sure someone will explain how. I dont care, just like not having to tell someone to get out scaffolding.

OrionImagery72 said:

Hey guys/gals, back again with a whole topic that I know very little about. RDM. I understand it in concept, but I can't see it ever actually working in reality. I'd love some real-world examples of how it could be used if you don't mind. And I'd also love to know which boards support it, like the T2 that I currently use. Thanks for helping dumb it down for me

Click to expand...

@jfleenor @Rob @STEVETERRY Would any of you care to reply to our OP @OrionImagery72
Toodleoo!
Ron Hebbard

Ha. I just wrote this to a friend yesterday. Not the Full explanation, but easy for me to cut and paste from the ski hill.

The RDM packets use a non-zero start codes, 0xCC. ANY DMX product built any time recently should propertly ignoring non-zero start codes, even if they do not use RDM. When DMX was ratified, almost all controllers just output all zeros for the start code and reserved that first byte for manufacture specific use. Almost nobody used it, so dead dumb controllers just tossed it aside and started counting 1-512 after the start code. If they still do that, they will get into trouble when an RDM packet comes in and likely behave erratically.

The max refresh rate of DMX is 44Hz. If you slow that down to 40Hz, there is a lot of idle time to do RDM. RDM is a polled protocol. Devices (lights) cannot speak until they are spoken to. So the controller (console or Pathport) drops in a 0xCC packet saying something like "Bob - change your start address to 101" (where Bob is a UID of a light earlier discovered). Then he might put out some more 0x00 DMX packets, then send out another 0xCC "Bob - what is your start address". Then Bob waits a random amount of time for the line to go idle then quickly shouts back "My start address is 101" and everyone is happy.

@Rob 's post reminds me...

All I know about RDM is that:
Whenever and wherever there's an issue of erratic behavior,
the first suggested solution is "Try disabling RDM."!
Kinda makes me think the juice isn't worth the squeeze.

I’ve played with it using an Ion with a rig of Lustr 2’s and D60’s. The console did a discovery and you see a list of gear that are RDM compliant. Note that to do this a lot of things have to be turned on, RDM at the console as well as having any Net3/sACN nodes having RDM enabled. Once you see the list of fixtures you can “flash” them from the desk for the fixture to get some light out the front end. In theory (I think) you can then set an address and patch it. This saves having to set addresses at the fixtures.

Issues I saw were wherever the desk is located you want to be in line of sight to the fixture to know which fixture is flashing. If you’ve got a cluster of stuff that the board op can’t actually see, you then need somebody to see it’s “Ladder Right #6, goes to channel 201”, etc....

Then there’s the issue of mixing non RDM compliant fixtures in the rig. They would want to be on their own node that has RDM off, else you get the issues Derek refers too. As we have a bunch of Elations that are not compliant AND that don’t like RDM, we essentially do not bother with RDM at all and I just automatically set all nodes and the desks to Off.

It's a great idea in theory. It's a terrible idea in implementation for a lot of reasons. Here are a few:

Rdm over dmx is a standard. Rdm over network is not: most installs that benefit from rdm are big enough that you'll have network distribution between your console and your fixtures. Theres no accepted standard on how the network device that translates sacn/artnet to dmx handles rdm. As a result, you need to match the data nodes with the software you use to communicate rdm.

-there's no standard on what properties devices implement over rdm:. Rob's example above is great. That being said, the conversation is more like software: "hey, is anyone out there? What do you want to do today" device 1: "yes, im out here, if your nice to me you can change my address and personality" device 2: "you can change my dmx address and fixture type". As a result of this flexibility, there are no standard fields that devices support. As a result of that, you cannot select a group of similar devices and make a global change (each property is defined on a per device basis). This makes working with rdm frustrating

Only some devices support rdm:. Due to how rdm was retrofit onto the dmx standard, devices that don't support rdm can ruin your day/show if connected to distribution communicating rdm. This isn't always consistent, but when things go wrong everyone knows. As a result, most electricians I know avoid rdm wherever possible. In most cases, the benefits of rdm can be alleviated by planning properly in advance. There's no reason you should need to be making changes to devices once they are in the air and patched. That's not too say it doesn't happen, but in my experience its no faster to use rdm than to change devices by hand.

The industry needs a modernised protocol that enables bidirectional commination. It shouldn't be that terribly hard to do, but rdm is a bandaid, not a cure

I would add that RDM uses the DMX line in a bidirectional manor. Proper use, such as termination, is important to follow.

Installers tell me that the only way to address some fixtures now is with RDM. Tools, such as the DMXcat, come in handy in these situations.

RDM does have its place. This is an instance where it could have been used. That’s an aluminum ladder in salt water above shark tank with an 18’ shark in it (very bottom of image). Ripely’s Aquarium Toronto.

Rob said:

View attachment 17680 RDM does have its place. This is an instance where it could have been used. That’s an aluminum ladder in salt water above shark tank with an 18’ shark in it (very bottom of image). Ripely’s Aquarium Toronto.

Click to expand...

This is going to make me sound like much more of a technophobe than I am, but until rdm can swap a lamp or replace a bad fixture, a plan for access to the light is always going to be necessary. If this plan exists, rdm is less important (how much less? That depends on the expense of reaching equipment... Of course)

danTt said:

If this plan exists, rdm is less important (how much less? That depends on the expense of reaching equipment... Of course)

Click to expand...

Did I mention that the sharks had “frick’n laser beams attached to their heads”?

danTt said:

This is going to make me sound like much more of a technophobe than I am, but until rdm can swap a lamp or replace a bad fixture, a plan for access to the light is always going to be necessary. If this plan exists, rdm is less important (how much less? That depends on the expense of reaching equipment... Of course)

Click to expand...

@danTt The truly impressive part of Ripley's installation was their underwater wireless implementation of the RDM controlled shark. Possibly the aluminum ladder acts as the antennae to route the bi-directional signal into and out of the water?? @GreyWyvern and @Amiers have you any thoughts to contribute? Once @JimRC4 gets the final wrinkles out of bidirectionally communicating through Donald's walls RDM will reign supreme.
EDIT: @Rob Sorry, you added your most recent post while I was typing.
Toodleoo!
Ron Hebbard

While RDM is nice. Every environment I’ve been in we had easy access to before during and after so as we don’t have to worry about a “freaking shark”. Until we start hanging our spares with RDMs I don’t see the need in corporate.

I would say it best suite architectural fixtures that when power goes out and addresses get wonky. You aren’t out there with the glass cleaners on the scaff upside down looking sideways to readdress each figure on that high rise.

Well, when you need to address over 100 led strip lights in cases of 4 or 6 RDM can save a lot of prep time. I’ve found it to be extremely useful.

RDM is a fantastic diagonistic tool. It is a terrible show tool. As many others above me have said, within a controlled environment, it can save a lot of time and hassle with access. My one day shows barely ever use it. Mostly only through a diagnostic tool like a Swisson to check an address or profile on a fixture by interrupting the line from the console.

On installations, I just specified a house light system that would have RDM access so that when a tech does maintenance, they can turn it on and do a sweep for data and problems. Normal operation it will always be turned off. Being able to sweep for maintenance allows the tech to see failed or failing fixtures, operational time, etc.

RDM comes in very handy when an EC installs all of your lighting fixtures in the default setting. When you get into the architectural world access gets more difficult and quantities go up significantly. Addressing after install becomes a lot harder without RDM. Even if you can access them it is a lot easier to stand on the ground with an RDM controller and set addresses than run up and down a ladder/lift/scaffold.

Another more specific example.

When we install dimmers and tape into a set piece we know it works at install but have to re-test after it has traveled in a truck and be re-plugged on set. To re-test we just plug the DMXcat into the dimmer, find it with RDM and run through the channels. This keeps us from having to bother the programmer on the install to do the initial test. Of course, we will test again once DMX is run but we can make sure everything works far before that happens.

There are also some fixtures that do not have a user interface so RDM is required to set the address and modes on them. The ETC D60XTI is a good example.

All of this has been assassinating with something I've not ever dipped my toes into.

danTt said:

Rdm over network is not: [a standard]

Click to expand...

This is about to change--RDMNet was recently voted in. It's making its way through the remaining standards process now.

danTt said:

The industry needs a modernised protocol that enables bidirectional commination. It shouldn't be that terribly hard to do, but rdm is a bandaid, not a cure

Click to expand...

I agree but I'm pessimistic about anything better being accepted in at least the near term. What you describe was all provided in ACN, and that tanked in the market.

And for anyone interested, I do have a chapter on RDM in my book

John

RDM was very useful in a rig that had a separate computer running Concert on the network. I never had to use it directly on their Ion.

My philosophy as a manufacturer is that I can understand the usefulness, and also understand how it can become a huge waste of resources...
We started with RDM about 3(ish) years ago, when we thought that the controller companies had finally begun to figure out how to let people use it (Chicken and Egg...). Since then, we've had RDM in almost every fixture we've launched in Chauvet Professional.

Why it's useful: With the advent of LED lighting, every fixture has become a computer. Now a parcan may have 4 or 5 different options for operating mode (personality), 6 choices for PWM rate, and 4 dimming curves. This is 96-120 possible combinations of settings...some of which will be obvious, and some of which may only become noticeable during programming, or worse, only noticeable when the video guys show up with cameras after the show is already up and running. This has substantially increased the opportunity for people to make mistakes during initial setup and rigging of a show. In a concert environment, you may not find out until the motors have flown. In a theatre, scenery may have been installed below the electrics. It is easier than it has ever been to make a mistake that may be difficult to correct.
Also... Electrical Contractors don't understand any of this. they understand power, and some of them get Data termination. But, very few understand how to adjust the settings on a fixture. When they look at the scope of their job on an installation, they say to themselves "Self, did you put the lights where they belonged physically? Did you get power to them? Did you run the correct spec of control cable, and terminate it according to the chart you were given?" if the answer to those questions was yes, then most ECs will consider their portion of the job complete. If those fixtures are hung on the outside of a building, or hung as pendants above seating in a house, getting up there to troubleshoot data and addressing issues is a GINORMOUS pain.
Using RDM has allowed our fixtures to (mostly) mirror the options in the display via RDM from the console, so that you can make those changes from the ground.

I am still dubious of people who want to use RDM during a show. I (personaly) think this is not a great idea. Even if you're just asking for reporting if a fixture has a problem (thermals out, for instance)… What are you going to actually be able to so about it in the middle of a show? you're better off running a diagnostic before and after, and addressing it then.

The Controller side is where we need to focus next.
We've developed the technology, but still have to figure out how to make it useful for end users...and mostly that means making using these complicated lighting fixtures easier for everyone, but especially less experienced users.
For instance, ChamSys and ETC have auto-patch features in their "entry level" consoles (QuickQ, and Colorsource). This is (to me) a great implementation of the technology. However, it barely scratches the surface of what can be accomplished. The issue for me is not "Is RDM useful", but "How can we make RDM easier, and thus more useful". Finding the right user interface to make the best use of all of these "new" capabilities is what can ultimately make RDM worth having for most people.

While I think this conversation is great... I think the fact that people are scratching their heads about RDM is the problem... In an ideal world, we (lighting fixture, and console manufacturers) would integrate it in such a way that end users wouldn't need to puzzle over whether it is worth learning about... you'd just be happy it exists.

Here is my terrible simile: RDM should be like the automatic transmission. It should make using RDM easier for the majority of users, and enable the geeks like me to lord it over everyone that I can still drive standard (manually address a fixture).