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
ACN
ACN stands for Architecture for Control Networks. Right now, this is RDM’s hyper-clever, super-advanced, mega-powerful cousin that offers a great deal more functionality, in theory. In practice, it’s pretty limited at the moment because no one makes any ACN fixtures. It, too, is an American ANSI standard, arriving at that point after a lot of work by a lot of people over a lot of years, starting before RDM. It used to have a catchier name, Advanced Control Network, but the final version better reflects what ACN actually is.
ACN should offer all of the advantages of RDM and more. The premise is that you should be able to plug in a rig and have it all just work, even if the console and the particular type of light you’re using have never met each other before. An ACN light should carry onboard a detailed description of what it does and how it works: “I am an XYZ9000. I have a dimmer that can go from 0 to 100; cyan, magenta, and yellow that can each go from 0 to 100; a gobo wheel with five rotating gobos; and a strobe that can go from 0 to 100Hz.” If the console already knows about XYZ9000s, it can patch using the information it already has. If it doesn’t, it should be able to automatically build a detailed, working model of the fixture from the information it gets from the fixture itself, the data structured such that no human intervention is required.
Like RDM lights, ACN fixtures have unique identification numbers, but they don’t then have DMX addresses or slots or any of the other paraphernalia of history, not even a limit of 512 devices per universe. You just have one great big ACN lighting system. You patch your desired channel control number to a light’s ID number—no chance for accidentally overlapping addresses—using the same type of “identify fixture” routine as with RDM (and so demanding exactly the same kind of setup tool to assist with established workflows).
Also as with RDM, there is provision for uploading extra information to the light. If a light fails and is swapped out, a smart controller could even automatically notice one light gone, assume the new one is its replacement, and populate it with the relevant information and settings.
Also like an RDM device, an ACN device can talk back to the controller, but whereas an RDM device can only talk back when it is asked to speak, and only one device at a time can answer, an ACN device can send a message (“I’m too hot,” “some external force is moving me”) whenever it likes. The controller (or controllers, since an ACN system can integrate multiple control devices) can do with these as it will. The system can alert operators to problems before they actually affect the lighting on stage, in addition to all of the data-management possibilities opened up by two-way communication. Plus communication over ACN will be quicker; RDM’s speed is limited by the need to coexist with existing DMX data.
The other advantage of ACN is that it controls lights in a completely different way from DMX. Gone is the “go to 50; go to 51” approach. Instead, ACN says, “Light 1, you’re going to pan 26° in five seconds, go.” From the point of view of the art, the lights now know their targets and how long they have to get there, so they can accelerate from rest, move as smoothly as they can, then decelerate to rest—beautiful, smooth, organic movement, color change, or anything else. Potentially, you could even define the acceleration curves to suit each cue. Moving lights could move elegantly again. From a network-geek point of view, it also means less traffic on the network, since, when nothing is happening, the controller could be silent.
“Network?” you ask. Yes, the current requirement is that ACN run over Ethernet; it is designed to coexist with other standard Ethernet protocols, making use of them where required but using its own low-level protocols where necessary, such as to ensure that data gets to the lights in a guaranteed time and in the right order, something that standard Ethernet doesn’t do but which is generally not critical when web browsing. And so yes, we might all end up trying to run complete rigs tied together by those nasty little RJ45 connectors. At the very least, let’s hope for the widespread adoption of the more robust Neutrik EtherCons!
Where things get more complex is that, beneath the hood, ACN is actually a set of tools, an architecture that defines rules for how products talk to each other—“pick up telephone, dial number of backup console, wait for it to answer, start talking”—but doesn’t place any limits on what they then say, just as the phone company doesn’t mind whether you have a conversation in English or German. While the default for sending information from console to lights might be “English,” a manufacturer could choose to use “Polish” for communication between a main and backup console.
This potentially offers great power for multiple types of devices sharing a network. It also makes it tricky to explain what ACN is, in terms of how we, as end users, think of protocols: the Ethernet cable to surf the web, the USB cable to print, the DMX cable to control lights. From that, we expect any two products billed as ACN devices to be able to communicate. That would be immensely powerful. Imagine a rig database program or visualizer listening to the console, updating itself with patch or setting changes automatically and a truly magical improvement on what we have now. Perhaps we’re still a way away from that.
ACN’s flexible nature is also a challenge to manufacturers. It is defined by many interrelated documents, all of which involve techniques fundamentally and radically different from the DMX channel-at-level-and-repeat approach everyone has grown up with. It also needs more computational horsepower than DMX. All of this adds time, effort, and, ultimately, cost. In a world of competitive pricing, this may not be acceptable. The result is that no one currently makes a light that will directly accept ACN. Some lights say they are “ACN-ready,” but that usually just means they have an Ethernet connector and might one day accept a software upgrade to understand ACN.
On the control end, ETC describes its new ETCNet3 protocol as “powered by ACN,” but here, the meaning of ACN is confusing. ETC is using ACN for communication in its own language between controllers and then sending level data to nodes and dimmers using Streaming ACN (more on that below). Other manufacturers who have investigated the process claim that parts of the specification, particularly the Device Description Language (DDL) that lights use to describe their capabilities to controllers, are not yet complete or clear enough to work with.
No lights and no controllers is the chicken-and-egg game again, and this will only change when enough people start demanding ACN for the advantages it brings.
Streaming ACN
Perhaps an unfortunate use of the ACN acronym, Streaming ACN is really “super DMX,” rather than anything offering the benefits promised for full ACN.
What is it? It’s a way of carrying standard DMX data over an Ethernet network to take advantage of the lower cost and higher capacity of Ethernet cabling, able to carry multiple DMX universes down one Ethernet line. In this regard, it is functionally similar to Strand’s ShowNet, ETC’s Net2, Pathway Connectivity’s Pathport, Artistic Licence’s Art-Net, and various others. It needs a compatible console and devices that can understand it or, at the moment, more nodes that can convert the data back into “real” DMX running over 3- or 5-pin XLR cables for final distribution to existing DMX lights.
Advantages over the rivals? Unlike the manufacturer-specific protocols, it is an American standard, open to anyone to implement. From a user perspective, the differences between it and the open Art-Net are harder to spot. Art-Net can already carry RDM information back to a controller using suitable nodes, while work is ongoing to extend Streaming ACN to support this. It is claimed that Streaming ACN scales better to very complex rigs, but Art-Net is currently supported by many more devices. Ultimately, either should let you find, identify, patch, set, and receive feedback from your rig with just one Ethernet cable to your console.
Neither is as elegant as full ACN (no magical creation of detailed fixtures, no super-smooth movement, and still needing management of universes and addresses), and feedback from the lights might not be as quick because of the speed limitations of the RDM portion, but both also have the advantage of being here, now, ready to use. In any application in any industry, that tends to be a compelling advantage.
Continue on Page 3
So Where Are They?
So, now you’re wondering, “If these are all so great, why aren’t they everywhere already?” I suspect that part of the problem is that no one is actively promoting either “brand RDM” or “brand ACN” and their advantages.
In an informal survey of 50 or so random lighting designers and electricians, only three had heard of either RDM or ACN, and only one actually had a clear idea of what either was. If you’ve never heard of something, you’re never going to demand it on your show! By comparison, end users didn’t know they needed USB or Bluetooth but were more than happy to accept them when shown their strengths.
Both protocols have been promoted via demonstrations and talks at tradeshows, but without funding available for glitz, the RDM demos have never really stood out on the show floor, while the ACN talks have historically had a reputation for descending quickly to deep technical levels that discourage real-world users from attending. In either case, visitors don’t learn about the possibilities, and the protocols’ creators miss out on valuable feedback.
Even some people who know about these new protocols wonder why they should pay for them. One rental company owner convincingly argued that, on any given job, he was already paying to have a bright, smart, intelligent crew on-hand to set things up and make things work properly, so why pay more for extra intelligence in the lights? If his crew was doing its job properly, it just shouldn’t be needed. He has a point.
And then there’s the all-pervasiveness of the Internet and the easy access to console fixture files that has clearly reduced the need for a fixture to be able to introduce itself to the console. But, equally, if a setup mistake was made—and we all make them, however careful we are—it would surely be better if it could be fixed from the ground, rather than having to send someone climbing.
And feedback from the lights, with whichever protocol it’s achieved, opens an enormous range of new possibilities. That could be just having the controller tell you which lights have gone missing at power-up or having the system track how long the discharge bulbs have actually been struck so you know when you really have to replace them, rather than making educated guesses. Or it could be a smart system that figures out the colors that are in a scroll or notes that a scroll snapped after 2,000 movements and warns you when the replacement reaches 1,800, so you can replace it before it breaks. You could monitor the data locally or even remotely via the Internet.
These are powerful, useful tools that would help us with our jobs of getting shows on and keeping them looking great, night after night. The irony is that some of these tools already exist and have for years, just waiting for you.
Making Choices, Making Demands
So which protocol will win? Current thinking is that they might just happily coexist. Old, DMX-only lights will be around for a long time, so ACN will handle data distribution around the building, feeding nodes (protocol converters, essentially, as in the early days of DMX) that convert to and from DMX/RDM for the last leg to the lights. In rigging terms, DMX cable’s ability to daisy-chain lights is more practical than Ethernet’s need for splitter nodes. Lights that can talk back will do so via RDM; lights that can’t will have to be set up manually. Such setups are already in use on a number of large-scale projects.
Does that mean we should give up on the dream of full ACN everywhere? No—as rigs get bigger and more complex, and the demand increases for integrating different types of equipment, even beyond lighting, to create spectacular effects, the need for high-speed, reliable data communications will only increase. Given that we have a protocol designed to deal with that, it seems crazy not to press forward with it.
At the end of the day, it all comes down to what people—you, me—ask for and are prepared to pay for. Keep in mind the potential benefits: a little more cost upfront could lead to great savings of time and money over the equipment’s life. If you’re specifying new equipment, you should at least be considering asking for these new protocols for your project.
One thing is very clear: Once you know the technology is there, waiting to save you a trip up the truss or keep a critical cue from being messed up in front of an audience, that’s all you’ll be thinking about next time you have to deal with things the old-fashioned way.
Well, now you know. Spread the word.
Rob Halliday lights shows, programs shows, and writes about shows, and has done so around the world for more than 20 years. There’s a list of the shows and other information at www.robhalliday.com. Some highlights of his writing are available in the books Entertainment In Production vols 1 and 2, available now in paper and e-book formats.