A simple lighting-control setup might not seem like a network, but it is.
The opinions expressed are mine only. These opinions do not necessarily reflect anybody else’s opinions. I do not own, operate, manage, or represent any band, venue, or company that I talk about, unless explicitly noted.
In an age where everything is connected to everything else, we’re used to the idea of a data network. We hardly give a second thought to computers, tablets, phones, and an ever-growing host of other things talking to each other in an orderly fashion. We live in a world of managed communication.
We’re so used to modern, managed networks that we can fail to see that other communication protocols also fit the definitions used for data networks. While this doesn’t prevent us from using those protocols, we end up understanding less about them than we otherwise might. In the world of entertainment, for instance, I’d wager that a good number of us deploy DMX lighting control without conceiving of it as a data net. I certainly didn’t think of it that way at first.
But if we’re willing to look at things a bit more deeply, we gain tools to understand what’s going on when a system is working correctly – and we also gain ammunition to use when troubleshooting. To that end, I’d like to present some of my observations about DMX networking. These observations are not a primer on basic setup, nor will they directly fix an issue that you’re having. They may, however, help you to grasp a basic setup or suss out a problem.
A basic thing to understand about a simple DMX network is that it uses a “bus” topology. In electronics, a bus is a common conduction line. Networks using a bus topology, then, connect various nodes (lighting fixtures and dimmers, for example) to a single “data pipe.” If the bus becomes interrupted at a point, all nodes downstream of the break are unable to receive or send communication. However, nodes upstream of the problem can be just fine. If a lighting rig loses control of half the fixtures due to a cable being broken or accidentally yanked, the still-connected half should still receive control.
With a bus connection, an important concept is that each node can be completely non-dependent on the other nodes – with the exception of whatever node handles the original data transmission. As long as the common signal line stays intact, the removal of a non-transmitting device has no necessary effect on other devices. Pull a light “off the line,” make sure the cable is reconnected, and all the other lights will continue working.
Larger, more complex DMX networks can make some use of a star (or star-like) topology. Active DMX splitters receive signals from a DMX bus, and then retransmit those signals along additional signal lines. Each line then becomes a bus along which a number of fixtures can be connected. If the splitter is operating correctly, a problem with any single “child” bus will not directly affect any other child bus or the parent signal line.
This Connection Is Connectionless
When a DMX controller is talking to a fixture, it’s using a connectionless protocol.
“Wait a second,” you might be saying, “lights and dimmers have to be connected to the DMX signal line in order to work. How can DMX be connectionless?”
What I mean by this is that DMX is connectionless in the logical sense. Yes, each node has to be physically connected to the signal line, but a DMX controller and a DMX-enabled fixture don’t negotiate any communication parameters with each other. In the world of DMX, data transmission occurs on a “ready or not, here it comes” basis. If the controller is told to transmit a number of instructions for, say, DMX channel 10, then those instructions are transmitted whether a node is listening for instructions on channel 10 or not.
This isn’t to say there aren’t connection parameters, of course. It’s just that the connection parameters are not determined by communication over the network media. All the necessary connection configuration is stored in the devices used. The DMX controller is built to communicate in accordance with the DMX standard, as are the lights and dimmers. Further, the lights and dimmers are set up by the user to listen on a pre-arranged set of channels. Once all this is set, the only way to change it (on a simple DMX network) is to do so by hand.
We’re Out Of State
Simple DMX, being connectionless, is also stateless. Because the DMX controller has no knowledge of whether a fixture is receiving or not, any communication that gets sent has to be completely “understandable” without regard to any prior communication. Also, the controller is ignorant of the fixture’s actual control state. This necessitates that any request for a certain control state (what color the fixture should be producing, where the fixture should be pointing, etc.) has to be fully self-contained in order to be reliable. For example, to guarantee that an RGB fixture is set to produce a yellow color, the non-zero red and green intensities have to be requested alongside a request for a blue intensity of zero. If the blue-at-zero request is not sent, then the current dimming level of the blue emitters will not change.
This might seem surprising, especially if you use DMX software that shows you the supposed control state of the fixtures. You might have signaled your fixtures to give you an amber color, with the software showing the fixtures as producing that color, and the fixtures themselves physically producing the correct color. It seems that the software knows the control state of the fixtures, but it doesn’t if the DMX network is a simple one. The software knows what information has been supposedly sent, and what that information should mean…if everything is working as expected. The light-control program is simply making the powerful assumption that the control state of the lights matches the requests that were sent. It does not actually know what’s happening down the line.
A Parting Word
You may have noticed that, at several points, I have qualified my descriptions with the idea that they apply to a “simple” DMX network. This is because there are protocols and technologies that can be used in conjunction with DMX that have a great deal more functionality. For instance, it’s entirely possible – using Art-Net – to encapsulate DMX data so that it can be transmitted using Ethernet-based equipment and Internet protocol. RDM allows for DMX controllers to actually know something about a fixture’s state. This article’s scope doesn’t include these concepts, because the point was to discuss the “plain vanilla” DMX networks that are commonly found in small-venues.