Using an RS 232 to 485 converter box for DMX program

D

domls

Member
Hello to all, first post here!

I am writing a DMX software program to control lighting gear from my laptop at live sound gigs. I'm a very experienced RS 232 programmer (VB.NET VS 2005), so I bought an RS 232 to RS 485 Converter box from B&B electronics. I've wired up my own DMX connector from the box...

I also have the entire ESTA National Standard USITT DMX 512-A book with all the DMX specs. I know that (from pages 19 & 20 of the book), the timing is critical. I know I can set up the serial comm (232 side) so that the port is opened with, say 9600 baud, 8 data bits, 2 stop bits, no parity and RTS handshaking. This should do the trick, since I'm using the 485 converter box.

What I am not sure about is sending the right characters. Let's say I want to send the "SPACE FOR BREAK" followed by the "MARK AFTER BREAK" and then the NULL (START CODE) followed by the Channels 1->4 data only.

If I want Channel 1 data to be 3C (hex), Channels 2->3 to be 00 (hex), and Channel 4 to be FF (hex), I would normally think that I just have to send the following bytes for the complete loop: 00 FF 00 3C 00 00 FF. But this doesn't seem to be working right. When the specs talk about setting the line high or low, how does that relate to the characters that I'm sending? What is the converter box doing in terms of the incoming data, and do I need to shift the data I'm sending with regards to the least significant bit/most significant bit (LSB/MSB).

Thanks to all!

domls
 
DMX controlled devices are looking for all 512 values for the universe. Each device counts the bits that go by and act on the ones that apply to them. So, if you are only sending out data for channels 1-4 you will confuse the gear. You need to transmit 1-512 all the time, even if the values are 00.
 
OK, no problem creating the sending of all 513 bytes of data (START + 512).

rmarston: Thanks for the link. I checked it out briefly and, like many (or most) other web sites with DMX info, it really gives very detailed information about hardware, timing, etc... But it seems that nobody ever talks about the actual sending of of the bytes of data? In other words, when they say HI and LO, what characters are being sent? How does it relate between RS 232 and RS 485???

I've got the serial port write on a timer. I've set the timer to send data every 250ms (I can set to any value, if needed). Here's my write code. Does anybody have any write code that they KNOW actually works?

Private Sub tmrWrite_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles tmrWrite.Tick
Dim b() As Byte
Dim s(0) As Byte
Dim m(0) As Byte
Dim timeout As New System.TimeSpan(100000) '100 microseconds = 100,000 ns
Dim timeout2 As New System.TimeSpan(12000) '12 microseconds = 12,000 ns

Erase b
ReDim b(512)
s(0) = 158 '9E

SP1.Write(s, 0, 1)
System.Threading.Thread.Sleep(timeout)

m(0) = 223 'DF
SP1.Write(m, 0, 1)
System.Threading.Thread.Sleep(timeout2)

b(0) = 0
b(1) = 60
b(2) = 0
b(3) = 0
b(4) = 255

With SP1
.Write(b, 0, 513)
End With
End Sub

Note that I had captured data from my Behringer controller into Hyperterminal and the "9E" and "DF" hex values are from the capture...just guessing that these might be the LO and HI values.

Thanks!!!

domls
 
