The evolution of RDM over DMX 512

This page introduces RDM by starting with a short history of lighting control, back in the days before the semiconductor revolution, following the progressive development of stage lighting control, through the present day to the future. By following a logical progression, the requirement, purpose and potential application for RDM can be clearly explained.

It all began when dimmers were used to fade stage luminaries in and out of scenes of stage productions. These dimmers were high power rheostats, used to share the load with their luminaries, producing a lot of heat, especially at 50%, when they produced as much heat as luminaries they controlled. These dimmers did not give the operator a view of the stage and were often controlled with a bar, ruler or broom handle to produce a uniform fade.

Other designs were introduced for dimming AC powered luminaries using auto transformers. These transformers or variacs were highly power efficient, transforming the voltage of the incoming power supply to produce the required power level for the luminaries.

What was still required, however, was a better method of control that allowed the broom to be used as stage prop or returned to the cupboard. Complex mechanical controls were developed to remote the control of resistive faders and auto transformers and brought about presets for scenes, giving operators a more manageable system to operate.

In the early 1960s when Thyristors or silicone controlled rectifiers (SCRs) became commercially available, a new generation of power efficient dimmers were produced. This new generation of dimmers work in much the same was as the majority of dimmers work to this day.

A pair of thyristors are used to chop the AC power cycle up to variable durations for each cycle, according to how much power is required, a method known as phase angle control. For 50Hz Power, this equates to chopping the power supply into 100 bursts a second, the duration of the bursts determining the level of power delivered. Advantages of the SCR dimmers include cost and portability. Some readers may remember or have seen portable radios from the 60s and 70s with Solid State inscribed on the case. The development of SCR dimmers meant just that, no moving parts and portable.

The big advance in the context of where we're heading was in the control of the dimmers. The dimmers were generally controlled by a 0 to 10 Volt low power input from a remote location, with some notable exceptions that were controlled by 0 to -10 Volt signal, therefore not always compatible, a point to note.

As the cost of technology came down, so the number of channels generally increased, giving more flexibility and bringing about increasingly sophisticated control systems, afforded by the method of control.

For each channel of lighting control, one or two conductors are required between the control desk and the dimmers. For many installations, this was not initially a major issue. With the rising popularity of portable equipment, the control lines rapidly became more of a problem, giving rise to various manufacturers developing multiplex systems to stream serial data from control desks to the dimmer system. The obvious advantage is that many channels of control are sent via two or three conductors. The down side of the multiplex approach was the lack of interoperability between manufacturer's equipment.

In 1986, the first standardised protocol was published by USITT to resolve the problem of interoperability between manufacturers. DMX512 is a simplex data stream, feeding channel data from the control desk to dimmers, chained together. Each dimmer or channel on the dimmer may be set to pick off the relevant control channels from the serial data stream, the channels being referred to as the DMX address.

Demultiplexers may be used to adapt legacy equipment to the DMX standard, giving the advantage of being able to patch channels from the desk to one or more dimmer channels without the requirement for a vipers' nest of dangling wires and plugs that were once the norm.

The flexibility of DMX512 technology is well suited to fixtures that require a block of control channels, known as a footprint. These fixtures, such as a scanner will have a footprint of four control channels from the DMX data stream, for example, Mirror X-axis, Mirror y-axis, Light pattern and colour. As with dimmer packs, each fixture can be assigned to separate DMX start addresses for its footprint or to share with other fixtures by duplicating the start address from another fixture.

As the take up of DMX continues, so the advantages become ever more apparent. After interoperability, the greatest advantage of DMX512 must be the flexibility to assign any fixture or device to any address, and in the case of the more recent generation of dimmers, it is possible to individually assign each channel in a dimmer to a specific DMX addresses. This flexibility to assign channels is fairly much taken for granted, especially in the mobile applications, where every event may differ from the last.

Now imagine, or just maybe you might be able to recall, the days of patching the dimmer channels behind the stage whilst shouting to the oppo in the lighting box. If you're well equipped, you may have the luxury of an intercom. Surely the sensible thing to do, would be to have a way of identifying each device from the lighting box and assigning the DMX addresses from there. For this to happen, the control system has to be able to not only control the remote devices, but to manage them as well!

