DMX lights can add a new dimension to your display.

DMX lights can add a new dimension to your display.

If you have any kind of theatrical background you’ve probably heard the techies throw around the ‘DMX’ term. It’s a common protocol to control the lighting fixtures on and around the stage. DMX is a proven technology and can certainly be used in non-theatrical environments, including architectural lighting as well as Christmas displays.

Most of the PlanetChristmas vendors specializing in computerized Christmas displays use a proprietary protocol to control all of their equipment. There’s absolutely nothing wrong with a proprietary protocol other than it tends to lock you into one vendor.

Using the DMX protocol opens up a wide world of vendors and solutions to build just about any kind of over-the-top display you can imagine. There’s no doubt DMX also has some limitations, but they’re well documented and vendors have figured out simple and clever ways around these challenges.

What does PlanetChristmas recommend? If you already feel comfortable in the DMX world, there’s no reason to change. If you prefer to use products more focused on just Christmas type light displays, checkout other options.

Below is a lot of information about DMX including how it works and a list of vendors. This has been assembled form many different sources but most of the credit needs to go to DMX-512-Online and Sunlite.

Let’s get started.  Here’s what we’re going to cover.

  • A Simple Analogy
  • Some DMX History
  • What is DMX?
  • The DMX Connector
  • Universes, Timing and RS-485
  • Basic Operation
  • DMX on PC’s
  • DMX In-line Processors
  • DMX Test Gear
  • RDM – Two Way DMX
  • Vendors

A Simple Analogy using Cable TV

To understand the DMX512 communication protocol (commonly referred to as “DMX”), we will use the simple cable TV analogy.

Imagine a simplistic cable TV system, with only four relevant parts:

  • TV station
  • cable
  • decoder
  • TV set

The TV station broadcasts a signal that travels through a cable network until it reaches a decoder. The decoder receives information on hundreds of channels, but only displays on the TV set the information (in this case video and audio) from that single channel that we select. The TV set ignores the information from any channel that is not selected. It only displays the information from the channel selected in the decoder.

DMX can be related to this cable TV system, where:

  • the TV station is the DMX encoder (the light console or controller)
  • the cable is a DMX cable
  • the cable decoder is the DMX decoder (which usually is inside each lighting fixture)
  • the TV set is the lighting fixture

In DMX, the number of channels that are broadcasted is always 512. Maybe some of them will be empty or unused, but they are still broadcasted because it is a necessary component of the standard.

So, the controller sends out a signal (512 channels of information), which travels through a DMX cable until it reaches the decoder inside the lighting fixture. In the same way you set the channel you want to watch on your TV, in a lighting fixture you set the channel that you want your fixture to display the information for. This is known as the DMX address.

In other words, if I set my lighting fixture to channel 21, then my fixture’s DMX address is 21. Both expressions are common in the lighting world.

Example: Imagine we have a DMX dimmer that controls a simple light bulb. This dimmer is set to DMX address 21, so the lighting fixture will only receive the information from channel 21 and ignore the rest.

We have a controller that sends a signal through a DMX cable and this cable goes into a decoder (the DMX dimmer) that receives the signal. So if the controller sends the “turn on” information on channel 21, the dimmer will turn on the light bulb.

Conventional lighting fixtures (simple dimmers) require one channel of information only. However, intelligent lighting fixtures require more than one channel to work. For example, if I have a lighting fixture that requires five channels of information, and its DMX address is 21 (again, address is the first channel used by the fixture), then this fixture will use channels 21, 22, 23, 24, 25. The decoder knows that the fixture needs five channels of information, so it will decode vive channels only and ignore the rest. The controller knows the fixture uses five channels also, so it will send five channels of information.

Example: Imagine you have a very simple robotic moving head that uses five channels:

  1. pan
  2. tilt
  3. color wheel
  4. gobo wheel
  5. dimmer

You set your moving head to address 21 and you tell the controller that you have this particular moving head on address 21. The controller then knows that channel 23 corresponds to color wheel, for example. If you want to change the color of the light beam, you tell the controller what color you want, the controller automatically sends this information through channel 23, and the lighting fixture reacts accordingly.

