I’d Sell My Soul For Total Control

Text:/ Paul Collison

1986. The year of the first ever PC Virus Brain, Halley’s Comet made a visit, Argentina beat West Germany in the World cup, Phantom of the Opera opened on Broadway , John Farnham released Whispering Jack, Neighbours was first aired on TV, Lady Gaga was born and Carey Grant passed away. It was a fairly momentous year however for the entertainment industry, most notably for ratification of the DMX512 lighting control protocol. Advancing from 0 to 10v analogue control and all the various flavours of polarities and pin configurations that encompassed that nightmare, to a packet-based, serial digital standard, that despite a few bastardisations (thanks Martin for the phase-reverse years), was a protocol that became essentially universal. Although several proprietary digitally multiplexed (DMX) control protocols had been around for a while, 1986 was the year that cool heads prevailed and a standard was agreed upon. It was the dawn of a new era of standards-based lighting control. An era that no one could have predicted would last for as long as it has, or be used in so many different and exciting ways. So let’s fast forward to now. 

We have cars that park themselves, email, phones that are smart and planes with showers and beds, so why is it that we still rely on this almost 30 year-old protocol, to dictate the design and functionality of our modern lighting, video and more, control systems? Worse still, why is it that there is absolutely no replacement for his ageing standard on the horizon? 

OK so DMX512 is old – which of course is no reason to suggest those copper cables are all of a sudden useless. Age is not the issue. The problem as I see it, is that we are retarding development of fixtures and control systems, in order to hold on to DMX512. We have consoles that can interpret such parameters as beats per minute, degrees for pan and tilt, and hue, saturation and brightness for colour. And therein lies the problem: they interpret. So if the base data configuration for your specific moving light or control system is incorrect in any way, the operator can move on, blissfully thinking they are talking in real-world values, but they are not. We are basically stringing together various pieces of equipment, and hoping that the data is interpreted properly. The process is akin to “if we get them to trigger this device, then it can send a signal over there, which will make that device do something we want”. Imagine driving a car like that! Be it video, automation or even some basic audio control, we struggle to find comprehensive solutions that can control multiple technologies. Our control desks can get thumbnails from media servers. Great. I still can’t control a timeline with multiple layers from the same control system that can efficiently control moving lights. Then there is stage automation. The lack of error checking and delivery acknowledgement on DMX512 data packets makes it an entirely inappropriate protocol for controlling anything where high levels of safety or repeatability are required.

THE DEVIL WE KNOW… AND LOVE

Don’t get me wrong. DMX512 is not the devil incarnate. Even though on some late nights during my career I might have disputed that. However DMX512 has done a stellar job. I’m unsure whether is was incredible design and foresight, or just good luck, but DMX512 has many redeeming qualities that have taken us so far. For starters, being based on RS-485, it is such a resilient delivery system that it can work on a variety of cable types. (There are some, like AV’s Editor, who claim it will even work over damp string!) It’s effectively-unidirectional, so fault finding is relatively easy once you understand signal reflection and rudimentary fault finding in transmission line systems. Solid XLR connectors keep your connections rigid and reliable. They can be thrown around, stepped on and used to open beer bottles. The strict rule of 512 channels of 256 values per channel, means that there is little ambiguity between manufactures at either end of the cable. We have a strict set of rules to follow, and if we don’t, things just don’t work. So from that perspective, DMX512 is amazing. Checksums (or error checks) weren’t a requirement back in the day when all DMX512 was required to do was control dimmers. If a packet got dropped along the way, things wouldn’t stop. The thermal inertia of a lamp’s filament would conceal the fraction of a second of incorrect current as a result of a missing or mangled data packet. The theory was: send plenty of packets of data and most of them should get through. DMX512 is simple and robust. Perhaps that is why we are desperately clinging to it. 

REMOTE DEVICE MANAGEMENT?

So why this conversation? Why the diatribe against DMX512? Firstly, it seems strange to me that in 2014, we are designing fixtures and control systems for future use, that are still based on a protocol that has for a while now, held us back from real development. We are stuck for a global control platform that can control lighting and video properly. Lighting consoles can trigger video systems fine. However there is no lighting controller that includes intuitive control for video. Automation systems shun DMX512 in favour of proprietary controllers for higher levels of error checking and feedback. Imagine if all your lighting fixtures had cameras in them. Lining up 3D environments and tracking of performers becomes incredibly easy. But we won’t see that technology generally available anytime soon, as we have no way to easily and efficiently plug it all together; and most importantly, control it. I’d love to be able to see a snapshot of my media server input card before I put it on screen. That’s not going to happen easily on my lighting console because all it does is trigger my media server. It doesn’t control my media. These are just a few examples of a plethora of features we can’t have, because we have no means to transport the data efficiently back and forth. “RDM does that” I hear you say? Remote Device Management is becoming a laughable inclusion to the DMX world. Many systems can’t reliably communicate via RDM whilst maintaining a solid DMX signal the other way. The lack of universal adoption of RDM by lighting control manufactures has stalled any momentum the protocol may ever have had. No serious production house I know of has any plans to become RDM-proficient on a company-wide scale. So as an annexe to DMX512, RDM has had little effect on prolonging the life of DMX. 

