Dmx control over usb

I need to send dmx messages via c++ to control lights. This is the box I have to test…-xinterface

You can download show software (lightjockey) but not sdk or dlls with api instructions.

I noticed in the Windows Device Manager that the device is listed under the Jungo group, and there is also WinDriver listed. There is some info on their site, but probably more specific about developing drivers for usb devices…-ecode.html

Does anyone have any thoughts?


don’t know if this is helpful, but erik’s cpp glue code has a dmx pro wrapper that might be a helpful starting point:…-O/DmxPro.h

take care!

Thanks Zach.

The device I had (expensive) doesn’t have a programming api it turns out. So I got an Enttec Pro and thankfully it uses FTDI usb<>serial communication.

I have started writing my own wrapper using ofSerial that isn’t based on Eriks code glue/poco, will post soon.

However I have hit a problem with ofSerial.

If I send a byte array that is longer than 250, the device doesn’t respond properly. It must be a ofSerial thing as I have setup a demo in Processing and I can control all 512 channels.

Any ideas?


if you set verbose, what does it say?

this is the code in ofSerial –

	#ifdef TARGET_WIN32  
		DWORD written;  
		if(!WriteFile(hComm, buffer, length, &written,0)){  
			 printf("ofSerial: Can't write to com port");  
			 return 0;  
			if (bVerbose){  
			 	printf("ofSerial: numWritten %i \n", (int)written);  
		return (int)written;  

do you get to see “numWritten” or the error with !WriteFile “can’t write…” ?


This is what I couldn’t work out, I actually get the numWritten back (correct value) but it doesn’t get to the device.

So this is why I tried it in Processing.

hmm – I’m not really sure how to debug this without your device if WriteFile looks like it’s working. hmmmm…

there is alot of info here:

and this function:
BOOL WriteABuffer(char * lpBuf, DWORD dwToWrite)

might be more promising then our writeBytes. do you mind to give it a try ?

take care!

Here is some more testing, interesting results that may help the problem.

I tried sending a byte at a time, but in a for loop so…

for(i = 0, i<numberChannels){
sendByte i

Still doesn’t work

I tried splitting my bytes up into smaller arrays, i.e.
headerBytes // size = 4
dataBytesOne // size = 150
dataBytesTwo // size = 150
endBytes // size = 1

I then send via serial those 4 sets of bytes one after the other, but I get the same problem.

Could it be that, per frame, there is a maximum number of bytes that WriteFile can cope with?

Hey, don’t know if it helps but I just cleaned up and updated my USB DMX PRO wrapper to support all 24-512 channels. I haven’t had a need for more than 24 channels but I figured it would be good to know if it works for more, and it does (on all 512 channels). I’m still not using ofSerial though. There is a performance decrease that is proportional to the number of channels. I get about 900fps when I send 24 channels as fast as possible, 10fps when I send 512. Luckily the dmx pro periodically sends out the last DMX packet it receives so you only need to send it a new packet when channel data changes……-.1/Glue/IO

hi chris,

I did some more research into the issue, but I can’t see something we are doing that might cause the limits you are seeing. (it’s a bit hard to test w/ out a device tho). If you can recreate the problem with an arduino sketch, for example, it would be great.

you might want to give the serial class from cppglue a try and see if that works – it will help us diagnose. there are quite a few windows serial implementations around, and I’d try a few to see if something works, then we can debug a bit…

take care

thanks for your help.

I gave up on ofSerial, I’m now using the ftdi d2xx drivers directly. Enttec say it is quicker as well.

Will release this is an addon this week.

hey chris,

I’m glad it’s working but if you have time it would be nice to revisit this since you have a device that doesn’t work (and we don’t). we would like to know what the problem with OF serial was, and would need your help to try, for example, alternative c++ serial implementations or to make an example that we can test, etc. that way, the OF code can get better…

take care,


Sounds like you solved this already. Anyway, here is some code i’ve been using on windows to send DMX signals through the Enttec Open Dmx. It can only send values though. It uses windows serial functions.


We are working on a light installation which we want to control over DMX. We’re using the Enttec USB DMX Pro and the DMXPro class from CPPGLUE.

Everything seems to run smoothely until I try and send more data. We want to controll a raster of 311 x 11 lights which still is in the 511 range…

This is the code:

sending = true;  
// DRAW  
if( dmx.isConnected() && sending )  
	for( int x=0; x<311; x++ )  
		for( int y=0; y<11; y++ )  
			int lightValue = pixelModel->getValue( x, y ) * 255;  
			dmx.sendLevel( DMX_START_ID+x*y, lightValue, true );  

I’m getting this error:

OF_ERROR: ofSerial: Can't write to com port  

This error occurs just a couple of times when I reduce the number of calls of sendLevel() to something below 5. But calling it 341 times a frame completely messes everything up :slight_smile:


I have created a ofxEnttecDmxUsbPro addon which uses the ftd2xx.dll library instead of ofSerial, and it works for that volume of data. I’ve not released it publicly yet as there are a few things I wanted to finish on it, but I will put it up anyway soon.

I will email you off the forum to test. If anyone else wants to test this let me know.


I’ve been using Chris’ ofxEnttecDmxUsbPro addon for a bit and it works really nicely. Doing DMX’s maximum of 44 fps when sending full 512 channel frames no problem. (I just the set the fps of my oF application to a slower speed, so that my visualisation/simulator would have a similar framerate as the real installation).

We used it for a big (7x7x5 meter) lightsculpture we created for the Lowlands festival in Holland this summer. No documentation of that online yet though, so I included an image here. (and found this short video-snippet a festivalgoer put on youtube).

Will look for the code I wrote to test the addon with my dmx hardware and post that soon.


Here’s the first code I used to test the communication between oF and my DMX hardware using the Enttec DMX USB Pro and Chris’ ofxEnttecDmxUsbPro addon. Although it was created for the specific dmx hardware (and it’s addressing scheme) I used, this might be helpfull for others aswell. More info in the comments in the update function in testApp. [you’ll need chris’ ofxEnntecDmxUsbPro and memo’s ofxSimpleGuiToo addons to run].


Hey Chris - any idea when ofxEnttecDmxUsbPro might be released? I am working on a project that will need C++ based DMX control and would hate to reinvent the wheel - especially since we are using OF. You did try to email the code to me once but Gmail bounced it - if you have a moment you could try sending a copy to - hopefully the server will be kinder - I’d love to give you a guys a hand on this - otherwise, anxiously awaiting the release :slight_smile:



hi justin

i emailed you the file on 2nd november. i just tried again…

----- The following addresses had permanent fatal errors -----
(reason: 552-5.7.0 Our system detected an illegal attachment on your message. Please) (expanded from: <jlove@***>)


anyway, the file is here…

pc only at the moment, not finished either.

great! thanks Chris! I guess Canadian mail servers are over paranoid! J

hey guys,

i just wanted to ask if someone tried another usb dmx device then the enttec dmx usb pro?