Developed by the Engineering Commission of USITT, the standard started in 1986, with subsequent revisions in 1990 leading to USITT DMX512/1990. In 1998 ESTA began a revision process to develop the standard as an ANSI standard, including a Public Review process. The revised standard, known officially as "Entertainment Technology — USITT DMX512–A — Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories", was approved by ANSI in November 2004. This current standard is also known as "E1.11, USITT DMX512–A", or just "DMX512-A", and is maintained by ESTA.
DMX512 was originally intended as a 'lowest common denominator' protocol for use between interfaces supporting proprietary protocols. However, it soon became the primary method for linking not only controllers and dimmers, but also more advanced fixtures and special effects devices such as fog machines and moving lights. DMX512 is unidirectional and does not include automatic error checking and correction, so it is not safe to use for applications involving life safety, such as controlling pyrotechnics. MIDI is sometimes used for this task.
The connectors themselves must be five-pin XLR, although only three pins of the five are always used. Some manufacturers have used three-pin XLR connectors and some light fixtures have been produced with a TRS connector jack for DMX connectivity. Although this is a violation of the standard, the trend in professional equipment is towards compliance with DMX512-A. DMX512-A prohibits use of any connector other than a 5-pin XLR unless there is not physical space on the device for that connector, in which case an adapter must be supplied.
Cabling for DMX512 was removed from the standard and a separate cabling standards project was started in 2004. Two cabling standards have been developed, one for portable DMX512 cables and one for permanent installations. This resolved previous issues arising from the differing needs of cables used in touring shows versus cables used for permanent infrastructure. In addition, cable performance is now specified with regard to nominal impedance and capacitance to provide guidance as to what constitutes an acceptable cable. For example, microphone and line level audio cables do not have the correct characteristics and should never be used for DMX512. The significantly lower nominal impedance and significantly higher capacitance of these cables distort the DMX512 data which can cause irregular operation or intermittent errors that are difficult to identify and correct.
Data Plus (pin 3) and Data Minus (pin 2) are the reverse of sound cables, and the signal travels in the opposite direction to the pins (female is out, male is in). The pin layout from DMX512-A is :
1. Data Link Common
2. Data 1- (Primary Data Link)
3. Data 1+ (Primary Data Link)
4. Data 2- (Secondary Data Link)
5. Data 2+ (Secondary Data Link)
Despite the convention, devices from some manufacturers swap the polarity of pins 2 and 3, requiring the use of a crossover cable or adapter. Many lighting desks are equipped with a polarity selector so that, if an entire universe of fixtures is of the reverse polarity type, no adapter is required.
Each DMX512 data link transmits a start code that identifies the data type and up to 512 eight-bit values, between 0 and 255, so one cable typically controls 512 dimmers or device attributes. Because DMX supports only 512 channels per data link, multiple DMX universes can be used in situations where more than 512 control channels are needed. A universe refers to a DMX512 data link from the console, and all of the devices on that data link. Many newer lighting consoles support multiple DMX universes, which must be cabled independently. Sometimes this is done intentionally to partition the control into units, for example dimmers and moving lights might be on separate data links even though neither link uses all 512 data slots.
DMX512 data is sent using EIA-485 voltage levels and cabling practices. The DMX specification refers the reader to EIA-485 for information about the electrical signal. Data is transmitted serially at 250 kbit/s and grouped into packets of up to 513 bytes, called 'slots' in DMX512-A. The protocol uses 1 start bit and 2 stop bits with a little endian data format. The start of a packet is signified by a break of at least 88uS followed by a "Mark After Break" (MAB) of at least 8uS, extended in 1990 from the 4uS specified in the original 1986 standard. The break is a signal to receivers to start reception. After the break up to 513 slots are sent. The first slot is interpreted as a "Start code" that tells receivers what kind of data will follow. For lighting fixtures and dimmers a start code of zero is used. Other start codes are used for Text packets or the System Information Packet (SIP), proprietary systems, or for the RDM extension to DMX.
The remaining slots make up the actual level data. Up to 512 slots can be sent, and it is the job of the receiver to count the slots to keep track of the channels. As there is no error detection or correction in DMX, it is vitally important for receivers not to miss slots, and to discard packets if framing or buffer overflow errors are detected.
A full packet takes approximately 23 mS to send, corresponding to a refresh rate of about 44 Hz. For higher refresh rates, fewer channels can be sent. This is accomplished by simply starting a new packet before all 512 channels have been sent. The minimum packet length is equivalent to 24 channels. Most transmitters send all 512 channels because many receivers have trouble with shorter packets.
Conventional dimmer packs or racks use a group of slots to determine the levels for their dimmers. Typically a dimmer has a starting address that represents the lowest numbered dimmer in that pack, and the addressing increases from there to the highest numbered dimmer. As an example, for 2 packs of six dimmers each, the first pack would start at address 1 and the second pack at address 7. Each slot in the DMX512 packet corresponds to one dimmer. Some dimmers use profiles to interpret the level being received. A linear profile means the output directly corresponds to the received DMX512 level, but other profiles behave differently. A preheat profile might keep the dimmer at a level of 5% until the received DMX512 level exceeds 5%, and respond linearly after that.
Moving lights use adjacent DMX512 channels to control different aspects of their behavior. These attributes may, for example, be laid out as:
The gobo channel may allow groups of values to select gobos, i.e. 0-20 No gobo, 21-40 Gobo 1, 41-60 Gobo 2, etc. It may even allow for gobo rotation, i.e. 21-25 Gobo 1 (No rotation), 26-40 Gobo 1 (Slow - Fast rotation). If there are multiple fixtures that require separate control, the starting DMX512 address of each fixture can be set so that there is no overlap. If the DMX512 address of the first fixture is 1 and the DMX512 address of the second fixture is 6, then the situation would be thus:
DMX Address Fixture Attribute
1 1 Intensity
2 1 Color
3 1 Gobo
6 2 Intensity
7 2 Color
Modern DMX512 controllers have libraries of data about fixtures telling them how to map attributes to DMX512 channels. The controller could then have separate ways of selecting gobos and gobo rotation, even though on a particular fixture they are controlled by a single DMX512 channel. Although some lights may require different DMX512 values to achieve the same effect, the light operator is presented with a single, consistent control method for all lights. The controller will also work out the correct addresses for the fixtures. If 512 channels will not suffice, then a desk with multiple DMX512 outputs is required. Each output handles a separate 512 channel universe, allowing many more fixtures to be controlled.
The DMX512 output is designed to feed 32 'units' of load. Although a single fixture may represent a fraction of a unit of load, the cabling in between the fixtures can degrade the signal significantly, particularly if it is very long. To deal with this and cable management issues, DMX512 buffers are often used. These have one DMX512 in but many DMX512 outs, all feeding identical data. Each output from the DMX512 buffer can feed 32 units, thereby making it possible to split the signal from a controller to hundreds of fixtures.
It is not recommended to split a DMX512 signal by "Y"ing an output into two inputs. This can cause termination and reflection problems. Any signal arriving at the Y point will be partially reflected and, depending on the final termination resistances, there will be either reflections from the cable ends or an incorrect steady state resistance seen by the controller.
DMX512's popularity is partly due to its robustness. The cable can be abused without any loss of function in ways that would render Ethernet or other high speed data cables useless. Many people do not use the terminating plugs as without them a break in the Data Plus (Pin 3) or Data Minus (Pin 2) cable may not affect the operation of the fixtures. Strange behavior of the fixtures is usually due to incorrect addressing, cable faults, or the wrong data from the controller. Cable faults can occasionally give surreal intermittent problems such as fixtures twitching.
Although the two secondary data link pins were originally intended for sending a second universe of data, many other uses have been implemented and the general practice is now to send additional universes on separate data links. Some manufacturers made units with 3 pin connectors because the original standard did not specifically disallow it. DMX512-A specifies that the connector is to be a 5-pin XLR connector and cannot be any other kind of XLR connector. There is good reason for this rule: a 3-pin XLR can easily be connected to a sound board. If an electronic piece of equipment was accidentally connected to a sound board with phantom power on, the 48 volts of phantom power sent along the cable would probably damage the circuitry inside the light, necessitating the expensive repair or replacement of the light. However, some companies used the extra pins to carry (usually 24 VDC) power anyway, which would again destroy any equipment which used those pins to carry data. For these reasons, DMX512-A forbids using the extra pins to send power or any other use that does not comply with EIA-485 signal levels.
Using these types of devices on older lighting controllers would result in two adjacent channel controls being used to adjust a single movement axis. One would be referred to as the coarse and the other as fine, indicating the relative amount of movement control each channel provided. The coarse channel would allow values in multiples of 256, such as 0, 256, 512, 1024, all the way up to 65280. The fine channel allows the addressing of all in-between values, by adding between 0 and 255 to the value obtained by the coarse channel. Thus the fixture's movement can be controlled more accurately.
Recently, wireless DMX512 adapters have become popular, especially in architectural lighting installations where cable lengths can be prohibitively long. While wireless EIA-485 signals can be effectively received over distances of 3000 feet or more under ideal conditions, most companies limit their maximum run to 1000 or 1500 feet. Wireless DMX512 generally uses WLAN technology to transfer the DMX512 data, with strategically placed converters bridging the signal back to wired links.
The 2004 DMX512-A revision of DMX512 also lays the foundation for the RDM (Remote Device Management) protocol through the definition of Enhanced Functionality. RDM allows for diagnostic feedback from fixtures to the controller by extending the DMX512 standard to encompass bidirectional communication between the lighting controller and lighting fixtures. RDM was approved by ANSI in 2006 and is rapidly gaining popularity.
Another ESTA project, E1.17, is a general Architecture for Control Networks, or ACN. One of the primary goals of ACN was to provide a reliable transport mechanism, which it does through the Session Data Transport (SDT) protocol. Once a session has been initiated in SDT, data blocks of varying types and sizes may be transferred back and forth. ACN also includes a Device Description Language that allows devices to tell controllers how they would like to be described and controlled, thus eliminating the need for fixture libraries.