Imagine that setting up a new printer was like setting up a lighting rig. Before printing anything, you’d have to figure out an operating address that fit in with the rest of your peripherals and how to set that address using dip switches or some complex menu system. Then you’d have to tell your computer about your printer—address, type, operating mode. Maybe your computer’s heard of that model, maybe not. If not, you’d have to search on the web or cobble together a settings file by hand. Finally, print, but now you just get garbage. Is the address wrong? The mode? The library file?

We don’t put up with this with printers anymore, but we do with lights—a vastly more complex challenge, since you might have hundreds of them. Somehow, address lights, patch console, plug the two together, and hope it all works has become the accepted norm.

The Past, The Present
Why do we work like this? Because we’re pushing a control protocol, DMX512, to do things it was never conceived to do. DMX was designed as an efficient way of relaying levels from a console to dimmers. At conception, its creators thought big. It could control 512 dimmers, an unimaginable number for most installations at the time. Each of those dimmers could be set to a level between zero and 255. The protocol worked very simply: the desk would send a level for all 512 dimmers, and as soon as it was done, it would do the same thing all over again.

It still does the same thing today, but we now have many different types of devices listening to that information. DMX was always an open standard that was relatively easy to implement in terms of both software and hardware. So when moving light manufacturers needed a way of getting control to their lights, many adopted DMX. Now instead of a dimmer reading one “channel” of data, one device might listen to lots of DMX slots, taking the first to be its dimmer level, the second its pan position, third tilt, and so on. The console sends the same numbers, but they are interpreted differently: 256 steps of pan movement, or cyan mix, or gobo selection, etc.

