DMX Signal, but lights not responding?

[coofercat]

Hi all,

I think I'm missing something obvious, but after a couple of days of hacking about, I can't figure it out. Any help would be appreciated. The frustrating thing is that this *has* worked in the past, but I can't get it working now.

I have a Mac laptop, running Mojave, an Entec OpenDMX USB device and a Chauvet Swarm 5FX. I've downloaded the latest (and a few older versions) of QLC+, and have run it up. It sees the Entec device as a "DMX USB" plugin, and identifies it as "FT232R USB UART (S/N: A6008XE5)". It says it's using libFTDI, and says it's working properly and that the system timing is good. It's automatically patched this to Universe 1. As soon as QLC+ loads, I see the Chauvet's status display stop blinking and turn solid, and I see a little LED on it blinking slowly. This looks like I have DMX signal. If I stick the multimeter in logic mode and put it on the DMX data pins, it 'buzzes' when QLC is running, and shows a static logic level when it's not - again, this looks like DMX signal.

Next, I head over to Fixtures and add the Chauvet Swarm 5FX. I'm then going to Simple Desk and clicking on one of the icons above the 9 sliders on the left. I then pick something off the pop-up menu. Sadly, nothing seems to happen. I've tried pressing a few more things in QLC, but so far have not managed to get the light to actually respond.

I've tried unloading the Apple FTDI driver (sudo kextunload -b com.apple.driver.AppleUSBFTDI), and the first time I run this it does something, the next times it just says it can't unload the driver. I've tried doing this immediately after a fresh reboot before and after plugging in the Entec device. With the driver unloaded, no /dev/tty* device appears when I plug in the Entect device (with the driver loaded, I see a /dev/tty.usbserial-A6008XE5 entry).

As I say, this whole hardware chain has worked in the past (like maybe a few months back - I think before I got Mojave). It feels like QLC isn't actually sending any messages to the light, or else is doing so in a way that the light can't understand. I can't find a way to 'sniff' the DMX signal to verify that though.

Any help getting this thing going would be most welcome - it's been driving me a bit nuts (and making my wife wonder what I'm doing - as I could just be taking it easy over the festive holidays). Hopefully someone's just going to say "oh, you need to click the 'make it work' button on the left" or some such, or maybe I have another problem...?

[edogawa]

Don't you have other DMX gear to test with on that universe?

Did you check for obvious logical errors: do the sending/receiving DMX addresses match(e.g. off by one error), did you set the correct mode for the chauvet fixture both on the unit and in QLC, etc. ?

For testing you could also add an appropriate range of dimmer channels instead using the fixture definition, that would hide the fixture complexity and show plain intensity channels but possibly help in finding out what happens... I'd trust the blinking on the unit and assume the DMX signal is arriving.

[coofercat]

Thanks for that - very sensible and helpful advice.

I said this was going to be something obvious, and sure enough, it was PEBKAC. Channel 1 on the Chauvet can be used to set which 'mode' it's in (auto1, auto1, sound1, sound2 etc). One of those modes is 'dmx'. Thus, for the Chauvet to respond to DMX signalling, you have to physically switch it into DMX mode on the unit (ie. make the display say something like 'd001'), and also be sending anything between 220-255 on channel 1 as well (to say "go into DMX mode). Then, if you do something in channels 2-9, it'll actually respond. Doh!

For anyone with more DMX equipment than me - is this sort of thing common?

Whilst I'm now wondering about my fading technical skill (!), I have done some other stuff along the way. I've 'sniffed' the DMX string with an RS485-USB device, and read the bytes out with a bit of Python. I've see the 513 byte packets, and seen QLC altering values in them. All that could be handy as I try to build out some sort of 'control server' for my Chauvet and some pixel strips I plan on putting in to my kitchen

Thanks for the help - and sorry it was 'user error' all along.

[edogawa]

Working mainly in theater, I haven't ever encountered such behaviour before with moving lights, but that doesn't mean much... the market changes a lot and new kinds of capabilities show up with new models.

All I can say - during the last 2 years or so looked at quite some cheap chinese and some not so cheap old and new (VariLite, Martin, Robe ...) fixtures and have written QLC fixture definitions for some of them. None of them had a channel to activate DMX control mode explicitely, or at least I don't remember.

It is common though to have some sort of Macro/Effect channel that overrides/deactivates direct access to RGB and dimmer channels, for example.

[coofercat]

Thanks for that - again, very helpful.

I was surprised to need to say "use DMX" over DMX itself, but as the same channel can select the various "auto" modes, I suppose it's not too much of a reach to need to do this.

Thanks again for your help - very much appreciated

[GGGss]

That behaviour comes because you have a multi capable fixture.
(The saved on the numbers of DMX channels vs capabilities)

Peeking in the manual, I predict you will have some issues setting the right colour (since they are combined in one DMX channel f.i.)
This fixture will even be a nifty one to get the fixture profile in good shape...

[coofercat]

Happy new year!

Thanks for that - I get the feeling it's an 'entry level' sort of thing. I'm only using it in my kitchen for after-dinner discos with the kids, so the exact colour isn't really a problem for me

I hadn't thought of fiddling with the fixture profile - I've got some other stuff to do first (most notably getting a suitable controller in place), but then will have some scene making to do, so will have a look at the profile and see if I can do anything with it.