Author Topic: DMX512 controller software  (Read 2210 times)

0 Members and 1 Guest are viewing this topic.

Offline HwAoRrDkTopic starter

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: gb
DMX512 controller software
« on: December 29, 2024, 11:30:01 am »
Can anyone recommend any software for Windows that can perform some basic DMX512 controller functions using commodity (i.e. non-proprietary) interface hardware?

Seems like there's a myriad of "virtual desk", "light-show", or "VJ" software out there but they all seem to only support proprietary hardware. I was hoping for something a little more low-level or diagnostic in nature, that can use general-purpose commodity interface hardware.

For example, I have some USB-UART adapters (e.g. CH340, CP2102N) and RS-485 transceiver breakout boards, and I'm hoping I can bodge something together with those so that I can send some test DMX512 traffic to a device for testing purposes.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14131
  • Country: gb
    • Mike's Electric Stuff
Re: DMX512 controller software
« Reply #1 on: December 29, 2024, 11:58:08 am »
QLC+ suports the FTDI  USB-RS485 interfaces
https://www.qlcplus.org/discover/compatibility

Not sure how possible it is with  other USB-serial interfaces as they need to do 250kbaud and create break conditions.
The CH340 datasheet only lists the "old-school" baudrates
« Last Edit: December 29, 2024, 12:03:11 pm by mikeselectricstuff »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7085
  • Country: ro
Re: DMX512 controller software
« Reply #2 on: December 29, 2024, 12:23:34 pm »
From what I remember, all the non-proprietary were expecting a FTDI-based USB-serial.  I don't remember any to be working with CH340, but that was some years ago.  Maybe they added it since then.

Last time I've used a FT232RL as a USB to serial bridge, no flash ID was needed, only soldered it on a perfboard, and it was seen (and working OK) as an Open-DMX interface:



The PC software was called FreeStyler https://www.freestylerdmx.be/  I see now they have a forum, maybe they can tell if any of those interfaces from the support list is with CH340.

If not, maybe use an Arduino as an AVR-DMX interface, which is supported by FreeStyler, but I didn't try.

Offline HwAoRrDkTopic starter

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: gb
Re: DMX512 controller software
« Reply #3 on: December 29, 2024, 12:36:46 pm »
QLC+ suports the FTDI  USB-RS485 interfaces
https://www.qlcplus.org/discover/compatibility

Not sure how possible it is with  other USB-serial interfaces as they need to do 250kbaud and create break conditions.
The CH340 datasheet only lists the "old-school" baudrates

