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 not only linking controllers and dimmers, but also linking more advanced fixtures and special effects devices such as fog/smoke 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.
A DMX512 controller is connected to fixtures or devices in a multi-drop bus topology commonly called a “Daisy Chain”. Each device has a
'DMX512 in' and generally a
'DMX512 out' connector - sometimes marked as
'DMX512 thru'. The
'DMX512 out' on the controller is linked via a DMX512 cable to the
'DMX512 in' on the first fixture. A second cable then links the
'DMX512 out' on the first fixture to the next device, and so on. In general, the final, empty,
'DMX512 out' connector should have a DMX512 terminating plug attached into it, which is simply a resistor that matches the impedance of the cabling used (usually 120 ohms) joining pins 2 and 3 of the connector. Many modern devices negate this requirement as they are capable of auto-terminating the link.
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 it has even been known for light fixtures to be produced with a TRS connector jack for DMX connectivity, this is a violation of the Standard, although 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 adaptor must be supplied.
Cabling for DMX512 was removed from the Standard and made a separate standards project 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 vs. 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. 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 reversed compared to 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 adaptor, many lighting desks are also equipped with a polarity selector so that if an entire universe of fixtures are of the reverse polarity type no adaptor 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.
Upon completing the Symphony of Lights installation in Hong Kong, The World's Largest Permanent Laser / Light Installation (Guinness World Records), Ben Webb, an Engineer from the Design Company Laservision, coined the term “DMX Galaxy” to describe a group of 10 “DMX Universes”. This came in handy as the current installation now uses over 100 “Universes” or 10 “Galaxies”.
DMX512 data is sent using RS-485 voltage levels and cabling practices. The DMX specification refers the reader to RS-485 for information about the electrical signal. Data are transmitted serially at 250 kbit/s and is grouped into packets of up to 513 bytes, called 'slots' in DMX512-A. Data are sent with 1 start bit and 2 stop bits, LSB first. The start of a packet is signified by a break of at least 88 uS followed by a “Mark After Break” (MAB), of at least 8uS (The 1986 version of the standard required a 4 uS MAB, this was extended to 8 uS in 1990). When receivers detect the break they restart their receiving code. Then up to 513 bytes are sent. The first byte is always the “Start code” byte. This tells receivers which kinds of data are being sent. For normal dimmer/level data, 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 bytes make up the actual level data. Up to 512 bytes can be sent, and it is the job of the receiver to count the bytes 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 bytes, 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 though, as 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 it continues up from there to the highest numbered Dimmer, e.g. 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 1 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 behaviour. 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 Colour 3 1 Gobo ... 6 2 Intensity 7 2 Colour
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. The operator is presented with a single consistent control method for controlling lights which require very different DMX512 values to achieve the same effect. 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. A single fixture may represent a fraction of a unit of load, however 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 out's, all feeding identical data. Each output from the DMX512 buffer can feed 32 units, so by using DMX512 buffers it is 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 either there will be reflections from the cable ends or the steady state resistance seen by the controller will be incorrect.
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 behaviour of the fixtures is usually due to incorrect addressing, cable faults, or the wrong data from the controller. Cable faults can occasionally give very surreal intermittent problems such as fixtures twitching.
The two Secondary Data Link pins on the five-pin connectors were originally intended for sending a second Universe of data, however 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. 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. DMX512-A forbids using the extra pins to send power, or any other use that does not comply with RS-485 signal levels, for these reasons.
If a single DMX512 channel is used to control pan on a Martin Mac 500 Pulsar, which has 440° of pan, then an increase of 1 would result in a movement of 1.7°. (This is found by dividing 440 by 256) Over a long throw (distance between the fixture and the projection surface) this amount of movement can result in a significant movement of the beam. To control position more accurately, MACs and other fixtures use 2 channels each for pan and tilt. This gives a 16-bit value between 0 and 65535 for each movement axis.
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 wired RS-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.
Many alternatives to DMX512 have been proposed and implemented to address limitations such as the maximum slot count of 512 per Universe, the unidirectional signal, and the lack of inherent error detection. One configuration that has gained popularity is the use of CAT5 to distribute multiple DMX universes through a single cable from a control location to breakout boxes closer to fixtures. These boxes then output the traditional DMX512 signal. Protocols used over the CAT5 are generally proprietary, specific to individual manufacturers, although ESTA has initiated a project numbered E1.31 to define an interoperable CAT5 transport for DMX512.
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.