Typically, intelligent lighting fixtures use one channel (sometimes more) for every function they can perform (color, gobo, prism, dimmer, etc). Some robotic moving heads use over 20 channels, some simple scanners only four channels, etc.

Some DMX History

DMX512-A is an RS-485 based communications protocol that is most commonly used to control stage lighting and effects.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 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.

What is DMX512?

In the good old days of stage lighting control, we had large manually operated autovariacs to control the lanterns that lit up a show. These were placed next to the stage and some amounts of power cable snaked their way around the stage area to deliver actual electricity to the lamps. Not that the amount of cable was much but on the whole quite cumbersome; you can imagine … one needed an octopus’s constitution to operate these things and forget about setting scenes !!

Until some smart guy fitted the autovariacs with motors… and hey presto, you now had a smart panel back of house and the variacs were down in the basement, motor and all! Only some low gauge control wiring to operate the motors went back to the console. The only hassle was speed… or slope, if that’s what you would say now! Motors had finite speeds and that was that!

Then came the first electronic dimmers and the first consoles. Necessity is the mother of inventions and the presets (or duplicate sets of faders for each channels) arrived.

Control was done using a small DC voltage, the proportion of which turned on the lamp to different levels of dimming. This voltage ran along individual wires for individual channels and this ‘analog’ system is still used all over the world. Different voltages and polarities are used but the +10 volt system is the most popular. This system suffers from two major problems:

  • It is prone to noise and earth loops if not wired properly over long distances.
  • It can be very non linear with the different kinds of lamps in use today.

Solutions to overcome these and other problems were attempted but were not remarkable.

Then came the basic computerized consoles using simple scene storage facilities. Outputs were still analog and improvements were done to send multiple signals over the same set of wires. Computers opened up a new dimension to the whole system… a fader need not be dedicated to a particular dimmer; it could be assigned to any dimmer or set of dimmers. With the faders and buttons on one side and the dimmers on the other side, the computer could be made to compute any connection, level or slope that was required between them. The processors available at that time were slow so a lot of constraints were still there.

Different manufacturers came up with different consoles with improvisations of all kinds. They were quick to realize that a digital communication system between consoles and dimmers was a natural extension of the computer’s power since it was spitting out digital numbers anyway. Various protocols were adapted with the result that there was little or no horizontal translation between manufacturers. It also meant that you had to buy all the gear from the same guy! The end user was the victim and a standard interface was very desirable under the circumstances.

The U.S.Institute of Theatre Technology (hence referred to as USITT) first developed the DMX512 protocol in 1986 as a standard interface between dimmers and consoles. It was a simple concept and was easily adoptable by all concerned. Since the first standard, some improvements was made in 1990 to accommodate some problems and it is now known as the USITT DMX512 (1990) standard. Another round of discussions are on for further modifications and then it would become USITT DMX512-A. It started out as a means to control dimmers from consoles and has ended up being used to control intelligent lights, color changers, yokes, strobes, smoke machines, lasers and even confetti dispensers.

The DMX Connector (3 or 5 Pins)

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, in 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.

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 outs, 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.

Universes, Timing and RS-485

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 are 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 is transmitted serially at 250 kbit/s and is grouped into packets of up to 513 bytes, called ‘slots’ in DMX512-A. Data is 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, extended from 44 uS in the 1986 standard, and when receivers detect the break they reset 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.

Basic Operation

The DMX protocol consists of a stream of data which is sent over a balanced cable system connected between the data transmitter (usually consoles) and a data receiver (could be dimmers or any of the stuff mentioned above).

A single DMX port, outputting this stream, can pass magnitude value information for a maximum 512 channels (or less) only. This port is known as a DMX universe. For consoles catering to more than 512 channels a second universe (and therefore a second port) is required. The following is the universe/channel table:

 UNIVERSES       CHANNELS
     1            1- 512
     2	        513-1024
     3	       1025-1536		
     4	       1537-2048
     5         2049-2560
     6         2561-3072

and so on.

There is no restrictions on the number of universes.

An AVOLITE DIAMOND II console, for instance, has six DMX512 universes and, hence, six DMX512 ports on it’s rear panel. It can feed 512 x 6 = 3072 dimmers!

