DMX "burp"

[woody74]

From the "maybe it's me" category...

 

I primarily use an ETC Express with theatre jobs, and about once every 15 power-offs, the board will "burp out" DMX and send one or a couple of dimmers to full. This happens regardless of the position of the Grand Master. Am I the only one? Does anyone have an explanation?

 

Cheers,

-w

[pete LD]

is it always the same dimmers? have you got a demux or anything that can remember things on power loss?

just an idea?

pete

[Ian]

From the "maybe it's me" category...

 

I primarily use an ETC Express with theatre jobs, and about once every 15 power-offs, the board will "burp out" DMX and send one or a couple of dimmers to full. This happens regardless of the position of the Grand Master. Am I the only one? Does anyone have an explanation?

 

Cheers,

-w

 

 

We get this occasionally with our Strand SLD 96 dimmers. We are a touring house and as such have a lot of different desks through, and this happens intermittently with any desk, both running on cat 5 or DMX. With us its always dimmers in the 77 >> 90 range, why just these dimmers Strand can't explain.

 

Ian

[si_cole]

I've had that years ago with a Sirius 48 and it was all channels. The only way I combated it was by powering off the dimmers first.

 

Si

[woody74]

is it always the same dimmers? have you got a demux or anything that can remember things on power loss?

just an idea?

pete

 

As far as I can tell, it's random. And it's a straight DMX run from the console to the dimmers. And to si_cole's point, unfortunately we don't have the option of powering down the dimmers before the console (well, we do, but it involves a key and a hallway with a breaker box).

[peter]

I've seen this several times in the past, and always attributed it to the desk being powered down in the middle of a DMX 'cycle' to which the dimmers misread and determine it as a correct command when infact its a mid-cycle command. Bizarrely I've seen this on desks like the 520 where the DMX-output system is shut down in software before the desk is powered off.

 

One potential solution would be to have some form of DMX device which you could cross-plug into the dimmers quickly at the end of the day which sends a 0,0,0,0... anything which outputs DMX should do... a debug, smaller desk, etc.

[jfitzpat]

There is no error checking in DMX packets. Pretty much, marker, one byte, here is the data...

 

If you just kill power to a DMX source, instead of going through some sort of shut down procedure, you don't know where in a packet you will be killing power to the physical UART. Depending on the actual circuit, it wouldn't be surprising to get some gibberish. Without any form of error checking, the dimmers can't tell good data from bad and will sometimes flash. Then, typically, stay on at the bad value until the 'no DMX data' timeout occurs.

 

-jjf

[Martin]

I've had this before with our 520, but our dimmers are D54, so it's not just a DMX thing. Hasn't happened in a while though.

[woody74]

One potential solution would be to have some form of DMX device which you could cross-plug into the dimmers quickly at the end of the day which sends a 0,0,0,0... anything which outputs DMX should do... a debug, smaller desk, etc.

 

So, even if all faders are cleared and zeroed (essentially sitting at total zero), I'd actually need to send a 0 cue to the dimmers? And wouldn't the master at 0 be a signal, and if so, why would it still happen? Seems like something inherent with DMX packeting (it has also happened with my Virtuoso DX and an NSI 7532)

[peter]

Basically, the problem relates to when a DMX transmitting device stops transmitting. Lets say for arguments sake the DMX packet it is transmitting is a 1,0,1,1,0,1,1... the numbers are irrelevant. Anyway, if the transmission is stopped mid-flow, or interrupted, the packet is corrupted. Because of the nature of DMX signals (essentially just a bunch of numbers separated by stop bits), the dimmers interpret the corrupted data as good data, but incorrect data. They may receive the 1,0,1,1, then the data may stop. Instead of ignoring the packet, the dimmers see the erroneous data and interpret it in their own way. It seems that most dimmers tend to accept the error-ed packet as a good packet and therefore listen to that control signal. Because this has happened on DMX-fail, the dimmers will generally hold that data until they receive more good data, or the dimmers themselves are powered down.

 

For this reason, it doesn't matter what the console is doing at the time of power-down, but rather what frame of DMX is being transmitted at the time. If you happen to be mid-flow, and the dimmers recieve an errored packet, you're going to get channels on. Adding error checking to the standard would improve this, but would involved re-writing the entire DMX standard.

 

Hope this explains things a bit better.

[woody74]

Basically, the problem relates to when a DMX transmitting device stops transmitting...

...Hope this explains things a bit better.

 

That helps; thank you. One more question (and I think I already know the answer): do most devices send DMX all the time, regardless of if it contains a "command"?

[TommyToad]

Yes, at a specified rate.

[David Buffham]

We've experienced this situation quite a lot, but so far have only seen it with Strand dimmers, never ETC or Zero 88. My worst experience was at the old Wimbledon Theatre a couple of years ago where they had EC90 dimmers and it took three or four attempts each night to power off the console without any dimmers popping back on.

 

So it would be interesting to know whether other people who have seen this problem are using specific makes of dimmer, e.g. Strand, or whether it is across all manufacturers. I agree with Peter that it seems to be down to the DMX receiver's handling of incomplete packets, so it could be specific to individual manufacturer's implementation of their DMX input systems. Although I see it with dimmers quite frequently, I've not yet seen anything like this happen to moving lights or LED fixtures. e.g. I've never encountered any random movement of lights or LED cells coming back on when powering down the console.

 

I've also seen LD90 dimmers randomly come on just by unplugging the DMX cable, so I am sure that it isn't console related.

[Barney]

I've seen similar problems with spurious DMX being sent as a desk is shut down or powered off.

 

The easiest solution is to bring your grand master down to zero, then remove the DMX cable from the rear of the desk before powering down.

 

Just remember to plug the DMX back in before you use the desk again :)

[Glyn Edwards]

We've had the same problem here in Coventry with both a 520 and a Compulite Ovation, both running Compulite dimmers. It does appear to be random when it happens nor does it affect a a certain dimmer.

The solution we came up with was to turn all the DMX holding off on the racks and fit an Artistic Licence Cue-Patch in the control room. This provides back up for 2 universes, as well as solving the interesting dimmer patching our building requires!