DMX Questions from a newbie

JonCarter

Well-Known Member
A DMX newbie here with a question for all the DMX gurus on ControlBooth: Why do some instruments use more than one DMX "address"? If the DMX "address" is the actual address assigned to an instrument, I would assume that the instrument would wait for its address to come down the line and then accept all the instructions sent to that address and do whatever it was told. (Change intensity, change color, turn left, pan down, and whatever else was sent, assuming of course that the instrument could do these things.) Is a DMX "address" really the address of a piece of hardware, or is it the sequence number of a "time slot" in a sequence of 512 time slots after a start bit, each containing ONE instruction, and the instrument waits the time from the start bit until its "address" (time slot) is reached, then executes the one command at that address?

And another question: Let's say we have a dimmer has DMX address "001." The last cue left our dimmer at a level of 6. (Or 6/10, or 60%, or 60, or whatever we're going to call it.) The next cue is to move this dimmer to 9.5 over a 30 count. (That's about 30 seconsds.) Does the control board send a command to the dimmer to "move UP 35 points over 30 seconds" or does the control board send incremental commands to the dimmer for the next 30 seconds, each one telling it to move the necessary fractional increment (depending on the frequency of the control signal) so that the result is a 35 point increase over the 30 seconds the designer has called for? In other words, is the "thinking" done in the control board or in the dimmer?

And a last question (for now): How about he names of some good books on the subject? Thanks!
 
It is probably more correct to say 'parameters', most of the time when 'address' is used, people are referring to start address, that is the 1st parameter that the light looks at. Dmx is sent out in batches at a defined frame rate (usually around 30-40 frames per second) each 'frame' includes a value for each of the 512 parameters, 0-255. Additionally each frame has a start (header) and end to indicate the break between frames. So for a mover, it would look at its start address, and channel mode, to see what parameters correspond to what functions.

For dimming, yes the board really does send hundreds of incremental changes on a fade or movement. Since there are only so many whole numbers between intensities (max of 255 steps), changes on long fades can be noticeable on intelligent (movers/LED) lights (since they lack to thermal inertia of a filament.) This is why intelligent lights will often have a '16 bit' mode where 2 parameters are used to adjust one control function (we'll say tilt). The 2nd channel (tilt fine) will go through all 255 steps for every one step of the primary channel (tilt), giving a total of 65,025(!) for tilt control.

As for reading, there are a few threads/articles around with lighting book recommendations, however Fleenor will probably go in more depth then most books: http://www.dfd.com/info.html

I hope I mostly answered your questions, but I'm sure someone else will more eloquently explain how things work using more diminutive words ;)
 
Think of it as an apartment complex. The whole unit is at address 102, but if you want mail to get to different units (each of which do different things) you have to address them differently.

So colors, effects etc take up a number. The whole building is the first number, but depending on whether you're in 1,3,5,12, (however many channel mode) various effects or parameters need the apartment number to know what they should be doing.
 
Think of it as an apartment complex. The whole unit is at address 102, but if you want mail to get to different units (each of which do different things) you have to address them differently.

So colors, effects etc take up a number. The whole building is the first number, but depending on whether you're in 1,3,5,12, (however many channel mode) various effects or parameters need the apartment number to know what they should be doing.
I think this is a misleading way of looking at it. It suggests that all parameters have some sort of subdivision of information outside of the normal DMX stream. The DMX Address is a "start address", and depending on the fixture will then continue to consume a varied number of addresses within the stream of 0-512.

The reason for this is history: DMX was designed to control single parameter dimmers, conveying a value of "off" to "on" over 255 steps. Moving Lights, LEDs, and similar more complicated devices have grafted themselves onto this standard by thinking of each control parameter as a separate "dimmer value" mapping pan, tilt, color, effects to a 0-255 value, and eating sequential addresses for each parameter.

In addition, various parameters benefit greatly from higher resolution data. A moving light with 540 degrees of pan, for example, suffers greatly when you can only give it 255 distinct locations from the console--that's a resolution of 2.1degrees which is huge over a long distance. To compensate for this, many parameters have started taking up two sequential addresses in a "16 bit" configuration, achieving 255 steps of resolution in the "fine" address for each step of resolution in the "coarse" address--A total of 65536 values, or a theoreitcal resolution of .008 degrees on a 540 degree pan.
 
DMX guru here...

Think of it as a repeating series of values - 512 values to be specific and each value is 0-255.


The "DMX start address" merely tells the fixture where in this series it should look to find values that are relevant to it. If the address is 5, then your values start at the fifth data byte.


What do those values mean? Only the console and fixture know that. Looking at the DMX-512 packet, you'd never be able to tell what the actual values mean without knowledge about the fixtures you have and what their start address is. It's not like other protocols where destination specific messages can be sent with variable sizes, commands, etc. - DMX-512 is very simple and very dumb. It's a protocol that can be specified in detail on one page (or less).
 
On top of what everybody else has said, think of DMX channels as light switches (or dimmers, if you fancy).

Each light switch can only control one set of lights; it may turn on multiple lights, but all the lights on that switch work together, and they cannot be separated. You can also have multiple switches control the same lights. If you want to control lights independently, you'll need a switch for each light (or group of lights) you wish to control separately. This is just like how multiparameter DMX fixtures such as RGB and moving heads need a channel for each attribute that can be changed.

As for the "how" part of DMX, think of your DMX signal as a radio station.

When you listen to that radio station, the station doesn't know that you're listening; it's all one way. Adding to that, many other people could be listening, and you won't impact how they receive the station. This is just like how DMX is what I like to call a "broadcast" signal; it'll send out ALL the information, because it doesn't care what is listening, just that something down the line cares about it, just like how a radio station broadcasts music to reach a certain audience (IE rock vs pop vs country).

Now, let us say the only song you really like is Song 2, but you'll still listen to other things, just so that you can hear Song 2 play again later. You listen to this one radio station 24/7, and for some reason the station broadcasts the same exact sound bytes no matter what (say it goes Jingle, Ad 1, Song 1, Ad 2, Song 2, Ad 3, Song 3, so on so forth to Song 512), but the music is a different volume every time (this would be analog, but we'll just use that as a sensible "level" tool). You listen to the station, and you hear their jingle play; you now expect Song 2 to play exactly 3 minutes after the jingle (say the ads are 30 seconds each, and each song is 2 minutes long), so you start your stopwatch. The very moment it hits three minutes, you start paying close attention to the volume the station is playing Song 2 at. Being an odd man, you don't dance during your favorite song, Song 2, but only after it; this is because Song 2's volume tells you how hard you're going to dance. So you continue dancing at the same level until Song 2 plays again, and you adjust how hard you're dancing once the song finishes, based on its volume.
This is how devices interpret DMX. Think of the songs as each channel, and the volume as the channel level (I had mentioned the thing about volume being analog because DMX is digital, so a more accurate representation would be certain parts of the song playing, but still at the right times with constant volume, so basically some segments would just be muted). This is why you can't give a fixture a "To-Do list" via DMX, you basically tell it what to do step by step, basically "Everything on channel 1: Go to 250, Everything on channel 2: Go to 100" all the way through channel 512, and then after telling everybody where they should be, you start announcing where each channel should be, starting back at 1, and going up to 512 again. One of the main functions of a console is to convert the human friendly "fade from full to zero in 3 seconds" to steadily decreasing the relevant DMX channels from full (255) to zero (0) over the course of 3 seconds.
As for talking to just one device and telling it what to do, I'm not too certain about ArtNet, but if I'm not mistaken, that will send data to a specific IP address instead of blasting it to any and every device that can hear it (more like a phone call- other people can't listen in on the signal).

This free PDF from Elation is decent, and also makes a very similar analogy to mine, but with cable TV instead of radio: http://cdb.s3.amazonaws.com/ItemRelatedFiles/10191/dmx-101-handbook.pdf

(I just had to use Song 2 as an example, woo hoo to you if you get the reference)
 
I always liked the coal train analogy. Locomotive (start byte, tells you when it’s a new packet) pulling 512 coal cars (addresses). Each car is half full, full, 1/4 etc... represents whatever the listening device can “do”; I.E. dim, move a motor, etc...

A 96 dimmer rack listens to cars 1-96, a mover listens to 97+98 for pan, 99+100 for tilt, 101 for mechanical dimmer, 102 for the dedicated color wheel, etc.... using 24 or so cars/addresses per fixture.

One train on one track (DMX cable) for one universe, 44 trains per second. Need more information sent, piggyback the train onto a TCP/IP protocol on a network and send 32 or 64 trains (sorry, universes) on one track (pair of Cat 5 wires).
 
Many thanks to all who responded, and for your suggestions of resources which I shall review. Now, another question: Does anyone know the reason that this particular protocol (non-error checking, unable to send more than one command to a specific hardware address rather than a specific time slot in the sequence) was chosen for theatrical use?
 
One of the big reasons is cost. It costs a lot more to add error correction (requires implementation on both ends, not to mention two way communication).

Other reasons include that it was adopted a couple decades ago, alternatives aren't widespread enough to consider as full-scale solutions, it's super easy to connect lots of devices (compared to the likes of Ethernet) and nobody wants to deal with protocol conversion just to use certain devices.

Luckily, DMX seems to be difficult to mess up with normal RF environments when it's set up properly. The only time I've seen issues related directly to the DMX protocol is with my DIY USB to DMX interface having a hard time keeping time, but dropping the transmitted channels to 256 and bumping my control software priority to High seems to fix it.
 
Many thanks to all who responded, and for your suggestions of resources which I shall review. Now, another question: Does anyone know the reason that this particular protocol (non-error checking, unable to send more than one command to a specific hardware address rather than a specific time slot in the sequence) was chosen for theatrical use?

Ahh. Time for some history ( all of this is my recollections and may be incorrect. I hope more knowledgeable folks will chime in )

When SCR dimmers came into general use, they were controlled by a low voltage signal from the console. Frequently 0-10 volts. ( I have a vague recollection that Kliegl was 0-20 but it’s vague). This was accomplished by running bundles of wires from the console to the dimmers. As dimmer counts became larger and larger, the cost, time, expense of all those wires started to add up.

Several manufacturers created their own multiplexing protocol which sent dimmer levels over twisted pair wire. Each manufacturer had a slightly different flavor so interoperability was more than a little difficult. In 1986 ( I believe ) a meeting was held at USITT to try and come up with a better way. To many folks astonishment, Kliegl did not push for their protocol, but instead promoted a variant of the colortran protocol and thus, in an afternoon, DMX came to be.

One reason for the approach, there was a chip in existence that did most of the decoding work for the dimmer manufacturers.

As to error correction or even a check sum. If one packet was corrupt, the next packet came along quickly enough that you could not see the output in the light connected to the dimmer.

Turns out that the protocall is pretty error free and forgiving of noise, etc so error checking is not that big a deal when controlling dimmers or lights ( not so for other applications like pyrotechnics )

Remember all of this was developed before protocall like UDP and TCP were in wide usage. It it was a LOT cheaper and easier to set up than they were at the time.


When moving lights, etc came along they adopted the DMX protocall. There was a years long effort to develop something called ACN ( advanced control network) which would be more of a UDP type protocall and soul support commands like “pan to 34.5 degrees in I seconds) but there was not a strong business driver and the project stalled ( after creating the specification for streaming ACN. A way tomsend DMX data over an Ethernet network)
 
Last edited:
Many thanks to all who responded, and for your suggestions of resources which I shall review. Now, another question: Does anyone know the reason that this particular protocol (non-error checking, unable to send more than one command to a specific hardware address rather than a specific time slot in the sequence) was chosen for theatrical use?

The big 3 lighting companies at the time, Kliegl, Strand-Century and Colortran had all designed and built memory desks as well as analog multi-scene manual desks. They all created their own digital protocols proprietary to their own desks to talk to their own dimmers. It was obvious that it was impractical to keep using the analog 0-10 VDC for increasingly larger and larger systems, thus digital.

The rental shops needed the flexibility to use anybody’s dimmers with anybody’s console, thus made a push for a standard. The Colortran CMX D192 protocol was the most advanced and easiest to implement. The WiKi is a good article to read

Recall as well that the manufactures had the option to implement talkback from device to console, using the spare pair of wires in the 5 pin XLR, just nobody bothered. Mostly as some manufactures would do this via a separate system (ETC Link). The only hardware was a dimmer and if it wasn’t able to talk back, no error check was required.

https://en.m.wikipedia.org/wiki/DMX512
 
Many thanks to all who responded, and for your suggestions of resources which I shall review. Now, another question: Does anyone know the reason that this particular protocol (non-error checking, unable to send more than one command to a specific hardware address rather than a specific time slot in the sequence) was chosen for theatrical use?
1. In 44 ms. you'll get another packet, so if you have a glitch, it won't matter much.
2. It's possible to implement a DMX-512 dimmer without a microprocessor by using shift registers and some clever latching circuits. - thus checksums would be ignored, and complexity would increase cost too much (by requiring a microprocessor).

It used to be just about every DMX device I came across was 8051 based based because that was about the only chip that could handle 250kbps. And that would typically mean there'd be a separate PROM chip, and maybe some other logic... a significant amount of board space and cost. Embedded software development was a lot harder then, require programming, test, then UV erase, then repeat... what takes me ten seconds now, took ten minutes then.

I was a Motorola guy then, and most of the DMX work we did was farmed out to someone with those tools.

Now days, pretty much any micro can talk at 250kbps. And it's one chip with flash...
 
Recall as well that the manufactures had the option to implement talkback from device to console, using the spare pair of wires in the 5 pin XLR, just nobody bothered.
Not quite true. Entertainment Technology (ET) used pin 4-5 for Talkback and configuration of their IPS dimmers. The Horizon 512 Interface and s/w was used to configure and monitor the dimmer. ET also built splitters that used both pairs.
 
Not quite true. Entertainment Technology (ET) used pin 4-5 for Talkback and configuration of their IPS dimmers. The Horizon 512 Interface and s/w was used to configure and monitor the dimmer. ET also built splitters that used both pairs.

I stand corrected, but having admired but never used ET gear, likely never would have known.
 
Huge number of words for your to browse through. At it simplest;
Whereas an 'Old" lamp required one address/channel whatever to tell the dimmer to supply power to a lamp, you can look on a simple 3 LED RGB fixture as 3 separate lamps requiring three DMX addresses and (at the most basic level of control) 3 faders on your board. When you set the 1st address on these fixture it assume subsequent addresses from that one. So if you have a 5 channel (R,G,B, White and Dimmer) fixture and 'put' it at say 20, you and your board will send data to 20, 21, 22, 23, and 24. Now to spice tit up moving heads and numerous other devices (they don't have to be lamps, just anything that understands DMX512) can take up dozens of channels (addresses).