ARCHITECTURE FOR CONTROL NETWORKS?

“ACN”, I hear some of you say with an earnest tone. “That’s what will save us.” I’ve heard this repeatedly and pondered it at length. Just what is it about the Architecture for Control Networks that is going to change my life? For those who don’t know, ACN is a ‘new’ TCP/IP-based control protocol that in its wider scope, could actually be quite useful to the greater industry with its ability to carry all manner of control information. Its scope vastly exceeds that of mere lighting control and there is a loose roadmap with great ambitions to provide a lean, effective and most of all, freely-available protocol to all. Though the problem here is that the working group defining ACN is made up of industry professionals who meet once or twice a year and have real day jobs outside of the group. So they have little time to lend to the development. Many are from manufacturers who already have established proprietary protocols for their own products, and are in no hurry to replace them. Results are few and far between. Which might explain why it has taken ACN 20 years to be ratified in the current state. That’s right, 20 years! One wonders how much longer it will take to see the full scope of ACN published and ratified. Then how much longer before production companies start to implement it. But will ACN help us? ACN is designed to be able to sync multiple sources of data on a single network. It is designed to be more robust and reliable, and include check sums on all data packets. It also is intended to have maximum flexibility and be ‘future proof’ by being extensible. One of the key points with ACN is that it is to be designed with off-the-shelf TCP/IP networking components and products. We can currently send DMX512 data a thousand different ways along an Ethernet cable, and most of us do that day in day out. When used in the Ethernet world Streaming DMX over ACN protocol, the one part of ACN that has actually been implemented, is much tidier than Artnet, but it really is only a fancy way of transporting existing DMX512 packets over an Ethernet-based system.

THE LAST FIVE METRES

The big challenge, the one that is seemingly being ignored by the entire universe, is the last five metres of the data network. That’s where we still change from Ethernet networks to a daisy-chained DMX cable to get our precious data to a fixture. That is where our bottleneck remains, but here is no solution – coming, proposed, or even publicly discussed. Ethernet is not the answer. For a start, even if your fixture has a basic two-port switch on board, the moment that fixture loses power, the rest of your daisy chain ceases to work. Switched Ethernet will not pass data passively like DMX does through a fixture with no power. A modern Ethernet network really only works in a star configuration, while on the other hand, nobody appears to want to change luminaire data distribution from a daisy chain buss to a star topology. This is quite surprising in light of the fact that we already run power in a star configuration. If we could get over that, then we could possibly consider a connector that distributes power and data. Now that would be cool and would certainly make things more efficient. I’ve never seen that before… or have I? Maybe Vari-Lite was on to something back in the 80s with its Series 200 fixtures that had power and data in a single cable. A star configuration for power and data! Way ahead of its time. Perhaps the grass is greener, or perhaps they were on to something. Sure power and data in the same cable opens up potential problems with interference, etc, but have you looked on a lighting truss lately and seen the copious amounts of data and power piled on top of each other? Or the network cables that snake through the mains feeds? One fundamental problem in all this is the connector type. RJ45 is not going work in a production environment. Even protected in the XLR shroud of an Ethercon, they are just too fragile for the treatment connectors get on productions. Perhaps we could throw back to 75ohm coax and BNC connectors, they’re still working reliably for high bandwidth in the world of SDI video.

The frustrating thing for me, is that there seems to be nothing on the horizon that might signal the start of a new era. At least nothing that anyone is talking about. Perhaps one day, the last five metres might be delivered by some new technology and we may be able to revolutionise entertainment system control. Until then and with a heavy heart, I’ll go back to my 8-bit asynchronous serial data world.

MORE INFORMATION

ANSI E1.11 – 2008 (R2013) Entertainment Technology – USITT DMX512-A, Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories.

ANSI E1.20 – 2010 Entertainment Technology – RDM-Remote Device Management over USITT DMX512 Networks.

ANSI E1.17 – 2010 Entertainment Technology – Architecture for Control Networks (ACN).

ANSI E1.31 – 2009 Entertainment Technology – Lightweight streaming protocol for transport of DMX512 using ACN.

ANSI E1.27-1 – 2006 (R2011) Entertainment Technology – Standard for Portable Control Cables for Use with USITT DMX512/1990 and E1.11 (DMX512-A) Products.

Download these standards free of charge from PLASA: tsp.plasa.org/tsp/documents/published_docs.php