Dealing with glitchy(?) pan/tilt fixture

[omegahacker]

I've spent today chasing down various problems, the most recent being that the SHEHDS moving lights we bought seem to have major problems doing short movements over moderate periods.

I have two scenes with nearby positions, approximately ~600 "ticks" apart along the 16-bit pan axis. When I put the two scenes into a chaser with fade times between 2 and 5 seconds (so far, I've got more experimentation to do), the fixture will glitch backwards 1-2 times during traversal. I have a more complex chase where the light goes from A to B, then other stuff happens, then back to A, and the direction in which the light jitters can vary depending on the situation...

Knowing that 16-bit support has recently been updated (4.13), my first thought was some kind of bug where the coarse value might be out of sync with the fine, but I verified that the DMX values are in fact completely correct, using Wireshark to capture USB packets going to my Enttec Open DMX USB. I also isolated a single fixture with a direct shot from the converter to the light and nothing else on the bus, to no effect. That pretty much means that the problem is at the fixture itself.

So my question is, has anybody else run into this with any lights? I've emailed SHEHDS but they're on national holiday for the next 3 days... I've tried a few things like putting a linear transform on the fine channel to restrict it to e.g. 5-250 in the hopes that 0 or 255 somehow triggered an edge case, though I didn't confirm the exact values going over DMX in that particular scenario yet. I don't seem to be able to set the channel range within the fixture definition, because that would make the channel "Custom" rather than "Pan (fine)", so I don't think there's any other way to make QLC recognize pan as 16-bit.

I started doing some experiments with different movement ranges, and generally speaking a much larger move at a higher speed doesn't seem to result in any issues, but I've got a lot more experiments to do because I need to try to narrow down exactly what situations cause the problem so we can try to design lighting to avoid them...

Anybody have any other ideas here?

Thanks!

[janosvitok]

Some moving heads have position feedback. If motor turns the head more than desired, the position feedback detects it, and sends command to the motor to turn a bit back, until the position is OK.

You may try to disable the position feedback in menu on the fixture to see if the glitches go away. Note that feedback turned off may cause the fixture to lose precision (it may aim somewhere else than desired).

You may try to clean the position feedback system (I won't tell you how) - some are based on optical reading of encoding wheel (e.g. position of holes encodes position of the head).

Jano

[GGGss]

Or since the OP is using the open DMX interface, the movers miss some in-between DMX packets and jump to the next valid one...
I helped develop and debug the 16b mechanism and with 4.13 it is dead on ... https://youtube.com/shorts/icjNFNl505Q so there is another problem somewhere...

[omegahacker]

Or since the OP is using the open DMX interface, the movers miss some in-between DMX packets and jump to the next valid one...
I helped develop and debug the 16b mechanism and with 4.13 it is dead on ... https://youtube.com/shorts/icjNFNl505Q so there is another problem somewhere...

I confirmed that the DMX values at least are correct exiting QLC (as they traverse the USB stack on their way to the DMX interface), so I agree that the 16-bit code is dead on. I'm not sure how missing a DMX packet is going to cause this issue however, as the DMX values are strictly monotonic. One packet might have 148+250, the next 148+255, and the next 149+4 for a linear fade, but losing the middle packet doesn't make it no longer monotonic.

I have the tools to capture the DMX data as it is on the wire itself, though it'd take a fair bit of work to set up (either just my digital scope, or use a USB UART), and I'll do that if I need to to find out if anything is getting lost or mistranslated.

I'm seeing a lot of hate on the open DMX interface, but I'm not exactly sure why. I'm well versed in the FTDI chips and the USB stack, and I have used both extensively in designing electronics. The async API (D2XX) means that QLC is just dumping an array of bytes to the stack, and it goes out to the FTDI chip, which doesn't exactly have any problems with accurately transmitting bytes (if it did, FTDI wouldn't exist any more). The only thing I can think of that could be attributed to the use of the FTDI chip would be the generation of the break and MAB, which might require some more involved driver interaction and timing issues. Also something I should be able to verify with my scope if I need to.

I have access to a Chauvet sACN adapter, I can mess around with that as well to see if that makes a difference.

[GGGss]

Or since the OP is using the open DMX interface, the movers miss some in-between DMX packets and jump to the next valid one...
I helped develop and debug the 16b mechanism and with 4.13 it is dead on ... https://youtube.com/shorts/icjNFNl505Q so there is another problem somewhere...

I confirmed that the DMX values at least are correct exiting QLC (as they traverse the USB stack on their way to the DMX interface), so I agree that the 16-bit code is dead on. I'm not sure how missing a DMX packet is going to cause this issue however, as the DMX values are strictly monotonic. One packet might have 148+250, the next 148+255, and the next 149+4 for a linear fade, but losing the middle packet doesn't make it no longer monotonic.

I have the tools to capture the DMX data as it is on the wire itself, though it'd take a fair bit of work to set up (either just my digital scope, or use a USB UART), and I'll do that if I need to to find out if anything is getting lost or mistranslated.

I'm seeing a lot of hate on the open DMX interface, but I'm not exactly sure why. I'm well versed in the FTDI chips and the USB stack, and I have used both extensively in designing electronics. The async API (D2XX) means that QLC is just dumping an array of bytes to the stack, and it goes out to the FTDI chip, which doesn't exactly have any problems with accurately transmitting bytes (if it did, FTDI wouldn't exist any more). The only thing I can think of that could be attributed to the use of the FTDI chip would be the generation of the break and MAB, which might require some more involved driver interaction and timing issues. Also something I should be able to verify with my scope if I need to.

I have access to a Chauvet sACN adapter, I can mess around with that as well to see if that makes a difference.

Erik,
It's nice talking to someone who understands the stacks of commands in a DMX stream.
With the open interfaces, some users have seen a faulty interaction between their mouse movements and the FTDI output stream from the CPU. The fault here was the shared USB hub inside their computer. Switching from one USB port to another mostly solved the issues. So yeah, there is a hate-love affair going on. On the other hand, I've known some operators doing business in theatre, using solely the open interfaces without any hiccups.
If things are getting time-critical, for sure, the use and fade-ing movements on movers, it might be that the CPU serial stack gets overwhelmed and adds wait states to the QLC+ engine, explaining the unprecise timing that you are experiencing.
If you are interested, I've composed a DMX timing chart recording the measured values of all my interfaces. https://docs.google.com/spreadsheets/d/ ... sp=sharing

[janosvitok]

Note that at 50 Hz, each frame is 20 ms. At 33 Hz, the frame is 30 ms. Any resolution below these does not make sense.
(I'm not saying QLC+ should drift either, I'm saying that e.g. specifying fade of 2 ms can't work).

[janosvitok]

If you are interested, I've composed a DMX timing chart recording the measured values of all my interfaces. https://docs.google.com/spreadsheets/d/ ... sp=sharing

Can you please make it public?

Jano

[GGGss]

If you are interested, I've composed a DMX timing chart recording the measured values of all my interfaces. https://docs.google.com/spreadsheets/d/ ... sp=sharing

Can you please make it public?

Jano

Sorry, my bad - FIXED