The LO and HI refer to the signal level for each bit of data... so sending 0x00 will be all low for 8 bits, 0xFF will be all high for 8 bits, and 0x55 will alternalte high and low. (I may have the high/low backwards, I don't have the specs in front of me...)

RS-232 vs. RS-485... They are two different electrical specs for serial data. Converting from one to the other will give you different signal levels (RS-232 is referenced to ground, RS-485 is a differential signal). Note in terms of data rate, bytes, etc, what you put in is the same as what you get out, only the levels have changed.

Are you running at the correct bit rate? You mentioned 9600... I believe that DMX requires 250,000 BPS.
 
Thanks, fredthe,

I'm not sure that the B&B 232 to 485 converter box handles 250,000 bps, or that there is a 1 to 1 correlation between bps in 232 and 485. I'll have to look at the specs of the box, and see what it says. It might have a limit of 115200 on the 232 side. Baud rate in RS 232 is x number of bits per second, so that if you send a character such as FF, you usually have 10 bits per byte (but in this case, you have 2 stop bits, making for 11 bits per byte).

I guess my biggest question concerns the conversion of data in the box between 232 and 485. In other words, if a byte of FF into the 232 end of the box is converted, what is it converted to, or is the box smart enough to know HOW to convert the FF into an 8 bit high signal automatically (where all 8 bits are set to HI)?

Any ideas?

Thanks!

domls
 
Allow me to give a real-world example. I have a "COLORpalette" from Chauvet which can be set up to be a 6, 9, 15, or 27 channel DMX LED light. The first channel determines the function. If I set the first channel with a value of between 060 and 079 (decimal), then it is set to 6 Channel mode. The second and third channels are Auto mode speed and Strobe (which I usually don't use, so these are 0).

The 4th channel is Red 1, 5th Channel is Green 1, and 6th is Blue 1 (assuming that I've set Channel 1 to 6 Channel mode, as above). So, by sending a value of 255 for Channel 4, 255 for 5, and 255 for 6, I get all LED's on at full blast, thus giving a White light overall. If Channel 4 is 255, 5 is 0, and 6 is 0, then, obviously I will get a Red light overall.

What is unnerving for me is that the Behringer (and many other) hardware mixing-style dimmer boxes give values on the sliders from 0 to 100 instead of 0 to 255, when all the specs for modern LED devices give detailed channel values ranging from 0 to 255! This makes it incredibly difficult to set Channel 1 to a range of 60 to 79 (which is the range for 6 channel mode), and thus my want for a software program to control the lighting instead. What else is crazy is that there are only 12 main faders (with two banks=24), so heck, in theory, the Behringer controller can only handle the ONE LIGHT (if set to 27 channel mode).

Thanks!

domls
 
For the (any) 232 to 485 converter, it's only a signal level conversion.... in terms of bit rate, etc, what you put in is what you get out. Since DMX is 250,000 bps, your RS-232 port would need to be set to the same, which it probably can't.

Looking at your code snippet, your reference to HI and LOW seem to be in relation to sending the BREAK and MAB parts of the DMX signal. Unfortunatly, these are Constant levels, not something that can be programmed as a byte to be sent out by a UART, since the byte will always be sent with start and stop bits, but the requirement is to keep the output at a single level, with no transitions, for a specified period of time. Unless you have a port that can be directly programmed to output a Constant low or high level, you're out of luck using a serial port. (This functionality may exist, but may or may not be easily accessable.... I haven't looked at low-level UART programming in 15+ years :))

Oh, and don't get me started on "Baud" rate... unless you're dealing with a modulated signal, you really mean bit rate. (Yes, I know the documentation probably says baud, but it's still not correct usage.)
 
To convert from an attribute value (scaled by 255,) to the board value (scaled by 100) just multiply by 0.392
 
OK, thanks.

Perhaps I should start at the beginning, then. There certainly are software controllers on the market today (like MyDMX from American DJ). It appears that it comes with a "box" to convert the signal (I would imagine) from RS 232 to DMX. So, first question, what is the box actually doing, and second, if they (and others) can do it, then how is it being done with respect to writing the software for Windows PC's?

On another note, I know I could multiply the value by 0.392 (100/255) to get the "percentage" to use on the controller's fader, but really, this is unreasonable at a live sound gig (low light...good luck moving the fader to between 23.52 and 30.968 exactly)! This represents 060 to 079 per the Chauvet documentation, and the fader only has numbers at 0, 50, and 100!!! That's just one of the reasons why I want to write this program!

IMHO, hardware controllers were probably great back in the day of just having a bunch of par cans with color gels, but now with the LED lights and all the available controllable channels, it seems that the hardware is far inferior to the overall capabilities of running a light show???

domls
 
The box from American DJ is probably USB, and it most certainly is buffered. The computer just says what channels need to be at what intensity, and a microcontroller in the box takes care of the rest. Your computer is multitasking, so it has to take care of sending the DMX signal, and checking your email, and displaying stuff on the monitor, etc. The microcontroller in the DMX box only focuses on getting data from the computer, and spitting back out on the DMX line.
 
Hi Soundman,

Thanks for the input. I checked out the ENTEC site. It looks like they have a USB to serial converter. B&B Electronics (Industrial Serial Communications - B&B Electronics) also has several USB to serial converters that support RS 232 & RS 485 serial comm. In addition, they sell an Ethernet to serial converter box. I think that I would rather have a commerically available box rather than one tied down with a GPL license. I doubt there's any difference between the two. However, I really do like their documentation on the ENTEC site. Perhaps it should be able to help!

But really, I want to be able to write my program because then I have FULL control over how the program operates and can tailor it to my specific needs (such as a text box under each fader that lets me actually enter the value! Seems that I just need to write the correct driver to do this, and/or perhaps use a USB to serial box instead of a 232 to 485 box?

Thanks!

domls
 
I'm not sure if we've solved the frame-break problem or not, but it's interesting nonetheless.

Hardware boards aren't really outdated; they're just not suited to driving movers (except for the ones that have things like fixture libraries and encoder wheels).

But I like the idea you've got. I like finding low-level solutions to things .. one I want to do sometime is an AMX192 -> DMX512 translator. That's an "eventually" project. Before that, I'm tinkering with a camera-tally-multiplex circuit that creates (and a receiver that decodes) a serial digital stream on one wire with multiplexed clock .. all using 7400 logic.
 
Here's what I've learned today:
It appears that the only real solution to writing my own program for controlling DMX lighting fixtures is to either A) Build my own converter box that does 2 things: 1) converts the signal from say, USB, to RS 485, and (most importantly) 2) ALSO ESTABLISHES A PROTOCOL FOR MY DMX SOFTWARE TO USE. In other words, I need to actually create my own protocol and implement it in hardware. Then, I will be able to create a VB.NET program to run the lighting.

