When the notion of a control standard finally jelled in the minds of lighting equipment manufacturers, the gates opened on a golden age of lighting control that lasted nearly two decades. Gone were the days when connecting a lighting console to a dimmer rack entailed matching up the control voltage, polarity, connector type and possibly the communication protocol. Any DMX512 console can communicate with any DMX512 dimmer, effects device or moving light. Today, there is a reasonable expectation that if you follow a few basic rules, everything will work together straight out of the box.
DMX512
When the DMX512 data communication standard was developed by the U.S. Institute for Theater Technology in the mid-'80s, computing power was still very expensive. Lighting consoles may have been powered by a microprocessor or two, but such advanced technology was generally not wasted on dimmers. With this in mind, the group devising DMX512 crafted it to work well in dimmers with little processing or data-storage capacity. The DMX specification was slightly amended in 1990 to tighten up timing.
In conventional data networks, devices talk to one another. In a DMX512 system, there is only one transmitting device--either a console, a rigger's remote or a DMX tester. All other DMX devices are receivers only.
Error checking is used in most communications networks to establish that data is getting through to where it's needed without getting corrupted. This usually requires processing by receiving devices to verify the data and then either send a brief confirmation reply or make a request to resend any missing or damaged data.
To simplify receiver design, DMX512 designers approached the integrity problem differently. In the mid-'80s, the only devices that were connected to lighting consoles were dimmers, and the only devices connected to dimmers were luminaires with incandescent lamps. The idea behind DMX512 is that if you resend the data often enough, any occasional missing or incorrect data will only result in a dimmer briefly going to the wrong level.
As the filament of an incandescent lamp has substantial thermal inertia, an occasional and brief wrong level will have little, if any, effect on light output. In addition, DMX512 requires that if a datastream disappears entirely, a dimmer must continue to output its last received level for at least one second. In practice, most dimmers on the market indefinitely hold their output at the last received level.
OTHER APPLICATIONS
On the other hand, motor-driven devices such as color scrollers, moving lights and chain motors do not take kindly to missing or slightly mangled level information, often responding in spasmodic and ungainly ways. This problem is generally addressed by taking great care with cabling and by using DMX distribution and isolation systems to ensure that the data gets through unharmed. An alternative approach is to encapsulate a DMX512 stream inside another data protocol that transparently handles missing or damaged data, and outputs perfect DMX. This is an underpublicized feature of most DMX-over-Ethernet systems.
With the benefit of clear hindsight, there has been much lament that DMX512 is only a one-way data path.
Dimmers long have been capable of reporting their state of health and load status, but no standard existed for transporting data back to the console or monitoring system. Some equipment manufacturers used the second data pair in a DMX512 cable to carry this information, although there is no standard format for transmission and therefore no compatibility between brands (or even models) of dimmers.
The configuration and maintenance of moving lights, with their multiplicity of features and possible failure modes, and their lusty appetites for DMX512 data, would be greatly simplified by two-way data exchange. This was a driving force behind the decision to develop a bidirectional data protocol that could co-exist with DMX512.
The Remote Device Management (RDM) Task Group at ESTA (Entertainment Services & Technology Association) has been working for the last few years to develop a standard that will eventually be known as "BSR E1.20, Entertainment Technology--Remote Device Management over USITT DMX512." The aim of RDM is to conduct a conversation between a host controller and any RDM-capable devices on a DMX512 network.
Although there is a second data pair in any fully compliant DMX512 cable, the standard did not define a use for these wires. In the meantime, the pair has been omitted from some installations and used for other purposes by equipment manufacturers. To make matters worse, despite the DMX512 standard specifying a 5-pin connector, some equipment is fitted with a 3-pin connector.
The RDM Task Group could find no safe path through the miasma that is the "spare" DMX512 data pair, instead choosing to share the primary data pair with the main datastream of 512 channel-level slots. Not only does the RDM network specification have to deal with RDM-capable devices--each communicating bidirectionally with the controller--it also has to define how this can be done without compromising the performance of any standard DMX512 devices on the network.
This is primarily achieved through the use of an expansion capability built into the original DMX512 standard but not widely used before now. Each 512-slot DMX packet is prefaced with a single byte of identifying data known as the start code. Every one of the 40-odd packets of level information sent every second over a DMX512 network starts with a byte set to zero, the start code for normal level information. All DMX512-compliant devices are required to check the start code and only respond if it is set to zero.
The proposed RDM standard requires its data packets begin with nonzero start codes that will be ignored by any standard DMX512 devices. However, some clever equipment designers, upon noticing that all lighting consoles sent out a zero start code, decided to simplify their devices by ignoring it. The very fact that this shortcut went largely unnoticed until recently is proof the trick worked. If you find that some of your DMX512 devices behave strangely when one of the new-generation RDM controllers is connected to your network, get out your DMX tester and try a few nonzero start codes on the suspect equipment.
The first part of the proposed RDM standard defines a method for the controller to discover and identify the devices on a network. This process takes up a fair amount of the available DMX512 bandwidth and is intended to be carried out at a time when the control console is not running a show. Besides, the information being collected during the discovery process is often used to configure the console and the rig before plotting.
The majority of the standard consists of definitions of the type and format of messages that can be exchanged between controllers and devices on a network. Messages from a controller consist of either requests for device parameters and status information, or instructions to set parameters on a device. Messages from a device consist of responses to status requests from a controller.
This offers the possibility of setting the controller to work to contact each of the devices in a rig, collecting its name, network address, DMX footprint and option settings. It can then allocate start addresses based on the information collected, and set up the console with the desired groups and palettes, all correctly identified. The lighting tech could be advised of devices with outdated firmware, which could then be updated over the RDM network. Daily pre-show status checks could be conducted, not only to test each piece of equipment for correct operating voltages, temperatures, fan speeds, etc., but also to identify the luminaires with lamp hours exceeding the preset value for allowable color temperature drift.
During production, RDM status information could be gathered a few times each minute from each device without serious impact on the main DMX512 producton stream. This could allow for pre-emptive maintenance of equipment drifting out of specification. Falling voltages, rising currents, rising temperatures, decreasing fluid consumption and falling light outputs could all be monitored via standard RDM status queries.
The proposed RDM standard is now well on its way through the process of adoption by the American National Standards Institute, having been through its second public comment period with very little adverse reaction. Devices running the current version of the proposed RDM standard were demonstrated at the PLASA show in London last September and at the LDI/ET show in Las Vegas last November. Among them was the RDM version of Doug Fleenor's DMX-controlled coffeepot. Almost every week, another RDM-capable device is released. These devices generally run the current version of the proposed standard but can be updated to run the final standard, once it is approved. It should come as no surprise that some of these devices can be upgraded via RDM.
At the very least, RDM will eliminate the tedious task of setting dipswitches and operating options on the devices in a lighting system. At its very best, RDM is going to have a very significant impact on the way we configure, program, maintain and operate lighting systems.
