Remote Device Management (RDM)

[Guest lightnix]

I heard about this for the first time the other day, while visiting the ARC Show in London.

 

Remote Device Management (RDM) is a new protocol (published in 2007) which "piggy-backs" onto DMX, to allow two-way comms between RDM-compliant consoles and devices (e.g. luminaires). This will allow the luminaires (or dimmers or whatever) to report their status back to the console.

 

Having experienced the foibles of V*L Series 200, I've tended to be a bit cynical about the usefulness of reply data; but also understand how it can be handy, especially in large installations, or installations which are not entirely visible from the control position.

 

The Wikipedia entry can be found here.

 

Any thoughts, comments or experience?

[indyld]

As you say, the usefullness of two way data is not hugely apparent in many situations at the moment. Knowing the exact reason you need to reset a fixture or get up there and swap it out is a not huge advantage. Certainly not one to replace all of your DMX splitters and other control systems tomorrow.

 

I believe that the other two way DMX systems were not "taken up" in a big way because they don't fulfill a burning need, not just because they were incompatible with the infrastructure or because they were proprietary. Lighting control system workflow is essentially one way and the "extras" of a two way system are pretty much diagnostic only.

 

I am trying my hardest to think of a way in which a genuine feedback loop could be used in lighting control, such as automatic self positioning/changing based on other fixtures, but even this is acheiveable using software in a one way system. And not really what an operator needs - even with media servers/projectors up to their eyeballs.

 

It interesting that manufacturers are making their latest products RMD compatible but surely this is another white elephant with a a bit of ND over it. Even given the limitation of of DMX over ethernet, discussed here and elsewhere, the next big solution must be something more like a real network. This should have enough flexibility and bandwidth to cope with all our whims concerning multimedia, array control and a load of stuff we haven't thought of yet.

 

