Hello, I'm new here so first, just a hello to everyone on this forum.

Anyways allow me to explain my situation here.

I received a certificate in General Live Sound and Lighting (not the exact name) a few years back and have returned to upgrade to a diploma. Me being the one student who does electronics as a hobby, was challenged by my instructor to build a device to control DMX lighting via a PC. However there was one limitation I had to follow, the device must be controlled over good old RS-232.

At first I figured this would be easy, I would purchase a simple RS-232 to RS-485 adapter from Amazon. However, I then came to think of software support. I see lots of USB to RS-485 adapters out there being used with the Enttech OpenDMX plugin in DMXControl. However, it doesn't make sense to invest $12CAD in a device that may very likely not work with this same setup.

So, I'm looking for advice from someone with better "serial knowledge".

The main question is: Is anyone aware if any of the DMX Control programs out there may be able to talk through these devices, or can the popular software control fixtures through this device?

P.S. This is the device I am looking at on the Canadian Amazon.

No sense in spending money if it likely won't work.

Thanks,

I'm not a DMX expert, but I have used many different RS232- and USB-to-RS485 adapters in the industrial electronics field. I like the B&B Electronics "ULinx" adapter. It's USB-to-RS485 converter that appears as a COM port to your PC. It's also isolated, so a catastrophic fault on the RS485 network is less likely to hurt your PC. The same company used to make an RS232-to-RS485 adapter that works well, but I believe they've discontinued it.

Regarding the Hardware: get yourself a converter that can be hardwired to full-duplex, RS422. This guarantees that the transmit line is always driven, and as long as you are not doing half duplex RS485 (Reading back data from the fixtures) you can avoid the complexity with driver/receiver switching.

On the software side, I think it might not be trivial to reliably send the data stream, while obeying the timing restrictions on breaks and timeouts, but please prove me wrong :-).