At this point in our progression, it has become apparent that the DMX512 standard has its limitations too and would have a brighter future with some form of extensibility. The extension to DMX is achieved by making the data link half-duplex, and re-using the same frame sync method used for syncing DMX frames, for syncing command and response frames and will be referred to here after as RDM.

To legacy equipment that is compliant with the requirements of DMX512, this new frame protocol should be un-intelligible and safely ignored. Not all legacy DMX equipment, however, adhered too strictly to the DMX512 standard, causing unpredictable behavior when used in conjunction with RDM equipment, a lesson to learn and another point to note.

There are two main features of the RDM protocol, firstly the ability of the master unit or controller to discover all compliant devices. The discovery facility specified in the standard allows for the implementation for a virtual plug and play system to be implemented in a similar way to a PC reacting to the insertion of a USB memory stick. If the discovery is not immediate, it can be done on demand. Each item of RDM compliant equipment will have its own unique ID and can be discreetly addressed.

The second main feature of the RDM protocol is the command and response structure that facilitates a master controller to interrogate and configure all known attached RDM compliant devices. With this in mind, go back to the scenario of patching the channels to the control channels of the desk. Now, from the same location as your desk, you have the ability to identify all your fixtures, maybe assign them meaningful names and configure them individually without leaving the comfort of the control box. That has to be better than the advent of the TV remote control.

Now that we have this wonderful system in place, why stop there? There is a bountiful list of documented possibilities in the RDM standard which is not limited by the standard. Power, heat and status values can be queried, warnings and alarms can be set and monitored, there is even scope to reset a tripped circuit breaker on a remote device, although the wisdom of being able to do so may be called in to question.

With the advent of RDM, a new issue arises. Remembering the control voltage that goes from 0 to -10 Volts that was mentioned earlier, we now have the tail wagging the dog. Having a control standard is good when the remote devices all work in the same way, but with RDM, there are many more facets of remote equipment to account for. It would appear to be logical that a lot of the controllers would embrace the flexibility, forward compatibility and interchangeability offered by developing management tools on a PC platform, say the Linux, Free BSD or MS operating systems, with which most of us are familiar. Indeed this is the case for many vendors of stage fixture control systems.

Here is the fly in the ointment. Most OS platforms will not reliably offer the turn around time to strictly meet the timing requirements set out in the RDM standard, especially when interfacing to a DMX512/RDM connection via a USB adaptor. For the DMX512 requirement, the minimum update required is only once a second. For RDM, as response should be completed within 0.0028 Seconds of the command being issued. Many users of bloated operating systems would be happy for a response after several seconds and others would question the requirement for a controller to react so quickly, after all, the controller requested the response. The same view may have been shared by the developers of the DMX512 equipment who chose to disregard the standard, having not taken into consideration, future developments such as RDM.

Hardware dedicated to manufacturers' control system may meet the strict requirements of the RDM standards but lose the main point of interoperability. The meeting of interest of the user is between control tools and the RDM standard, logically speaking, this would be the interface that handles the requirements of the standard and allows the PC platform tools to do what they do best, give the user the experience they expect and require.

If the case has been made for having an intelligent intermediary to interface the RDM protocol to a PC platform having been made, the leading question must then be with what?

Off loading the responsibility of discovering RDM equipment and handling command and response frames leaves application developers free to concentrate on the features of their products. Having the response frame timing handled at the point of command transmission provides the optimum method of frame timing errors which can be reported back to the host application in a coherent and consistent way.

By using an interface such as the RDM-TRI, applications developed to handle the RDM protocol may still do so, whilst applications that employ the services provided by the standard commands will benefit from data and protocol integrity checking. The RDM-TRI also facilitates the configuration of DMX512 settings, using both standard commands with error handling and legacy operation with audible error indication to compensate for the lack of detent in the legacy instructions.

The adoption of RDM has at the time of writing, not reached the critical mass that catapulted DMX512 into every aspect of equipment control. Like the adoption of DMX512, as it gains increased popularity, the way we operate is bound to change significantly. The most obvious advantage to be gained is for the addition of monitoring and remote configuration of equipment where the original DMX512 standard would have been of little or no relevance. It is likely that take up of RDM will be led by touring and hire applications.

© JESE Ltd 2009 to 2014