Thought provoking question - I am trying to keep an open mind (even if it doesn't show). ;-)

 

// Edit for typo

[Tomo]

The only thing I care about during a show is "Are my lights working?" - I don't really care about the details of an error.

 

Congo does remote error data quite well, although it doesn't yet do RDM directly*.

- When used with Sensor+ or IES dimmers and a DimSTAT server, it pops a little warning triangle in the corner of channels with errors.

 

If I want to see the details of the error(s) I can open the error log, but the warning triangle in the Live display gives me the fact that a problem exists without interrupting me. It's then up to me whether or not I actually care.

 

I'd like to see that extended to moving lights - but so far nobody** is actually providing the data onto the line!

 

Almost all DMX products released in the last few years have been "RDM-Ready", but nobody has actually released code to do it yet.

 

*It's "Ready", but there doesn't seem much point in doing it until there's data to receive.

**Ok - Wybron. But nobody else.

[martinw]

I think the most useful application of RDM is that it will allow parameters usually set by the fixture's internal menu to be set remotely from the console. This means that when you start programming your show, and you discover that a fixture has been mis-addressed or is in the wrong mode, then you can correct this easily from the console, rather than having to drop the rig or get the ladder out.

It will negate the need to go through the process of setting the DMX addresses before your hang the fixtures. I realise that this functionality has been available in a more limited, manufacturer specific form, but RDM standardises this, and should make it commonplace eventually.

 

Martin

[roryfm]

I think the most useful application of RDM is that it will allow parameters usually set by the fixture's internal menu to be set remotely from the console.

 

In theory the DMX 512A standard allows for this (pre-RDM) by allowing manufacturers to send data packets with non-standard start codes allowing proprietary data (such as addressing information) to be sent along the data link.

 

I'm not aware how many manufacturers took up this opportunity to use alternate start codes, yet have come across a cheap controller from Prolight (the iSolution iLead) which allows their equipment (the iMove etc) to self-address, whether if this is done using the alternate start codes I don't know.

 

 

In response to the OP I agree with most of the comments above - there may well be some use for bi-directional communication with fixtures in the future, but we have done quite well without RDM up to now, and so can't really see the need at the moment. However, moving to a bi-directional network, and even to CAN will open the door to more possibilities, it just needs someone to find a need.

With the introduction of error checking and status monitoring there is no reason why stage automation, video (live and recorded) and others could all be interlinked allowing for a much more flexible (and less labour intensive) setup. Once you have bi-directional control it only needs the software to take advantage of the system - for instance automated followspotting (using networked cameras and image recognition/tracking software); interactive lighting (I can't find the document but there have been studies into developing club lighting that alters dependant on the movement of the people on the dancefloor) which again would be much simpler if all the units were networked; etc etc.

 

But effectively I kind of feel that RDM could be a bit useless - the only added value with RDM is that it is backwards compatible with non-RDM equipment (you don't need to buy an entirely new system to implement it) but there are much more elegant ways to implement control, especially now that embedded computing power has increased so much, and come down in price. The downside to these methods however is getting people to move over to the new techniques, and requires the scrapping of existing infrastructure.

[Guest lightnix]

...Almost all DMX products released in the last few years have been "RDM-Ready", but nobody has actually released code to do it yet...

Because there hasn't been any broad scale demand for it.

 

the (lighting controller) manufacturer I was talking to, said that although it was on their product development list, there were other things which had a higher priority and unless a major client (such as Disney) suddenly asked for it, that's the way it will stay.

 

To be fair, the Series 200 feedback was sometimes useful; in the end, the lights were quite good at warning about ropey pan / tilt units before they became visually apparent. It was also handy to be able to see whether the bulb in the non-shining lamp was struck or not. However, a great deal of error messages were generated by duff sensors rather than faulty mechanisms ;)

[HobitLight]

Does RDM send data down pins 4 and 5? If it does, isn't this similar to CMX?

[Ken Coker]

Does RDM send data down pins 4 and 5? If it does, isn't this similar to CMX?

 

No

 

KC

[lichtwicht]

Does RDM send data down pins 4 and 5? If it does, isn't this similar to CMX?

No, due to the fact that some manufacturer misemployed pin 4 & 5 for stuff like power and that lots of equipment have only 3-pin connectors RDM had to be a half-duplex signal, meaning it sends in both directions on the same pair of cables. Of course it would have been nicer if RDM had been full-duplex but that would have meant that the RDM implementation is not just a question of software, but also of hardware.

Actually every piece of equipment that really fulfills every requirement of DMX512-1990 is also RDM compatible. But now you can see how much gear actually doesn't. The major problem is that some gear isn't checking the start code.

 

After dealing half a year with RDM now I can only say that there is a big potential for RDM: Probably not for small Rock'n'Roll but every bigger show or any show that runs for some days can gain easily a benefit out of it. For rental equipment it means that you can save lots of service time by generating service and error reports onsite. And it makes a big difference if you see in advance that a fixture is going to overheat (data of temperature sensor and speed of the fans) instead of waiting till the point where you can really see the damages caused by an overheating. Besides you're able to fix problems during a show before they get visible.

The biggest advantage of RDM lays of course in installations where a systems like Wybron's Infotrace enables you as service partner to do all service checks and service planning without havin to be onsite.

 

To my mind the major reasons why RDM hasn't been a big succes so far are first the missing gear (only a small percentage of fixtures is software wise ready for RDM, hardware wise nearly every modern fixture is able of half-duplex communication) and the secondly the missing knowledge of the market about the features and benefits of RDM.

[peter]

Taking my Zero 88 hat off for a second, but speaking on behalf of manufacturers as a whole, the problem at present with RDM is that it is relatively simple for a fixture manufacturer to implement, but a huge can of worms for the controllers, due to the many unknowns left open by the spec.

 

For a fixture manufacturer, it is simply a case of reporting the status of the sensors/settings they already have on board. These sensors are defined by the mechanical and electrical design of the fixture and can be reported back to the console using defined messaging. All of the sensors and intelligence already exists, its just a case of implementing the messaging back to the console.

 

For a console manufacturer, designing a neat user interface to support the huge host of messages which can be sent to/from the fixtures is something of a problem. RDM messages from the fixtures are only broadcast when requested (acting as a polled system), so for any sort of error checking / status reporting to be effective, the consoles need to send/recieve the status of each of these sensors/settings and note any problems to the user.

 

RDM is also fairly slow - to patch a rig of 100-200 fixtures could take 5-10 minutes using RDM. Imagine plugging up your 4 universe rig and allowing the desk to auto-patch, only to find that you don't have enough channels one one of your universes (of course, the 512 channel limit of DMX still applies) - by forcing us to do the maths on the ground, this saves much re-rigging or re-routed DMX cables. To poll all fixtures in the rig for their status could also have a detrimental effect on the refresh rate of the DMX signal, or result in lags in the status reporting. I don't know if any tests have been carried out on the time it would take to report with 512 individual devices all responding and reporting back to the console. IMHO RDM is much more likely to be used before a show as part of the rig check than able to feedback during a show.

 

Until a number of fixture manufacturers are supporting RDM messages, it's very difficult for the console development teams to devote time to developing user interfaces for an unknown set of messages - they could spend months or years developing menus to allow you to adjust settings on the fixtures, only to find that no fixture manufacturers ever support those messages. It would seem that at present the industry is at something of a stalemate when it comes to RDM.

[lichtwicht]

RDM is also fairly slow - to patch a rig of 100-200 fixtures could take 5-10 minutes using RDM. Imagine plugging up your 4 universe rig and allowing the desk to auto-patch, only to find that you don't have enough channels one one of your universes (of course, the 512 channel limit of DMX still applies) - by forcing us to do the maths on the ground, this saves much re-rigging or re-routed DMX cables. To poll all fixtures in the rig for their status could also have a detrimental effect on the refresh rate of the DMX signal, or result in lags in the status reporting. I don't know if any tests have been carried out on the time it would take to report with 512 individual devices all responding and reporting back to the console. IMHO RDM is much more likely to be used before a show as part of the rig check than able to feedback during a show.

Actually I think personally that auto-addressing is one of the most useless features in most application. To be able to manage a lighting grid you should know at any time which fixture ID within the console belongs to which 'real' fixture and which address that fixture has. You can easily let the system auto-address your rigg but nevertheless your forced to mapp the patched fixtures to your console IDs as probably everybody has his own system for labeling the fixtures. But most ways refer to the physical position of the fixture - an information no fixture knows by itself.

Of course a discovery is no RDM command that should be used during a show. But as RDM message are shorter than a normal DMX frame you can nevertheless collect important information during shows wihout affecting the performance especially as many consoles aren't working at full 40Hz - so there should be enough space within the normal DMX traffic for basic error checks. At least tests with Infotrace worked out.

But I agree that it's not an easy task for console manufacturers: first designing an application that is intuitive, but let you enjoy all benefits of RDM, secondly integrating and supporting the right mix of commands (collecting all necessary data, but not assailing the user with unimportant data) and thirdly make the system show-compatible in a way that it delivers important information within time without affecting the show performance.

 

Finally when we're speaking of RDM management systems we should think for two applications:

First the RDM application within the controller that addresses the needs of the operator, meaning addressing and configuring fixtures and basic error checks.

Secondly independent RDM software applications for the service staff, either backstage or in the repair shop: link through boxes connected to a network or PC that concentrate mainly on status and error reports. One nice feature of RDM is that it allows real systems checks by comparing given to actual values. Doing that onsite during breaks or at the end of the show improves service planning (when an error appears, you don't need to send somebody up the rigg to get the error message but you can already decide whether you probably can fix the error onsite) and replaces in that way some of the service routines, which a good rental shop should do before it sends out the gear for the next project.

 

And if you look closer at ACN you should be aware that it relies on DMX and RDM. So without RDM even ACN is not really bidirectional - apart from the fact that ESTA itself is stating that standards like ACN are not meant to 100% replace the conventional DMX. There are too many problems like network typologies instead of daisy chaining that render normal DMX not useless.

[Dmills]

The other nice gotcha comes as soon as you add splitters into the mix.

 

RS485 is half duplex multidrop but as soon as you use it that way a simple 8 way opto splitter becomes not so simple any more (In fact it becomes a minor nightmare to do correctly).

Sure I can see ways to do it, but where a conventional splitter is basically dumb, an RDM capable splitter must have either a fairly complex state machine or small microprocessor on board.

 

As an aside, I suspect the likely market for RDM is not theatre or even rock shows, but is as an aid to planned maintenance in large semi architectural systems in cruise ships, hotels and the like, where being able to print out a list of blown lamps and locations to hand to the electrotechnical maintenance guys is a big win.

 

Regards, Dan.