From the perspective of the working lighting technician, stage electrician, or lighting director/designer, the world of control protocols has been stuck in a time warp for nearly 14 years. In 1986, the US Institute for Theatre Technology (USITT) published DMX512, the digital lighting control protocol that revolutionized lighting control by allowing virtually any console to work with virtually any dimmer. A relatively small amendment, designed to address a timing compatibility issue, gave us DMX512 (1990), which remains the standard until this very day, but not for much longer.
DMX512 may not have changed for nearly 14 years, but, under the guidance of the Entertainment Services and Technology Association (ESTA) and the American National Standards Institute (ANSI), there has been much preparatory work for an entire new system of control protocols that will upgrade, extend, and perhaps eventually even replace, this reliable old workhorse.
Unlike the virtually single-handed efforts of the USITT to set the DMX512 and AMX192 standards in 1986, the current revisions and additions are being undertaken using strictly defined standards processes. These are the same procedures now followed worldwide for setting the standards for everything from baby-food containers to lifejackets.
The formal standards process includes working groups that are open to membership by parties with a genuine interest in the outcomes of the standard and meetings that are open to everyone. The proposed standard arising from the working group discussions is then opened for public review on its usefulness, practicability, and suitability for the task.
The working group next examines and responds to each of the public comments, modifying the proposed standard, if required. It then opens the revised standard for further public review. This process continues until there is a consensus between the members of the task group that all issues raised by public comments have been adequately addressed. At this point, the group passes the proposed standard on to ANSI for scrutiny, review, and, eventually, for processing into a full-fledged standard.
This standards revision and creation process has been underway for several years in three separate areas:
-
Since 1998, the DMX512 task group (BSR E1.11) has been revising the 1990 version of DMX512 to bring it in line with changes in applications for the protocol and contemporary equipment design and usage.
-
The BSR E1.20 task group has been working on RDM (Remote Device Management) over DMX512 Networks. This is an extension to the capabilities of DMX512 that allows for two-way communication between the controller and the other devices on the network. While not adding any additional functions to existing DMX512 equipment, it peacefully co-exists with current model DMX512 receiving devices such as dimmers, luminaires, effects equipment, scrollers, and DMX coffee pots.
-
In various stages of development since the mid-nineties, the Advanced Control Network (ACN) is the work of the BSR E1.17 task group. The task is the development of the Multipurpose Network Control Protocol Suite, a sophisticated system intended to eventually replace DMX512. The ACN will be capable of sophisticated interaction between all types of equipment including lighting, audio, video, stage machinery, and possibly even pyrotechnics.
DMX512
The years of work on the next version of DMX512 (to be known as DMX512-A) are nearing completion. Three drafts of the proposed standard have now been made available for public review, the most recent review period being July to September of 2003. All of the issues arising from the public comments have now been addressed. As the issues raised were more to do with clarity of drafting, rather than the technical content of the standard, the recent March meeting of the E1.11 task group recommended that the draft be sent to the ANSI Board of Standards Review for adoption as a Standard. Karl G. Ruling, former technical editor of Lighting Dimensions and ESTA's current technical standards manager, is currently involved in shepherding the final draft through the process of acceptance by ANSI.
Along the way, the January 2003 meeting of the DMX 512 task group chose to separate the matter of DMX512 cabling from the rest of the standard. According to Ruling, this decision was taken because “fighting about it was holding up the adoption of the standard, and wiring technology is changing faster than the rest of the standard, so this will make keeping up-to-date easier,” and “wiring is not really part of a communications protocol anyway.”
This March, the new task group (BSR E1.27) released a draft of the proposed standard for public review. “Entertainment Technology — Standard for Portable Control Cables for Use with USITT DMX512/1990 and E1.11 (DMX512-A)” is available for download from the ESTA web site at www.esta.org. The period for review ends on May 25th 2004, so there is still a little time available to read this proposal and make your contribution to the standards process.
DMX512-A differs from its predecessor in many ways, not all of them necessarily beneficial. The original standard was released for the sole purpose of allowing a lighting console to send a single stream of channel levels to as many as 512 dimmers. As processing power was then relatively expensive, it was considered unlikely that any error checking or data verification system would be incorporated into the receiving dimmers. Thus, the protocol was designed to avoid problems by simply resending the dimmer level data frequently enough to avoid any noticeable glitches being caused by lost data or minor line noise.
Since those days, DMX512 has been pressed into use for many tasks not dreamt of by its progenitors. In particular, the second data pair in a standard five-core DMX cable has had its original “not-defined” status defined in a wide range of incompatible ways by many equipment manufacturers.
Applications for the second data pair have included everything from a second DMX512 stream from the control console, to a bi-directional communication channel between consoles and dimmers. One particularly outrageous application for these wires was as a 25 Volt DC power supply line for ancillary equipment. Rather than attempt to set a single comprehensible and predictable standard for the use of the second data pair, DMX512-A simply documents the different combinations of data paths and gives them all a type number. At least the DC power supply version was not included as an acceptable variant of the system.
Since its inception, DMX512 has had an additional byte of data at the start of each packet. Until now, that start code has almost always been zero and remains as zero for standard operations that simply send out dimmer levels. The new standard allows for other start codes to be used to identify additional applications that may use the DMX data stream. Most of these possible uses are yet to be defined, but provision has been made to control the allocation of start code numbers to avoid any confusion between applications.
One specific start code allocation has already been made for the very useful addition of an optional data checksum to verify the data in DMX512 packet. A checksum is a number generated at the data source by adding up all of the bytes in a packet before it is sent. If the receiving device, such as a dimmer or a luminaire, then adds up all of the data in the packet and compares its own checksum to the received checksum, it can verify correctness of the data. The checksum can't be sent with the DMX512 data, as it would be mistaken for level data. A special DMX512 System Information Packet (SIP) commencing with a start code of 207 is used. The SIP can also be used for a range of other system management and information tasks, although jamming too much system data in between standard DMX512 packets can seriously slow down the responsiveness of the system during a production.
Inevitably, there has to be a trap in using something as simple as non-zero start codes. Many older and not fully DMX512-compliant dimmers were designed on the assumption that there would never be anything but dimmer information on a DMX512 network. These dimmers simply throw away the start code byte without checking its value then treat all subsequent information as data slots. If the first few channels of an older dimmer system start misbehaving when you bring in your brand new DMX512-A console, it's probably time to get out your DMX512-A capable test tool and do a little probing with non-zero start codes.
RDM
The Remote Device Management protocol is still being developed, with only some components of the protocol currently defined. The first draft of RDM was opened for public review between September and December 2003. A demonstration of some of RDM's possibilities was included in the ESTA Interconnectivity Pavilion at both the ETS-LDI 2003 and USITT 2004 shows.
RDM is an extension to the DMX512-A protocol that, in the words of the standard, “allows consoles and other controlling devices to discover and then configure, monitor, and manage intermediate and end-devices connected through a DMX512 network.” It operates over the main DMX512 data link, using data packets with non-zero start codes to initiate and control communications. It operates in polled half-duplex mode, alternately talking, and instructing devices to reply over the data link. The RDM task group chose not to use the second DMX512 data link for return data precisely because of the confusion over its use described earlier.
The types of conversations that RDM devices engage in include: the process of discovery (finding out just what is connected to the network); setting parameters, such as DMX512 channel allocation or tilt inversion on the discovered devices; obtaining status information from each of the devices; and sending out device data as firmware updates or custom dimmer curves.
The group was slightly apprehensive about how the proposal would be received by the lighting community. However, many of the 416 comments received related either to clarifying the wording of the proposal or suggestions for additional messages to be included in RDM's repertoire. “The majority of the comments were very positive and extremely constructive,” reports task group chairman Scott Blair. “We've sorted through and addressed all the comments and have implemented most of the changes into the working draft. We hope to have a clean draft ready to submit for the next public review cycle at the July ESTA meetings and to have completed the protocol by the end of 2004.”
Although there are many devices on the market today that will be capable of running RDM after a simple firmware upgrade, the one serious barrier to the rapid uptake of RDM may be the requirement to replace our entire inventory of unidirectional DMX512 distribution devices, such as splitters and isolators, with more sophisticated and more expensive bidirectional devices.
ACN
Although in gestation for many years, and with the prospect of several more years work before it's ready to become the protocol at the core of all production, the Advanced Control Network protocol had its first public review between September and December 2003. Working examples of some elements of ACN were also on show in the ESTA Interconnectivity Pavilion that appeared at both EST-LDI 2003 and USITT 2004. Devices on display included an ETC Dimmer rack, a Strand 300 Series Lighting console, a Horizon rack-mount playback unit with a small fader panel, a Martin MAC250, a Pathport Ethernet Node, a SandNet Ethernet node and SandNet control software running on a PC.
The proposed standard describes itself this way: “The ACN protocol suite is intended to provide the next-generation standard for the distribution of data in lighting, entertainment technology, and other control networks. Ideally, ACN will unify control networking in its field, allowing a single network to carry many different kinds of data and to connect equipment from many different manufacturers.”
The feedback from the first public review has brought on a flurry of activity from the task group, as they set about simplifying and rationalizing elements of the protocol suite in response to the comments received. They are anticipating having the next draft ready for public review by the July meeting of the ESTA Control Protocols Working Group.
The scope of this task is immense. ACN includes the creation of protocols varying from low-level data transport over media ranging from wireless to optical fiber and copper wire all the way up to application-level protocols that understand cues. It must include fail-safe interactive control for everything from a dimmer to a flying winch, a media server to a Xenon projector, and a wireless in-ear monitor to a gas flame gun.
For ACN to become the glue that holds productions together, several revolutions will be needed in the way that we work. We will have to discard or seriously modify every piece of gear in our inventory. Having done that, we will then have to rethink our entire data distribution infrastructure as we move from daisy-chain transmission lines of DMX512 to the star topology of Ethernet networks.
In the same way that, after 17 years, DMX512 dimmers have not completely replaced all of our older analog and AMX192 racks, an Advanced Control Network is unlikely to replace all of our current equipment. Perhaps it will find a place linking together intelligent boxes such as audio, lighting, video, and machinery consoles, while bridge nodes deal with the interface between the ACN and the legacy DMX512 devices that lie at the network's periphery. Maybe the best bridging technology will turn out to be RDM.