Text:/ Paul Collison

YOU’RE SOAKING IN IT!

Most recently-made data splitters and DMX paraphernalia are likely to be RDM compliant. Although many come with the option of disabling the RDM functions, it would be no surprise if the average lighting company or venue already had RDM-capable equipment. You may find enough bits and pieces to make your next lighting system fully RDM compatible. Of course don’t just think that RDM is restricted to DMX-controlled luminaires – anything from smoke machines, media servers and automation systems to environmental controls and remote PTZ cameras have the potential to be managed by RDM.

The idea of RDM is an elegant one. From a convenient location you can access the features of individual devices remotely. You can change the mode, the DMX address, inhibit features or invert channels. Anything that can be modified on a device’s interface should be accessible via RDM. Then there is the error reporting aspect. Your fixture can report directly back to your interface with lamp failures, calibration errors and even power loss. So the lighting technician may indeed be made aware of a blown lamp or other fault, well before the LD. In theory, a production house need not bother with doing a DMX patch prior to the job. They can throw luminaires up all over the place and then the operator can just address and manage the fixtures as they come online. Sounds great… or is it?

Let’s look at the practicality of a few of the main selling points of RDM. Firstly, I don’t know of a production house that would send a serious lighting system out where all fixtures aren’t first prepared individually and addressed. Giving a luminaire a DMX address in the shop is not time consuming, and is just part of a normal prep. So the idea of sending a fleet of fixtures out that have no specific physical position just screams inefficiency to me. I can see people on site chasing cases all over a venue. Secondly, do we really need notifications of problems when the light thinks there is a problem, or should we just rely on observation? If the washlights upstage never change colour during the show, do I care that there is a colour calibration issue in one of those fixtures? Will I be sending a tech to fix a problem that I would never have known about?

Don’t get me wrong, I’m no Luddite. I’d like to embrace RDM, as I like the idea of being able to change the mode of a light, or the DMX address if there is cause to do so. I’d like to be notified that a lamp has gone offline at some point. I can see real benefits of such a system. Part of the lack of my uptake is the fact that manufacturers of both lighting devices and controllers are yet to arrive at a collaborative approach. There appears to be no real consistency to the type of information garnered, or how it’s presented to either a technician, or a console operator.

WHERE THE RUBBER HITS THE ROAD

ELC is one company which has embraced RDM to a reasonable extent. Its dmXLAN software has some really great features. So long as you are using its nodes, you have the ability to print out daily reports for maintenance and get live error reports on the run. DmXLAN even has a graphical layout of your lighting system for testing and reporting. The software works in parallel with your lighting control system.

Robe has a proprietary box called RDM Communicator. It is a funky little battery-operated box that allows the user to change user options and report fixture status across multiple fixtures. Of course it only works on Robe fixtures and is designed as a maintenance tool and not for use with an active lighting system.

Martin has one of the better ecosystems for RDM from its M Series of controllers, allowing for reporting and interaction directly from the console surface. Again however, it is primarily designed to work with Martin fixtures directly attached to the console.

MA have a rather rudimentary RDM interface that works with any RDM-enabled fixture. However this area of the software is still under-developed and waiting for the lighting community to stamp their feet and demand a bigger RDM feature set. Then of course there was Infotrace, from the late, lamented Wybron, which won innovation awards at the PLASA and LDI shows way back in 2006. So collectively, we seem to be dabbling in RDM, but most companies seem to have a wait and see approach rather than driving innovation the way they have in other areas.

PRE-HISTORIC RDM

It’s worth noting that bi-directional feedback is far from revolutionary in the lighting control world (think back to when hipster beards were cool for the first time). Bytecraft, AVAB and ETC control systems found in all the TV studios and prominent venues had control system status monitoring and feedback. Although the systems were only communicating with dimmer racks, there were still capabilities for DMX channel assignment, dimmer curve allocation and warnings of overloads and circuit breaker status. What’s interesting is that when all of these organisations traded up to newer and more fancy control systems, the majority of these bidirectional feedback systems disappeared. Here we are, some 20-odd years down the track, talking about bringing these features back. Albeit in a bigger, better, faster way.

THE CHALLENGES ON THE ROAD AHEAD

This may shock you, but there are still some cheaper fixtures out there that do not fully follow the DMX standard with their start code data. So enabling RDM on your DMX network may cause unprecedented mayhem and bring your control network to a screaming halt. It becomes very obvious very quickly that certain fixtures and brands will just not work with RDM. So make sure you test your system thoroughly in the shop or between productions before heading out to your next show with you RDM guidebook in hand.

One of the main problems facing RDM is that the protocol, while being clear on the network communication aspects, is less than so when it comes to just what content and parameters the consoles and fixtures will exchange, and how that information is delivered to the users. Back in the mid-’80s, DMX512 was introduced into a landscape that had little or no other options for digital data communications. By contrast, RDM must compete with proprietary systems from a range of manufacturers and rely on co-operation between companies that traditionally are in a sales war and are actually relishing the opportunity to bring back the pre-DMX proprietary lock-in. I believe when RDM finally becomes integrated properly in to lighting control systems, we’ll have a truly powerful tool

ELECTRIC DREAMS

So you can see that RDM is starting to gain a toehold. However, the real power of RDM will be when the protocol is delivered directly back into the console and interacts with your show data. Imagine a cue list that warns that in cue 20, you’re missing one of the lights that are programed in that scene. Or the colour error on fixture 12 is going to affect your look in cue 45. Maybe even that your smoke machine fluid level is running low and therefore the smoke cues in your list may not be completed by the end of the show. I’d like to scan my fixture list and see if all fixtures are online or if one is missing, without having to go looking for that information in an obscure menu. When reporting like that comes along, in an integrated and instantaneous way, then we may see a rapid increase in its uptake. Until then, I fear that RDM will languish in the corner, and be “that feedback thing yeah?”