I suppose processing speeds would be the only restricting factor in accommodating more DMX512 universes. We will consider the operation of the first universe only on this page. The basic operation is the same for all universes except for the physical channel numbers at the console end. It is important to know that receiving devices will have circuitry to recognize only channels 1 to 512. In multi universe systems, the light designers and riggers have to physically identify universe/channel combinations when wiring up receiving devices. For example, a dimmer which needs to be connected to the output channel 2331 of the AVO DIAMOND II, would be connected from the 5th universe output but would have an address of 283 set on it. That’s because Output channel 2331 is actually channel 283 in the 5th universe.

The data stream is sent as a packet (hence forth referred to as the DMX packet) of data which is repeated continuously. It consists of starting bits of data which informs the receivers that the packet is being refreshed and then sends out a stream of serial data corresponding to the magnitude value of each channel, starting with channel 1 and ending with 512 or a lesser channel number (depending on the design and size of the console). Each channel is separated from the other by specified bits of start and stop data.

 

&h01… &h02… &h03… &h04… &h05…
 

&h06… &h07… &h08… &h09… &h0A…
 

The whole system works like a city postal system. Each postman (universe) has a route including 512 houses (channels). Each house (channel) has a unique address. Some houses are big buildings with many individual apartments (several channels in one unit like an intelligent light). The postman goes from house to house and delivers the mail (the value data) in individual letter boxes. Each occupant opens only their letterbox and takes their mail. Similarly each receiving unit is told its address (one of 512 addresses) and thus ignores all other data except the one it’s supposed to receive against its address. Some units like intelligent lights have one address as a start and go on to receive data for that address AND several more addresses following it. Not unlike the lobby security receptionist who takes in the mail for every one in that building and then distributes it.

The data stream has a specific format and has specific physical properties by which it is propagated.

Before we go on to explain the structure of the DMX packet, I am assuming that the visitor has some knowledge of the bits & bytes that make up any computer’s fundamental language system.

The DMX bits are also represented by a digital high (HI) or a digital low (LO). The actual DMX output transmits these HI and LO signals in an electrical form.

The DMX data stream clocks out at the rate of 250Khz which means each bit is measured at 4 micro-seconds widths.

1) IDLE or NO DMX situation:

In the absence of a valid DMX packet the output of a DMX line will be a continuously HI signal.

2) BREAK

The start of a DMX packet is heralded by the output going LO for a MINIMUM period of 88 microseconds. This means 22 LO bits are measured out one after the other. This is known as the BREAK. The BREAK could be longer but not less than 88 microseconds. Experience shows that slightly longer breaks (above 88 microseconds) sent from a console are better since the receiving devices are generally given the algorithm = “Is the BREAK>88 microseconds or 22 pulses”. I keep it generally at 100 -120 microseconds in equipment designed by me

3) MARK AFTER BREAK (MAB)

The MAB immediately follows the BREAK by making the output go HI for a MINIMUM period of eight microseconds or two pulses. This MAB is a bit of a problem since the difference between the original DMX512 and the current DMX512(1990) standards relate to this period of the packet. The original was set at four microseconds or one pulse. This created hassles for some receivers for being too short a MAB for detection and was upgraded to eight microseconds or two pulses in 1990. The problem comes when a older console is used with newer receivers or vice versa. Wrong detection will lead to packet rejection or the wrong data going to the wrong channel. This will travel down the line leading to confusion. Some receivers have a DIP switch to set this parameter for both timings. Again the maximum MAB length could be one second. My ideal timing would be 12 microseconds.

4) START CODE (SC)

The SC is next in the line. It is easier to remember that the SC is the start of the actual data stream where all individual channel data have the same format. The BREAK and the MAB were of different timings but the SC onwards all frames will have the same structure and timing of 11 pulses or 44 microseconds width. The first one can be termed as data for channel number zero which is a non-existent channel and represents the SC.

I will first describe the general structure of these channel data frames:

  • Of the 11 pulses the first one is always LO signifying the Start bit.
  • This is followed by the actual data byte of eight bits (which could be any of 256 values from 0 to 255).
  • The frame ends with two bits which are HI signifying the two stop bits and end of the channel information.