Haha, I just discovered QLC+ myself. :) And then realised it only supports FTDI USB interfaces. :(

But then I realised I do in fact own an FTDI-powered USB-UART adapter - I have an ESP-PROG that is essentially just an FT2232 dual port interface. It's recognised by QLC+ as two "DMX USB" interfaces, and if I set one of them as an output, I can see something happening on the scope. :-+

Now I just need to figure out how to use this software...
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7085
  • Country: ro
Re: DMX512 controller software
« Reply #4 on: December 29, 2024, 12:52:41 pm »
Indeed, many (if not most) of the MCU/FPGA programmers are using a FTDI, same, you can find FTDI chips on a lot of devboards you might already have around.

If you are using ready made DMX hardware, you'll also need a TTL to RS485 chip and some XLR connectors.  The 485 chips proved to be much harder to find in my case (I was looking that day to brick and mortar shops only, to finish the interface the same day).  Eventually found two SN75175 https://www.ti.com/lit/ds/symlink/sn75175.pdf, they are between the FTDI chip and the DMX bus.

Online themadhippy

  • Super Contributor
  • ***
  • Posts: 3318
  • Country: gb
Re: DMX512 controller software
« Reply #5 on: December 29, 2024, 01:07:08 pm »
If you can find an ancient version of chamsys that did support the open dmx  along with a few other basic dongles,but then they released there own dongle and took the option away.However if you fancy a challenge you can use the artnet output and again more ancient software, like entecs pro manager, to spit dmx out yer dongle from artnet.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14131
  • Country: gb
    • Mike's Electric Stuff
Re: DMX512 controller software
« Reply #6 on: December 29, 2024, 04:49:48 pm »
Indeed, many (if not most) of the MCU/FPGA programmers are using a FTDI, same, you can find FTDI chips on a lot of devboards you might already have around.

If you are using ready made DMX hardware, you'll also need a TTL to RS485 chip and some XLR connectors.  The 485 chips proved to be much harder to find in my case (I was looking that day to brick and mortar shops only, to finish the interface the same day).  Eventually found two SN75175 https://www.ti.com/lit/ds/symlink/sn75175.pdf, they are between the FTDI chip and the DMX bus.

if you're just messing about, you can avoid the need for an RS485 transceiver - just disconnect any terminators, connect the TTL UART TXD to D+ and bias D- to 2.5v with a couple of resistors
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 
The following users thanked this post: RoGeorge

Offline John B

  • Frequent Contributor
  • **
  • Posts: 881
  • Country: au
Re: DMX512 controller software
« Reply #7 on: December 29, 2024, 07:37:09 pm »
I use QLC+ with an ENTTEC USB DMX adapter. They're on amazon for a quite low price. Obviously you could build a prototype pcb for cheaper, there's not much too them.
 

Online themadhippy

  • Super Contributor
  • ***
  • Posts: 3318
  • Country: gb
Re: DMX512 controller software
« Reply #8 on: December 30, 2024, 01:19:25 am »
One thing to watch if using the entec open adapter is you may get the occasional flicker from your rig,from memory i believe its due to not having a buffer to hold the full dmx frame and instead relies on the computer to do all the hard work.
 

Offline John B

  • Frequent Contributor
  • **
  • Posts: 881
  • Country: au
Re: DMX512 controller software
« Reply #9 on: December 30, 2024, 07:46:32 am »
That is correct, in which case they also offer a pro version which has an internal buffer. However I've used the simple one in professional installations without issue, all on 10+ year old computers.

Either way it's worth picking up the simple one even as a piece of test equipment. It's handy to have in the toolbox if you do any work with DMX equipment. You can load QLC on your laptop and troubleshoot or test equipment easily.
« Last Edit: December 30, 2024, 07:51:15 am by John B »
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7085
  • Country: ro
Re: DMX512 controller software
« Reply #10 on: December 30, 2024, 09:42:06 am »
Which free software would be easier to use for a very small installation (a few holiday lights at home), QLC or FreeStyler?

Offline John B

  • Frequent Contributor
  • **
  • Posts: 881
  • Country: au
Re: DMX512 controller software
« Reply #11 on: December 30, 2024, 09:33:51 pm »
Never used freestyler, but can definitely recommend QLC.

For a permanently online, always active system (ie not a traditional theatre or event setting) you could install linux on the cheapest NUC. Apparently they did port QLC over to the RPi, but they ask for a donation to use it since it was such a big job. Either way I would probably stick to x86 for compatibility. I had some issues trying to get the ENTTEC adapter to work on Debian, but it worked right out of the box on Arch.

The next step would be how you interface QLC to external systems. It has a bunch of theatre and pro AV based protocols, but also uses some common ones like Open Sound Control, giving you the option to control QLC over your local network. You say it's a home install, so I'm sure you could bridge it to home assistant et al if that's your thing. Probably an OSC to MQTT python script.
 

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7085
  • Country: ro
Re: DMX512 controller software
« Reply #12 on: December 30, 2024, 10:00:15 pm »
Main use case for me would be 3-5 DMX dimmers light bulbs, each of a different color, that are controlled in the rhythm of whatever musing is playing at the moment on a Linux (Ubuntu) desktop.

Another winter holiday use for me would be "flowing lights":  3-5 interleaved strings of lights, successively turning on/off, to give the impression of "running lights" on a string of LEDs in the balcony windows.

Offline John B

  • Frequent Contributor
  • **
  • Posts: 881
  • Country: au
Re: DMX512 controller software
« Reply #13 on: December 31, 2024, 05:03:40 am »
QLC has a matrix function that you might like. Basically you program in DMX lights as "pixels" in an array, then QLC handles the complex sets of values that give the effect of patterns. There's a bunch of pre made ones like waterfall effect, left to right or vice versa. It is an easy alternative to manually creating complex chasers made of scenes, which essentially becomes stop motion animation (ie tedious)

You can also use an audio input as a control signal.
 
The following users thanked this post: RoGeorge

Online darkspr1te

  • Frequent Contributor
  • **
  • Posts: 381
  • Country: zm
Re: DMX512 controller software
« Reply #14 on: December 31, 2024, 08:53:49 am »
I also recommend QLC+, in fact I run it on a raspi 3b /7inch touch lcd and a generic rs485 ftdi adapter from amazon, it works fantastic and supports a lot of fixtures and setting up new fixtures is easy.


bonus is qlc also supports artnet and Open Sound to light protocols so support for external controls are there, as a example I control qlc via Virtualdj 2024 over the open sound to light via lan cable(to the pi) , that then controls a wifi to dmx box over artnet(esp32 and a rs485 transceiver, code on github).




with this setup I am able to have lights in front of my DJ booth and lights at the back of the venue without trailing dmx/power cable across the public area.


At first QLC might seem daunting with all the scenes/protocols/pages/controls and DMX numbers but there are some very good guides on the QLC forums and raspi forums. Here too.


One tip, Fixtures files is just a list of what BANDS of dmx channels a light (or anything else) covers in the available 512 channels with a icon attached for easy reading.
a example is a RGB pan light which lets say has 8 channels used (dmx 0-7) 0 is RED brightness, 1 green bright , 2 blue, 3 modes (sound activate, trigger mode ,pulse etc) 4-7 would cover the flashing modes of each channel plus brightness, this means your next fixture can use dmx 8(if you wish to control a new fixture separate) .
If you dont know what channel does what then set each device to zero and plug one in at a time, then use QLC dmx slider page to trigger each channel from 0 to what ever it stops responding to , also note some devices might have a over all brightness control on a higher number so you might raise red to max and get nothing then drop red and max blue but again nothing, this is because the total brightness control (also known as blackout value) is set to zero.


once you have a fixture added you then goto pages, new page and then drag drop a control for your new fixtures functions , example slider for red and brightness and then assign dmx 0 to one slider and dmx 7 to the other and once you drag both up your light will go red. other options like buttons fox example can be assigned to a DMX channel , eg DMX7 and then between states (on/off) can send preset DMX value based on state eg off DMX7=0, on DMX7=255 this turns that button into a blackout button.


Scenes are just pre-recorded states of the DMX channels , a example would be if you had pan/tilt lights and wanted to shine them on the center mic using all colours at max you would goto the page you created or the DMX slider page and set the light to where you wanted them and what state then goto scene's and create new scene , then you move your light to the new positions and colour and save a new scene. once you have multiple scenes you can insert behaviors between on how it transitions between each scene , example you be slow or fast or jump to another scene and come back, it's quite flexible.


hope that helps,


darkspr1te 
 
The following users thanked this post: RoGeorge

Offline HwAoRrDkTopic starter

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: gb
Re: DMX512 controller software
« Reply #15 on: December 31, 2024, 03:38:57 pm »
I've been messing around with QLC+, and it's doing the job, but I've come across some funny behaviour that seems to be a bug in QLC+, or maybe something else, I'm not sure.

If change the output frame frequency setting on the "DMX USB" adapter to something lower than the default 30 Hz, e.g. to 20 Hz, it makes the break and mark-after-break (MAB) periods excessively long. Like, it goes from ~10 us and ~145 us for break and MAB to ~15 and ~16 milliseconds. It also doesn't actually hit exactly 20 Hz, but more like 16 Hz. See logic analyser trace below:



But then things get weirder. If I then set the output frame frequency higher again, e.g. back to 30 Hz, the break and MAB length doesn't change, but it seems the overall frame interval does, resulting in frames being incomplete (i.e. < 512 slots) because they are cut off by the break of the next frame, which occurs with absolutely zero mark-before-break (MBB) time. Sometimes cut off even part way through a slot byte (e.g. the stop bits are interrupted)!



I'm not sure whether this is a bug in QLC+, something funny with FTDI drivers, or maybe the FT2232 itself.

This smells to me like software-generated break periods... But surely they would be making the FTDI chip generate the breaks itself, and so they'd be of fixed length relative to the baud rate? I dunno, I'm not familiar with FTDI chips.

Anyway, note to self: don't mess with the frame rate. ;D
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 14131
  • Country: gb
    • Mike's Electric Stuff
Re: DMX512 controller software
« Reply #16 on: December 31, 2024, 03:58:24 pm »
A problem with doing DMX on the FTDI chips, whether using explicit breaks or changing to a lower baudrate and sending a 00 byte, is the buffering that the FTDI driver does. There are some parameters in the advanced driver settings ( if using COM emulation) or API ( for D2XX) that may need fiddling with to optimise things.
It's a while since I did it but ISTR it's hard/impossible for the host software to detect when a break has finished being sent, so arbitary delays are needed, and the buffering can mess this up. I also have a vague recollection that breaks don't get buffered in the same way as data, and it's difficult to get a predictable MAB time, though I would expect many DMX peripherals may not care too much about the latter.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline HwAoRrDkTopic starter

  • Super Contributor
  • ***
  • Posts: 1619
  • Country: gb
Re: DMX512 controller software
« Reply #17 on: December 31, 2024, 08:15:50 pm »
I've been doing some poking around in the QLC+ source code, and I'm mystified as to how such a bug is even possible. :-//

It uses - on Windows at least - the FTDI D2XX API/library, and that library has FT_SetBreakOn and FT_SetBreakOff functions. So, no inherent timing - that is up to the caller how long the break period is. Each USB interface type seems to implement a run method that is basically just an infinite loop with delays for timing. The interface that appears to be being used in my case is EnttecDMXUSBOpen (that seems to be the one corresponding to "Open TX" that was auto-detected), and this class's 'run' loop is just this:

Code: [Select]
#define DMX_MAB 16
#define DMX_BREAK 110

// ...

while (m_running == true)
    {
        // Measure how much time passes during these calls
        time.restart();

        if (iface()->setBreak(true) == false)
            goto framesleep;

        if (m_granularity == Good)
            usleep(DMX_BREAK);

        if (iface()->setBreak(false) == false)
            goto framesleep;

        if (m_granularity == Good)
            usleep(DMX_MAB);

        if (iface()->write(m_outputLines[0].m_universeData) == false)
            goto framesleep;

framesleep:
        // Sleep for the remainder of the DMX frame time
        if (m_granularity == Good)
            while (time.elapsed() < (m_frameTimeUs / 1000)) { usleep(1000); }
        else
            while (time.elapsed() < (m_frameTimeUs / 1000)) { /* Busy sleep */ }
    }

I can't imagine what kind of craziness would cause a simple usleep call to morph a hard-coded microseconds period into dozens of milliseconds. Perhaps somehow the fault is in FTDI's library calls (i.e. FT_SetBreakOn/FT_SetBreakOff) introducing the delay. And also puzzling is how the 'correct' observed break and MAB periods are almost the opposite (i.e. longer MAB than break) to the code values.

I might try updating the FTDI drivers on my system. But QLC+ bundles a specific version of the ftd2xx64.dll, so if the problem is in the library, that won't fix anything...

Edit: The Qt docs for usleep method of the QThread class - from which every QLC+ USB interface class inherits - gives note (emphasis added):

Quote
Note: This function does not guarantee accuracy. The application may sleep longer than usecs under heavy load conditions. Some OSes might round usecs up to 10 ms or 15 ms; on Windows, it will be rounded up to a multiple of 1 ms.

:palm: :palm: :palm:
« Last Edit: December 31, 2024, 08:29:42 pm by HwAoRrDk »
 
The following users thanked this post: RoGeorge

Online RoGeorge

  • Super Contributor
  • ***
  • Posts: 7085
  • Country: ro
Re: DMX512 controller software
« Reply #18 on: January 01, 2025, 07:37:02 am »
Interesting finding, I didn't know there were such problem with DMX.  Did you measured only out of curiosity, or did you measured because your DMX lights were misfiring?

what kind of craziness would cause a simple usleep call to morph a hard-coded microseconds period into dozens of milliseconds

I would suspect the task scheduler might cause that, but I don't really know how the Windows task scheduler works.  Does the task scheduler wakes up a paused thread when a timing loop expires, or is the thread inactive until its next time slice takes place?  If you still have the measuring setup on the desk, would be interesting to see if the timing degrades even more when the CPU is busy with other heavy task while sending the same DMX sequence you measured before, or by altering the process priority.

Another thing I would suspect would be that the high resolution timer is disabled (I think it was called HPET - High Precision Event Timer, not sure if there are other high resolution timers, too).  Vaguely remember about some security exploits from a few years ago, were the malicious code was able to deduce what other tasks are doing by fine measuring the time it takes do count in a loop, and thus deducing what other parallel tasks were doing.  HPET is a hardware feature that was added long after the IBM-PC standard, back then the RTC tick was 18Hz or so (again vaguely remember the number, didn't double check).  Anyway, when the HPET kind of exploits were first discovered, the mitigation was to disable fine timing.  Don't know if better mitigation techniques were find meanwhile.

Yet another issue I remember, in the past there were big issues with sub ms timings in Windows, in some industrial SCADA software we were using a special (and proprietary Windows patch/driver to overcome that, but that was 10-20 years ago, and IIRC, that was before the hardware high resolution timers were introduced).  I don't know for Windows, but for Linux there are special patches for kernel, to minimize the timing jitter (I'm thinking RTLinux, but I don't know the details).
« Last Edit: January 01, 2025, 08:05:25 am by RoGeorge »
 

Online themadhippy

  • Super Contributor
  • ***
  • Posts: 3318
  • Country: gb
Re: DMX512 controller software
« Reply #19 on: January 01, 2025, 08:00:16 am »
Quote
is EnttecDMXUSBOpen
As i mentioned above the entec open is known to cause issues,often seen as the rig flickering,the easiest cure is to buy a better adapter or for not much more than the entec open box you could get a full  chamsys dongle >:D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf