DMX Lights not responding to Watchout's Art-Net Output

[Faab]

Hello,

I've got quite the puzzle in front of me with using Art-Net output from Watchout. I'm using a pair of Elation Color Chorus 24 lights, set in a single universe, in the same network/subnet as my Watchout cluster. When I try to send an Art-Net signal from Watchout, the lights do not respond to the signal. When I use LightKey on a MacBook in the same subnet, the lights work fine. When I use an Art-Net to DMX converter with Watchout, the lights work fine.

I grabbed two ArtDMX packets, one from Watchout, and the other from LightKey, to see what they do differently. Both are broadcasted ArtDMX packets, which are practically identical, apart from two differences. Below is a screenshot from the LightKey packet for reference. As you can see LightKey sends a Sequence byte, containing information about where it is in its sequence. It also sends data for a full DMX universes, 512 adresses, even if only 8 adresses are being used.

The Watchout packets don't use a Sequence byte (value is always 0), and only sends adresses that are defined in the Watchout Project's outputs. So instead of sending 512 adresses, it only sends, for example, the 8 adresses I have defined in my outputs. Could it be that my lights need this extra data to even acknowledge the signal being sent?

[jfk]

i am no expert, but could it be that particular lighting device considers any transmission not containing the full 512 addresses as a flawed transmission and ignores it? The standard does not require all addresses be transmitted. Yet sending the full range is the norm for most consoles, etc. WATCHOUT is the outlier.  Still, as you can see other devices deal with it.

Easy enough to check. Add a DMX Output in the same universe and set it to address 512. This forces WATCHOUT to transmit the entire range.

[Faab]

14 minutes ago, jfk said:

i am no expert, but could it be that particular lighting device considers any transmission not containing the full 512 addresses as a flawed transmission and ignores it? The standard does not require all addresses be transmitted. Yet sending the full range is the norm for most consoles, etc. WATCHOUT is the outlier.  Still, as you can see other devices deal with it.

Easy enough to check. Add a DMX Output in the same universe and set it to address 512. This forces WATCHOUT to transmit the entire range.

Very good suggestion, I didn't know the trick with adding an output set to address 512. However it didn't solve my issue, which leaves me to think that the empty Sequence byte might be the problem here.

[jfk]

26 minutes ago, Faab said:

Very good suggestion, I didn't know the trick with adding an output set to address 512. However it didn't solve my issue, which leaves me to think that the empty Sequence byte might be the problem here.

Understood, but that is a valid transmission and that device is not fully compliant with the standard if it is refusing to accept that Sequence byte.

[RBeddig]

Where did you grab the Art-Net data? On the WATCHOUT production computer?

And are you really sure that you're sending the data on the right universe?

I briefly checked the manual of LightKey. They start the addressing scheme from 1 while WATCHOUT starts the addressing scheme from 0.  So universe 1 in LightKey should be identical with universe 0 in WATCHOUT.

A good tool to check where data is sent too is Artnetominator  (https://www.lightjams.com/artnetominator/).

[jfk]

i am not sure if simply creating the DMX output at address 512 is enough. If its status does not change, it may still optimize out. Just to be sure, for the purpose of testing, create an aux timeline 2 seconds long with a DMX cue fade up 1 second, fade down 1 second, run it and loop it.

[wiesemann]

I had to work on a project that someone else had started (of course, never my fault..)  and DMX was not working correctly. It was set to 16 bit instead of 8… Who knows…