Channel number ‘0’ is the SC, which as things stand, ALWAYS has the databyte = 0 signifying that the following data is for dimmers. As per the current standard, no other value can be used. The option is left open and as and when ESTA specifies, the SC value may be used to tell the receiver that the data following it is meant for a specific type of receiver. That is the end purpose of having the SC… to be able to segregate a packet of data, receiver-wise. But, for the moment, it’s zero which has been specified for dimmers by ESTA. Do remember that this also includes just about any receiving device like dimmers, moving lights or whatever !

5) MARK TIME BETWEEN FRAMES (MTBF)

The mark time between frames can be from a little more than zero seconds to up to one second, but the lesser the better. Each channel frame can have the MTBF before the start bit. The MTBF is obviously HI .

6) CHANNEL DATA (CD)

The CD frames follows the SC frame in a logical manner from one to 512 (or less) in the form described above.

7) MARK TIME BETWEEN PACKETS (MTBP)

After the last valid CD stopbits are sent, one full packet is completed and the next packet can start with a fresh BREAK & MAB. However an idle (HI) can be inserted between packets (MTBP), the length of which may be a little more than zero sec to up to one second. It is up to the console designer to design the architecture of the console and the software powering it in such a manner that the data throughput time is at a minimum.

IMPORTANT

The happy part of DMX is that you DONT send the CHANNEL NUMBER AT ALL!!
The first byte AFTER the STARTCODE(SC) is AUTOMATICALLY taken as the datavalue for Channel 1…next, datavalue for Channel 2….next, datavalue for Channel 3…and so on…up to 512 OR less channels. That is how the receivers… be they intelligent lights or whatever… will decode them. Actually a channel counter is set up in the receiver… either in the software itself or as a hardware counter. This counter will be automatically reset to point at channel 0 when a valid BREAK and a valid MAB is detected. Subsequently with every LAST stop bit in each frame, this counter is incremented by ONE. Thus, DURING the SC frame, the counter output reads zero. At the end of the SC (last stop bit of the SC frame) the counter output becomes one, thus telling the processor that the next frame contains the data for channel 1 and so on. So the receiver knows which channel the current data is valid for… Thus when you set a start address in an MARTIN 812 at say 50 (+6 channels) it simply takes the 6 databytes from when the internal channel counter reaches 50….counting up to 55! The moment you start a fresh BREAK …etc sequence (a new packet, that is) this counter is reset! So it is fully legal for a console or software to generate upto valid 100 databytes after the SC for 100 channels and then generate a BREAK, etc. Thus you don’t HAVE TO generate all 512 bytes! The LSC ATOM, for instance, has the capacity to drive 99 channels; thus at the end of the 100th frame or a count of 99(remember, we have an SC frame to count, too, at the count of zero) the console starts sending a BREAK + MAB and so on. This concept is vital in order to understand the one to one relation between channel numbers and their respective data.

Like this: (This animation may take some time to load, but is worth waiting for)

Packet Demo..... PLEASE BE PATIENT !!!

What you see above, happens at a speed which is so fast that the scrollers actually retain the color. Receivers also store the last channel data they receive in the last packet refreshing it with the packets as they come.

The scrollers going to white at the start of the MAB in the above animation, is ONLY for demonstrating the packet action with every new packet and does not actually happen in practice due to the storage refresh.

The following is a mathematical layout of the typical DMX512(1990) timing:

[(88)+(12)+(44)+(CHL*44)+(CHL*MTBF)+(MTBP)] microseconds

Where CHL is the no of Channels under consideration.

The ideal timing (this is purely my personal opinion)

[(120)+(12)+(44)+(CHL*44)+(0)+(50)] microseconds

For 512 channels my timing would be 22754 microseconds.

Thus the refresh rate = 1000000 / 22754 = 43.9 or 44 Hz

How the refresh rate varies would depend upon the Microprocessor speed, firmware code and system architecture.

DMX Timing Chart/1990

The original intention of using DMX512 for controlling dimmers only, has now been stretched to include a whole range of equipment. The 8-bit data structure, which was originally used to specify 256 levels of dimming only, is now also used to define many different parameters in different equipment:

  • mirror position
  • gobo position
  • gelstring position
  • shutter position
  • focus motor position
  • smoke machine pump pressure
  • and many more.

