Control/Dimming DMX via Parallel Port

[sekatsim]

I'm attempting to expand our current lighting system by another 50 channels or so by hooking up a computer and using the parallel port to control the dmx. What I've done so far:

Wrote a program in Turing (as a prototype) to output to the parallel port (using pin 1 as high, and pin 2 as low):

100 millisecond BREAK (low)
8 ms MARK AFTER BREAK (high)
11 bit (44ms) START CODE (aka. Channel 0 @ 000) (low)
4 bit (1ms) BREAK BETWEEN PACKETS (high)
11 bit (44ms) level value for channel 1 (so.. channel 1 @ 255)(high).

Connected pin 1 on the parallel port to pin 3 on the DMX cable (5 pin). I connected pin 2 to pin 2.

Ran the program, and it turned on channel one at full. Beautiful.

I set up a loop for the other 50 channels-- however, in execution, channels one through 5 or six or so would turn on (sequentially), and then turn off. I realized that I was supposed to be working in microseconds, not milliseconds, and I was timing out the dimmer.

Rewrote the program in c++ on linux. It works insofar as it controls the parallel port, I hook up some LEDS and they all turned on fine. However, it won't turn on any lights. I even tried slowing it down to approx millisecond speeds, still no luck.

Attaching my parallel output to an oscilloscope, alongside the output from our current lighting board, it seems to me like my output is several thousand times slower than what it should be operating at (even at microsecond values). I cant figure out whether this is a product of switching over to linux, or just being slowed down by having a multi threaded computing environment.

I was under the impression that the parallel port could operate fast enough to control DMX, but then I also see that all commercial parallel-to-dmx controllers have some sort of memory/buffer between the computer and the dimmer.

Any and all information you can throw my way on this subject will be most helpful. I can post my sources here tomorrow, if anyone is interested in giving this a try for themselves. All it requires is an old printer cable with the end cut off, and some needle nose pliers.

Thank you

 

[JD]

Yea, parallel ports have a speed problem.

The "old" Centronics standard was 1kb. What you are doing is using the parallel port as a serial port output. That is not the problem though.

I think the problem is that DMX is transmitted at 250kbs and the port hardware is just not designed to work at that speed so you end up with bit overhang, or the register is downverting the speed. I don't think there is a way of changing that through software.

As there is no separate clock line, there is no way for the DMX receivers to read anything off speed.

Most dongles are USB. There are parallel dongles but they read the full 8 bit parallel output, and convert it to serial data. Here is a site I ran across. Hope it helps.

DMX 512 printerport interface

Looks like someone doing the same thing.

 

[PadawanGeek]

When you finish this program, I would love to have it because it would be great to be able to use it with my laptop for testing/focusing purposes.

Good luck!

 

[cutlunch]

Sekatsim I am amazed you got this working at all.

Theorecticaly with a modern parallel port you should be able to get the speed up to 250KBPS.
But I am not sure if you understand how the DMX interface works from an electrical point of view.

So I am including a link to a very good website that explains exactly how DMX512 works. I used the info from this site to build microcontroller based rigger boxs.

Ujjal's DMX512 Pages....DMX512 How & what ?

You said with the slow speed you could get channel one to full. Did you try any other values to see if it worked at these?

If you look at the link I provided under physical you will that the DMX signal swings pins 2 & 3 between a plus and minus voltage. Under your system you can only swing the DMX signal between +5 V and ground.

If you used a SN75176 RS 485 transcevier chip and toggled one bit of the parallel port this might work better.

As people have already mentioned interfaces using the parallel port generally have a microcontroller interface to handle sending out the DMX signal.

Trying to do it straight through the parallel port is very difficult because you can't let anything interfere with the timing. When you were using milliseconds system interrupts were probaly being handled within the pauses before you changed the port bits. But at microsecond speeds are probably being interrupted by other system programs.

You can buy a number of pre-built parallel or USB interfaces with sample code and concentrate on writing the user interface rather then the DMX signal driving. software.

The DMX page link I give you has a links section and you find some interface manufacturers there. Look under the "DMX PC/ MAC based " link.

