A Look at the Growing Complexity of Fixture Functions and Control Systems
ver the years, the complexity of intelligent lighting fixtures has finally gotten to the point where our own intelligence level has to rise up exponentially just to operate the gear we are using. Take a look around at what the shows we see now differ to the shows that we saw just a few years ago. Now take a moment to think about what we will be seeing in a few years from now. That’s right, those are chills running down your spine.
Where Are We Now?
The complaint has always been that channel counts are too high and that we have way too many parameters to control in intelligent fixtures. I have heard this same complaint since the beginning of the intelligent light era. Well, I can tell you that the channel counts are not going to be dropping anytime soon. Especially when there are batten fixtures out there with 150 channels of control, and they don’t even move or offer pixel mapping. Let’s face it, DMX control as we have known it is on its way out, but we have known that for years. The question on everyone’s mind is, what is the best route to take to control large amounts of data going from the controller to the rig? Is there a silver bullet solution?
Big Fixtures + Big Channel Count = Network Solutions
TCP/IP (Transmission Control Protocol/Internet Protocol) has offered us solutions that seem to be the way to go. There are lots of advantages to using TCP/IP as your method of sending data from your controllers to your lighting rig. It has become common over the past few years because of the fact that almost every modern lighting controller has an Ethernet port on the back of the console and can spit out Art-Net, and sACN. But this is just the beginning of what we can do with TCP/IP and networking. Think it this way. If a DMX cable is a two lane back road, then TCP/IP is a ten lane highway in both directions with preventable traffic jams. With DMX cable, we can only send DMX and RDM protocol and only in one universe at a time. If you go back a paragraph, I mention the batten that can take up to 150 channels to control it. If we do the math, we can only control 3 fixtures on one universe of DMX. That same fixture, when being used over Art-Net or sACN, is not nearly as limited.
Choosing a Flavor
Art-Net has been around for years and has become very popular with sending information from the console to a collection of network nodes, using either broadcast or unicast signal distribution. Those nodes then convert the signal from Art-Net to DMX so that the DMX-based fixtures down the line can be controlled. This method has been great up until recently. Now that we have more and more fixtures that can accept TCP/IP protocols directly on the fixtures, and those fixtures are becoming more and more complex, sACN becomes a better option. sACN transmits in multicast when fully implemented. Multicasting allows one or more consoles on the network to send content to fixtures that have identified themselves as interested in receiving the originating computer’s content. There are other differences, but that is for another article.
Networking Drama
So, we all agree that TCP/IP based control is a great way to control our rig, right? What could possibly go wrong? Lots of things. One of the good points about DMX is that the cabling topology is pretty straightforward — console to Opto splitter to fixtures; that’s it. If you have a flicker in a fixture, just change the cables until you find the problem. This is not so easy with networking. There are a lot of potential points of failure. In a network setup, there a lot more points of interest that can cause you a rough ride on the highway. Typically, your network might be running a few different protocols over it. You might be running the same protocol over different IP address ranges. You might even be using multiple controllers to send information to your rig. Managing multiple protocols is exactly what TCP/IP has been designed for. This is where knowing your network and gear setup becomes absolutely essential. You need to choose what flavor of protocol you are going to send to your lights and where that information is being sent from. For example, I might choose to send sACN from my lighting desk to control all of my movers and Art-Net from a media server to send video content to all of my pixel mapping data. Knowing this information from the start will help you to know what your limitations on universes of control will be.
Oh, and one more thing — grabbing a network switch from the big box IT store might be the worst decision you could make in your system design. If your console is the brain of your system, then the network switch is the heart. This is literally a fact. All of your network information comes in and goes out of the switch. It is the TCP/IP version of an opto splitter. If your network switch is not designed to handle all of that information effectively, you will see lag and dropped information packets on your fixtures in the form of twitches and flashes. You need to make sure to use an entertainment grade network switch with an extremely good throughput. This is one of the most important decisions you can make when it comes to using TCP/IP Protocol.
What’s Next is Here Now
Pixel mapping is all the rage now. Being able to control content easily and efficiently using pixel mappers and media servers like ArKaos Media Master, Madrix or Hippotizer is awesome. However, they don’t do so well with pan and tilt movement. Because of this, a few manufacturers like Clay Paky and Chauvet Professional have developed methods to blend console control and media servers together inside the fixtures themselves. What this means is that we can control a fixture with both a media server and a console at the same time. It works like this: I can operate the fixture function elements like pan, tilt, dimmer, strobe, and control channels in one profile, address, universe, and protocol (like sACN) and then run the pixels from another profile, address, universe, and protocol (like Art-Net). Having this level of control is just starting to become mainstream, but in time, I would be willing to bet that it becomes normal, especially with moving head pixel mappable fixtures.
There is one more protocol on the horizon that looks really cool. RDM Net is extremely promising. Already with TCP/IP protocol, we can use webservers that are built into fixtures to upload software, change parameters of fixture control and preform test functions. But that has to be done using a computer. It can’t be done from the lighting console, at least not easily. This is going to change in the future. With RDM Net, as long as it is fully implemented, we will have full RDM functionality over the entire network of fixtures from the console. It’s in ESTA review now, and absolutely worth checking out.
For a list of upcoming meetings where ESTA members will discuss control protocols and other industry standards, visit plsn.me/ ESTA-TSP-schedule and esta.org.
Michael Graham is Chauvet’s product development manager.