Similarly, equipment for generating DMX512 has also taken different forms, although the original basic console is still very much there :

  • Special console functions to facilitate use of moving lights
  • Personal computers (IBM or MAC)
  • Stand-alone equipment for Architectural lighting
  • Back-up equipment for consoles
  • Test instruments
  • etc

Some equipment both receive & generate DMX512:

  • DMX protocol convertors
  • DMX multiplexors and de-multiplexors
  • DMX splitters
  • etc

Consoles:

The console converts data collected by it from the various tactile controls on it into a 8 bit form using Analog to Digital converters or other devices and then computes the required output data. This computation may be simple or complex depending upon the desk functions and it’s patching scheme. The final CHANNEL values are inserted into a DMX512 engine after the processor correlates with the patch table inside it. The DMX512 engine outputs the values after sorting them into respective DMX512 Universes.

Dimmers:

Dimmers receive DMX512 data and use it to control the width of a pulse which then triggers a power control device such as a triac or a set of thyristers. The pulse is synchronized to the AC mains in a manner that allows the power device to control the phase of a electrical current passing through it, thus varying the power supplied to any light(s) that may be connected to it in series. However, the actual light output-to-phase angle ratio is not the same for all lamps in practice and, therefore, the DMX data-to-phase angle ratio is often compensated over the entire 256 step (8 bit digital) range. These compensating curves are called dimmer curves and are often user selectable in the dimmer or from the console.

Moving Lights:

Moving lights, scrollers. yokes etc work on more or less the same principal and are being discussed together. The central idea in all of them is to use DMX512 data to determine the relative angle of a motor shaft. This is achieved in a number of ways…t he most common is to use a stepper motor (similar to the guy who turns your computer printer roller to feed the paper or makes the printhead go left to right & back, while printing.) The stepper motor is an electric motor which turns it’s shaft a certain little bit when you put a momentary pulse of electricity in a certain set of wires and in a certain order. Reversing the order of pulsing makes the shaft turn in the opposite direction. There may be several such motors turning the mirror, gobos, lenses, lamp shutters etc in a moving light. Each needs it’s own channel of DMX data and thus separate channels are used. The data is received from one channel address onwards till the number of channels required and then separated and passed on as the required number of pulses in the required order to the motor concerned. The scroller has two such motors with a reel shaft on each across which the gelstring is strung. Based on the DMX512 data received, they reel the gelstring in or out, changing the color coming in front of the lamp. Similarly, other equipment use different mechanisms using these motors to achieve the necessary end.

Other than stepper motors, servo motors are also used where a closed loop feedback on the shaft position is obtained.

In addition, a channel may be used for a traditional dimmer inside the Moving Light to vary the intensity of it’s lamp. However, this dimming is also done mechanically, using one or two stepper motors driving a pair of shutters across the light path.

Other:

DMX512 is also used to control smoke machines. One or more channels are used. The basic channel is used to trigger the smoke machine to blast away by allotting a 8 bit value OVER which the pump inside activates. One more channel may be used to regulate pump pressure when it’s turned on by the base channel thus controlling smoke quantity.

By using DMX512 to activate relays, you can make it control confetti dispensers, snow machines and strobes.

WARNING:

The following equipment are SOME of many which are prohibited from using DMX512 as a trigger source as specified by the standard:

  • Pyro stuff
  • Set shifting stuff
  • Truss motion control
  • In fact, any thing which compromises the safety of human (or animal !) lives due to failure to receive and interpret DMX512 correctly, is prohibited.

DMX512 on PCs

When billions of dollars have been spent on technology research to get the desktop PC to the common man, why waste money & time re-inventing the wheel ?

The power of the PC can be used to generate spectacular end results as far as DMX512 is concerned. What you need is an outboard USB or Parallel Port or add-on card to generate the DMX512 signal and software to power it up. The 250khz DMX clock can be obtained from the PC’s clock line. The main computation can be controlled by the PC and the DMX portion can be handled by a separate dedicated microprocessor which continually outputs DMX and gets a refreshed DMX page from the main CPU at intervals. With a DMX512 Input facility, a dedicated tactile interface or a full fledged console can replace runtime operation with the otherwise cumbersome PC keyboard / Mouse.