If you want to build your own interface you could use that link someone else suggested. Or you could start from scratch with an Atmel AVR microcontroller and a freeware version of BASCOM-AVR Basic compiler. You can build a cheap programming cable .

Good luck.

 

[len]

For all your effort, I would think that buying the Entec box (typically available on ebay for about $60) would be more cost effective. You can use several different programs to run it, the software is free, the box is usb and works fairly well I'm told, and you won't be spending hours troubleshooting. No satisfaction in building it, but you could then move on to something more fun.

Also, Martin's LJ had a parallel port interface back in the day. It would only run LightJockey, and only on pcs operating Win98 and below, but it did work.

 

[n1ist]

A better technique would be to use a single-chip micro (Atmel, PIC, etc) to take the parallel data from the printer port (or from a serial port) and generate the DMX. Another way that might work (if you can get the baudrate right) is to use the serial port driving a MAX202/MAX485 combo to get RS485, but the PC will have to continously spit out the data this way... The Enttec PRO does it the first way, the Enttec open USB does it the second.

There are quite a few examples out there that you can copy.

 

[TimMiller]

Vellman makes a USB to DMX converter for about 70 bucks and it works great. It is compatable with quite a few programs.

 

[JD]

Yea, you have to consider what your time is worth! Projects are fun, for the first 100 hours.....

The big problem with PCs are that DMX wants a feed 100% of the time, whereas PCs like to go about doing other things at the worst possible time! You want to be able to "throw" the values to some interface that's only job is to spit out a DMX stream.

USB is more friendly to the theme.

 

[sekatsim]

I'm surprised at all of the responses-- sorry I haven't checked back here in a while.

For all of those interested in this sort of thing, here's what I've found out:

Cutlunch: Yes, I'm amazed that I got it working too, with what I know now. The dimmer that I got to activate was an old Strand CD80 from the early eighties, and I can only assume it was designed with a much less strict interpretation of the dmx protocol. What I was doing, in Turing, to emulate RS485, was setting pin 1 HIGH, pin 2 LOW for "dmx-high", and pin 1 LOW, pin 2 HIGH for "dmx-low". This was sluggish and crude, but it was enough to activate the first few channels on our older two dimmers before they timed out. Our newer (CD80-- 1994) packs totally disregarded that data.

Then: I bought a PIC16f628 microcontroller (thanks, n1ist), read a lot of assembler tutorials, and hacked together a program that would do the same thing I had been doing in Turing (pin 1 high pin 2 low / pin 1 low pin 2 high), except being 4mhz, it can do an entire 512-sized universe refresh in about 2ms. I ran That and successfully turned on all 24 lights on our two older dimmer packs. Still no luck with the new one. This system wasn't computer controlled at all.. it was just set to make all lights go to full and keep them on indefinitely. When it first worked, I was quite pleased, having spent a full day just constructing the programmer for the chip.

I figured that I was still having timing issues because I was not using True RS485. My microcontroller takes 1uS to execute each operation, meaning that there was a 2uS gap between each "dmx high" and "dmx low".. and when you're looking at 4uS bits, I guess that was enough to screw up the reception.

SO: I bought an RS485 transceiver, thank you again for That suggestion, wired it in, but being in a hurry, I didnt actually reprogram my PIC16f628, I just attached the RS485 to "Pin 1" and hoped for the best. It worked.. sort of. I did manage to turn the new dimmer on, at full, but it only stayed that way for about 5 minutes, and then shut off. This is probably because I havent yet fixed the timing in the code on the chip. I suspect that once I do that, I'll get all 50 lights on at full. That's for monday.

In the meanwhile..

I've been working on two things:

1.) The interface between the computer and PIC16f628. Was originally going to go with parallel, because I knew it well. Now leaning toward serial, because I learned a fair deal about it building the programmer. Was *thinking* about Maybe USB, but I'm very new to this engineering thing, and USB sort of scares me. If anyone has any experience with this, I'd be glad to hear it.

Anyway, the PIC has 255 memory addresses (the max for one chip, but still a big step up from 50), which store the value for each of 255 channels (with values from 0 to 255, obviously). The chip is programmed to take those values and refresh them down the line, it does this at approx 2.5mbps, aka once every 1.2 mS, aka, about 800 times a second. Fast!