Over time, consoles evolved to present a better user interface to this (“light 1 dimmer, pan, tilt”), rather than relying on the user to remember that was the function of channels 11, 12, and 13. And new tricks appeared to overcome the limitations of DMX’s level data. Sixteen-bit control (two DMX slots controlling one parameter, like the hour and minute hand of a watch where one makes a complete revolution for each step of the other) brought smoother movement and more accurate positioning (256 steps gives less than 1° of accuracy when spread over 360° of pan). But not all attributes are implemented as 16-bit, and those slow changes can still appear steppy (an iris is trying to follow “go to 49…go to 50…go to 51,” moving and then pausing between each level change. It looks inelegant, not the magical movement that used to define the old Vari-Lite VL2s and VL4s, whose control protocol helped them to move smoothly and even ramp up and ramp down motion to provide more subtle starts and stops.

Plus the console still actually has no communication with the light. It just sends out numbers. It has no idea whether anything is listening to them. Nothing can talk back to the console. The only reason it even thinks it knows what it’s controlling—a VL2000 or a MAC 700—is because the operator has told it, patching the light using a fixture library that either exists in the console, has been downloaded from the Internet or, at the very worst, hand-created by the operator.

At the same time, the electrician making the rig work has added a new job to his list: figuring out how to “address” fixtures so they can be controlled correctly. If each light takes 10 DMX slots, the first would have to be addressed as 001, the second as 011, and so on. Set two lights to the same addresses, and they would both respond as one. Accidentally have overlapping addresses, and mayhem will result, the dimmer control channel for one light perhaps also operating the color on another.

When it all works, it does so because we’ve learned to make it work; it’s become our norm, studied on small rigs and just scaled to suit much bigger rigs, thanks to experience and care. The workflow and details are well established: figure out addresses, configure lights in the shop (manually setting the correct address and mode on the control screen of each fixture), pass information to the programmer so the console is patched correctly, and everything meets up in the venue and “just works”…hopefully.

The Future…
Just because it’s the norm, that doesn’t mean we have to be stuck with it, right? Can’t we try to make things better, easier to set up, more helpful?

Take a modern printer again: It’ll warn you when it is running low on ink, letting you preemptively stock up on spare cartridges, rather than suddenly facing blank pages on a critical deadline day. Why can’t lights do that?

Turns out, there are two lighting control protocols—RDM and ACN—that offer, to varying degrees, that help. You might have heard of them, and you might not have. A surprising number of people haven’t, as they’re just busily getting on with doing their jobs lighting shows.

RDM
RDM stands for Remote Device Management, and right now, you can think of it as the more down-to-earth, practical, “let’s just get the job done” solution of the two for setting up lighting rigs. It is an American ANSI standard with a long name that I’m not even going to mention here since that’s the point where many people’s eyes glaze over. Think of it as two-way DMX. Data from the console to the lights is DMX data—512 slots at a time, each of a level 0 to 255—just as it has always been, so no magical improvement to the movement of lights. Everything works just as before, even using the same cables, either 3- or 5-pin XLR.

Except, here’s where it gets interesting: The control system can also ask the lights questions, the lights can actually answer those questions, and the controller can change settings in the light. So if a light is set to the wrong DMX address or mode, you can fix that from the ground, rather than having to send someone up the truss.

If you prefer, you can use this two-way communications ability to set up the entire rig up from scratch. Hang your lights, plug in your console, and tell it to “discover” the rig. It will go out and ask, “Who’s there?” generating a list of all the lights it finds. At this point, each will be identified by the unique identification number hidden away in every RDM-compatible fixture; the list will probably also tell you what kind of fixture it is and how many DMX slots it needs. To figure out which is which, pick one and ask it to identify itself. It will do something—light up, wiggle—to grab your attention. You (or the console) can assign it a DMX address and set that address, then patch it to your chosen console channel number, just as you’ve always done.

Encounter a never-before-seen XYZ9000 light, and RDM might be able to help. The controller can ask the light what it can do, and the light reports back, “slot 1 dimmer, slot 2 pan, slot 3 tilt,” and so on. It may not give you enough information to construct the best fixture ever. In particular, it tells you nothing about the number of frames of gobos or color, or how a particular control channel actually works, but it should give you enough to get going even if you don’t have the fixture’s manual or DMX chart in hand. If the console is clever enough, it could even work with you to create the fixture, though some human involvement will probably be required.

You can also alter the other settings that used to require a visit to the light—operating mode, pan invert, display backlight, more—all from ground level. There is a provision for uploading labeling information from the controller to the light, so that “channel 2, unit 6, upstage truss,” for example, could appear on the unit’s display, so there is less need for tape and a Sharpie (that is, if units even have displays, since they could be configured remotely). And, depending on the functionality the manufacturer has chosen to implement, you may be able to get other information from the device: how hot it is, whether its fans are running properly, whether its lamp is struck, how many times its scroll has moved.

Can you do this with your console yet? Probably not; only a very small subset of lighting consoles yet support RDM. Interestingly, those that do seem split between the very high end of the market (anticipating the use of RDM to manage really enormous rigs, often on huge architectural projects where fault reporting helps keep things going with reasonable staffing levels), and the very low end, where a school teacher with no understanding of DMX or addressing just wants to get some moving lights going.

Of course, a “controller” doesn’t have to be a lighting console. It could be a DMX/RDM test tool, a laptop used to set up a rig before handing over to the console, or even sitting alongside the console. What is still needed is a tool that recognizes the current workflow. On most shows, you just don’t have time in the venue to sit there wiggling and patching lights; you want it done in advance and ready to go. A device that would take a Lightwright-style rig data file, connect to each light in the shop to set the address, collect the RDM ID, and then upload all of that information to the console via a network or using a standard file format supported by all consoles so the patch was ready to go—no re-typing required—would be invaluable.

Above all, it just needs RDM-compatible gear. For years, this has been a chicken-and-egg situation: no lights because no consoles, no consoles because no lights. But an ever-growing trickle of RDM equipment is now creeping onto the market, including lights, consoles, and ancillaries like splitters that now need to handle data moving in both directions. Turning that trickle into a flood just needs more people demanding RDM functionality.

Continue on Page 2