DMX512 In-line Processors

DMX PROTOCOL CONVERTORS are used to convert other protocols (AVAB, PMX, D54, MICROPLEX, etc) to or from DMX512.

DMX ANALOG MUTIPLEXERS convert DMX512 data to and from analog systems.

This may be multiple analog (+10v / -10v /
+5v) or multiplexed analog (e.g. D54) signals.

DMX SPLITTERS generally provide multiple DMX outputs from one input and can drive a large number of units. Some splitters provide the same input data on all out puts OR divert the input data in a split fashion to two or more outputs. e.g. channels 1 to 256 may be on the first output and 257 to 512 on the second one. Thus channel 257 becomes channel 1 on the second output.

DMX MERGE units take two or more DMX512 inputs and merge them into one DMX output stream placing one input stream AFTER the other. e.g. If two DMX inputs ( say A & B) are merged then the output (C) will first send A then follow it with B using only one BREAK / MAB / SC sequence in the beginning. Thus if A+B = C then C(1 – 256)= A(1 – 256) and C(257 – 512)= B(1 – 256)

DMX MIX units take two or more DMX512 inputs and mix them together channel to channel and produce one DMX512 output. The mixing is usually done in the HTP (Highest Takes Precedence) mode. Which means whichever of the two inputs are highest (in terms of value) is passed on to the output.

Thus C(n)= A(n) OR B(n) ,whichever is higher.

Note: If A has 512 channels and B has 200 channels then C will have 512 channels of which the first 200 will be mixed. Channels 201 to 512 of A will pass on to C , unaffected.

DMX Test Gear

This generally take the form of small hand held boxes with DMX IN and DMX OUT connectors. They can address any of the 512 channels separately or collectively with selectable data and are fitted with suitable LED or LCD screens to display details. They can also receive data from any selected channel and display the same. They may have other advanced features like measurement of BREAK , MAB , SC timing or PACKET refresh rates and built in diagnostic warning signals in case these parameters deviate from normal range. They also have trigger outputs ( + or – ) for oscilloscopes which is useful in order to view the correct required frame while servicing DMX512 equipment. It’s the first thing you should get if you are going to use DMX512 stuff.

RDM – Two Way DMX

If you haven’t fallen asleep yet understanding DMX, there’s new stuff coming. DMX is a one way protocol, meaning a controller sends out a signal and the DMX fixtures wait patiently for something addressed to them so they can react. Wouldn’t it be great if the DMX fixture had a way to send information back to the controller? Get ready for RDM.

Remote Device Management or RDM is a protocol enhancement to USITT DMX512 that will allow bi-directional communication between a lighting or system controller and attached RDM compliant devices over a standard DMX line. This protocol will allow configuration, status monitoring, and management of these devices in such a way that does not disturb the normal operation of standard DMX devices that do not recognize the RDM protocol.

Since the RDM protocol travels on top of the DMX512 protocol most of its uses will be in the field of stage lighting. This protocol will change the way that lighting technicians setup and maintain their lighting rigs. It can provide:

  • Identification and classification of connected devices (Fixtures, Dimmers, Splitters, etc…)
  • Addressing of devices controllable by DMX512
  • Status reporting of fixtures or other connected devices
  • Configuration of fixtures and other DMX devices

RDM is pretty new stuff. The Enttec website is a great place for more information.

Vendors of DMX Stuff

DMX512 Console Vendors


DMX512 Moving Light Vendors

 


DMX512 Dimmers

 


DMX Effect Lights, Scrollers, Strobes, Follow Spots, Yokes, Projectors, etc


DMX Modules


DMX Fog Machines


DMX PC/MAC Based (including USB/Parallel interfaces)


DMX Automated Show Control


DMX512 Motion Control


DMX Chips


DMX Video


DMX Lasers and Fiber Optics


DMX Test Gear


Wireless DMX

 


DMX Cables and Hardware


DMX Circuits


DMX Codes for Intelligent Lights

These links are useful for everybody who is suddenly confronted by stuff he or she hasn’t used before or doesn’t have a library entry.

They are actually parts of the ESTA and INTERACTIVE websites and all thanks to them!


DMX Sales and Service


DMX Used Stuff

 

 

Related posts