I'm hoping to be able to (using whatever interface I settle on) write directly to these memory addresses, and then of course the PIC will update the dimmers. I'm trying to decide on a protocol for this.. I've heard whispers of USART, but I'm not sure how it all works. I need something fast, i.e. (Start Bit, Channel Byte, Value Byte, Stop bit), and it also needs to not interfere with the PIC's refreshing of the packet. Suggestions here, as well, would be welcome.

2.) Also Meanwhile: I've been developing the software. I knew a bit of C++ from prior projects, I've learned a lot more in the past week. I'm constructing the GUI with Qt4, under linux (for stability and improved port writing speeds). Exciting features:

Drag and drop rearrangeable interface. Much like the "palettes" in photoshop. Different "dockable" widgets feature:

1. Grand Master
2. Cues (small preview, supports editing and playback)
3. FX sequences (up to 8, can be individually named)
4. QuickFX(tm)- you can drag a series channel into "QuickFX", set the speed with a dial, and press Execute to build chases/sequences on-the-fly

Cue editing/storage is managed by a MySQL backend database. "Cuesheets" can be created for individual shows, and remain separate from other shows. No more "Cue 99 go" because cues 1 through 98 are from a different performance. Cuesheets can be exported as XML documents for backup / transfer to other systems. All cues can have descriptions added, for convenience. i.e. "Cue 10 | First entrance". Cuesheets maintain their authors, last edit dates, last execution dates, last execution Runtimes, and Average Runtimes.

FX's are managed in the same way.

Main window features sets of submasters, 18 per "tab" per screen (supports up to 3 widescreen monitors at 1280x865 resolution). Tabs can be created/arranged according to functions. "Rock Concert" tab could hold your washes, cycs, and fog machines, while "Public Announcement" tab would have your spotlight, areas, and house lights. I only have 8 submasters in currently, as changing the code for 8 at a time takes a while, and I dont want to make the rest of them until I've settled on a default functionality. Currently supports bumping, latching, solo'ing, and Linking (press link on multiple submasters to move more than one sub at the same time with the mouse).

There is also a Console, for traditional keyboard type operation. Supports the usual, CUE 1 GO, SUB 10 REC, 1 THRU 50 @ FULL, etc.

#1 FEATURE: Joystick interoperability. Recognizes joysticks (up to 2) attached (on linux) to /dev/js0 and /dev/js1. Automatically calibrates axis ranges, and allows user to specify which axes/buttons go with which functions. As I have it now, moving left or right selects a submaster (by highlighting it), pushing up or down increases/decreases the value. The trigger acts as a "Bump". Twisting the stick (z-axis) moves between tabs. It is So Much Fun (sorry to gloat, but I'm really enjoying it). Both joysticks move independently of eachother, so you can adjust/bump two submasters (or channels) at once. The slider at the base of the joystick I'm using controls the grand master. The joystick handlers are multithreaded, for near-realtime responses.

One of the major drawbacks to computer-based lighting desk was the lack of physical sliders, and thus the awkwardness of controlling a light. The joysticks eliminate this by allowing you to select a submaster almost instantly, and control two at once, all without taking your hand off the controls.

I'm attaching a couple of screenshots from the development process. If anyone wants to download the source and give it a try, I'd be happy to post it somewhere.


So Now the Pitch:
If anyone out there has knowledge of microcontrollers, interfacing, assembler, c++, or qt-- I could Really use a second developer on this. I've got a growing list of bugs that are quite trivial to fix, but I just havent had time to sort through. I've been putting in 10 or 12 hour days on this for about a week now, and I need to have it finished by the end of june. If you're wondering why I'm working so hard at it, it's become my end-of-term assignment for my engineering class, and I've also got a couple of schools looking at purchasing installations of the system for a very comfortable price-- if I get it running fully, and without all the little glitches.

Thanks to everyone for the help thus far, and sorry for the lengthy post, I'm quite excited about all of this, though I suspect many of you understand the feeling.

Cheers!
Sekatsim