It would seem to me, and yes, I know I'm a newbie/novice at the whole DMX thing, that the architecture of DMX really places a serious limitation on those who have the ability and would like to write their own controller software. Perhaps the designers of DMX were a little short-sighted and didn't take into account the future of lighting fixtures and the fact that a computer-based program would be MUCH more productive in presentation of a show? I know that there seem to be a lot of pluses to using EIA 485, but now, I wonder, perhaps there's a better solution out there (How about every fixture being wireless and receiving signals from the computer via wireless ethernet)?

I offer my very humble opinion on this matter, but as a programmer for 25+ years, and having written commercial data collection software for GPS and Robotic total stations for surveying-grade applications, I have found the difficulties here quite hard to swallow.:rolleyes:

That said, I may go with the ENTEC solution, or I may build my own box and EPROM program for the protocol. Thanks to all who have contributed to this discussion, and I still welcome any and all comments!!!:!:

domls
 
domls said:
...Perhaps the designers of DMX were a little short-sighted and didn't take into account the future of lighting fixtures and the fact that a computer-based program would be MUCH more productive in presentation of a show? ...
Click to expand...
Yes and no. First, it was "specification by committee." CB Member STEVETERRY was one of the major proponents. Its primary purpose was to specify a common language to allow any manufacturer's console to control any other manufacturer's dimmers. USITT DMX-512 (1986) was never intended to control anything other than dimmers, and was based on proprietary industrial hardware and dedicated controllers. Second, most lighting professionals agree that a personal computer, with keyboard and mouse, is no substitute for a dedicated control surface. We've argued this issue here many times. One of many threads: http://www.controlbooth.com/forums/lighting/6262-running-lights-pc.html?highlight=personal+computer.

If you wish to be forward thinking, research ACN. Unfortunately, no fixtures currently implement it. An interim step, not recommended, might be for you to generate Art-Net from your PC, and purchase an Art-Net to DMX converter (beyond your budget).

