Parts list:

• SHINP CL-16RGY
• OpenDMX USB dongle

A while ago I was given a SHINP CL-16RGY by 3ric, to play with. We had no software for it, no experience with the box, and no clue what we could make it do. Here’s the story of what I did to make it work, and what we’re going to use it for in the future.

First, I needed to install a driver the Enttec Open DMX USB dongle. This is how we send signals to the laser. The first bit of info I found was here, a tutorial on exactly the USB dongle we have. One problem: it’s for a Linux box. I have a Windows laptop. I fired up my Ubuntu virtual machine and got to work.

Compiling the driver was fairly easy. Mentioned in the tutorial I linked to is a driver from erwinrol.com. All I had to do was run a git command, make, copy the driver into the right directory, and then depmod. Voila, plugged the dongle into my laptop and it was recognized by Ubuntu as /dev/dmx0. Perfect! Next step was figuring out how to send it commands. I found some sample code somewhere (though unfortunately I can’t remember where). It looked like this:

#include <stdio.h>
#include <string.h>
#include <fcntl.h>

int main()
{
  unsigned char buffer[513];
  int fd;

  memset(buffer, '\0', 513);

  fd = open("/dev/dmx0", O_WRONLY, 0);
  while (1) {
    write(fd, buffer, sizeof(buffer));
  }
}

This worked to prove that the driver was working. The laser box has a little green LED on the back which signifies DMX512 data being received. It was blinking furiously. I thought “well, since it’s receiving data, everything after this will be easy.” I was very wrong. The manual told me that certain channels controlled certain things (channel 1 for X position, channel 2 for Y position, etc), and I assumed that the information would be correct. No. Of course not. It can’t be that easy.

I nearly gave up the project at this point. The terrible layout of the buffer was pissing me off. After a while though, I found a Windows DMX program. It didn’t work how I would have liked it do, but it let me adjust the channels in realtime, so I could figure out what things were. I squealed with joy (on the inside, of course) and took note of which channels corresponded to which functions. At the time, my code was in Python, so I edited the Python file and ran it. LAZOR WORKING! I tried editing a few of the channel values to make sure I was editing the correct positions in the buffer, and it worked just like it should.

My code at this time was in Python though, and I wanted the end result in C. I pretty much recreated the same code in C, implemented getopt, and cleaned up the code. It ended up being beautiful! Here is the sourcecode, a binary, and the CL-16RGY manual:

http://www.gnewt.at/lazor/