I think the 2nd part was answered. DMX512 system send out a train of 512 x 8 bit pulses about 40 times a second and it is the board that sends incremental power levels. The ONLY thing the fixture is getting is a 8 bit data word with 256 resolution.

It all falls into place, the secret is to have fun doing it.
 
I am amazed that no one brought up RDM.
RDM stands for Remote Device Management. It allows for bi-directional communication between the console and a fixture on the same DMX chain by using the space between DMX packets to exchange data. For example, this will allow a moving light to tell a console what it is, its address, and what mode it is in. It will allow the console to change the address and mode. Care NEEDS to be taken for installation and usage, but RDM is a powerful tool.
One of the other advantages to DMX was it allowed for daisy chain topography and very long cable runs. DMX can run upto 1800' (1000' for RDM systems). Because it is a one way data transmission signal, you didn't have to worry about data collision.
Take care,
John
 
I am amazed that no one brought up RDM.
Well, it wasn't really applicable to the original question.
RDM stands for Remote Device Management. It allows for bi-directional communication between the console and a fixture on the same DMX chain by using the space between DMX packets to exchange data. For example, this will allow a moving light to tell a console what it is, its address, and what mode it is in. It will allow the console to change the address and mode. Care NEEDS to be taken for installation and usage, but RDM is a powerful tool.
One of the other advantages to DMX was it allowed for daisy chain topography and very long cable runs. DMX can run upto 1800' (1000' for RDM systems). Because it is a one way data transmission signal, you didn't have to worry about data collision.
Take care,
John

True, until RDM shows up at the party! :)
 

Users who are viewing this thread

Back