I applaud your desire to write your own software, but the fact is there already exist many solutions ranging from sixty dollars to over $50,000 to control lighting. Why re-invent the wheel? While the wheel you invent may be perfectly suited to you, it won't fit any other vehicle, no one but you will be able to use it, and will cost more time and money than an existing solution. And chances are good that it won't be as elegant. Want to program lighting via timeline, just like editing video? How about a touchscreen, or FIVE (+3 external monitors!)? That being said, many professional lighting control systems today run under Embedded XP, Linux, or Mac OSX, so it can be done, just a matter of time, money, and perseverance. It took High End Systems, a major manufacturer, at least five years to deliver a show-capable HogIII, and I have no idea how many programmers and developers they had working on it. See here for the story of the founding of the predominant stage lighting manufacturer in the world. I believe it wasn't until seven years later, in 1982 when EPCOT opened, that the company showed a profit.
 
Last edited:
As others have mentioned, there are quite a few parts to DMX

- The electrical spec is RS485 (5V differential)
- The baud rate is 250000 (this is not a standard RS232 baud rate and can't be accurately generated by many standard baud rate generators.
- You don't need to transmit all 512 data bytes, but there's a minimum number that is needed.
- You need to be able to both send bytes, usually with a UART, and be able to pull the line low. This may be faked by changing the baud rate to a very low value (75 baud comes to mind) and sending a BREAK.
- Some receivers are very sensitive to non-standard timing and spacing between bytes. This often shows up as flicker or jittering in a mover. Driving a 232-485 converter from a Windows PC is what gives the Enttec Open DMX a bad name...

The correct way to do this is to use an external micro to take commands (set channel 3 to 42, set all channels to 0) and runs the DMX loop itself. There are many examples of this out there, some with schematics and source available. It's really quite easy.
 
:)
Hi N1ist,

That sounds like a good idea. I actually want to build my own "box" as it were that is dedicated to sending the data via DMX protocol. Sounds like I need to buffer the incoming data in the box and just have the program worry about sending data via a protocol that I create for talking to the box.

I really don't mind re-inventing the wheel, as it were, so that I can create an interface that suits me and add to it's capabilities as I go (i.e. as I purchase more stuff). In browsing the American DJ site the other day, I saw a new toy that they have out called the LED Messenger. I downloaded the manual, specs, etc. This device is of course DMX controllable, and it allows you to pre-program words using a standard PS2 keyboard. Now, I don't own it yet, but I'll bet that you can't program the words via DMX. The 3 channels are only for controlling which pre-programmed words to display, sensitivity, and strobe.

The reason I bring this up is that it's an example (to me) where, perhaps, DMX doesn't have the capability of doing something that, in this day and age, should be very easy to do. In other words, let's say you have the fixture set up on stage. Now let's say that you have a controller (be it PC or hardware) set up at the back of the room. IMHO, you should be able to edit the words (for display) from your remote location and then activate them when desired. However, it appears that someone would have to take a PS2 keyboard onto the stage (or the included infrared remote controller) to first edit the text, and then go back to your DMX controller to display the text.

This is what I mean, I suppose, when I say that the lighting fixtures are getting well ahead (technically speaking) of the DMX protocol capability...or, am I wrong?:oops:

Anyhow, do you have any links for the schematics etc, for building a box?

Thanks also to TimMiller and derekleffew.

domls
 
You must log in or register to reply here.

Similar threads

Kyla Werrett
A.C. Lighting Inc. Delivers a Stellar Lighting Rig to Discovery Church
Replies
1
Views
1K
RonHebbard
R
Joel Engelhardt
Using Martin M-PC with ANY USB-DMX interface - Cheap!
Replies
0
Views
9K
Joel Engelhardt
Joel Engelhardt
J
DMX physical layer questions (building a DMX receiver using an FPGA)
Replies
3
Views
4K
jonosphere
J
IanJ
The Cheap LED Round-Up
2
Replies
36
Views
10K
church
C
dvsDave
DMX
Replies
0
Views
11K
dvsDave
dvsDave

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back