Ion sends stray DMX signal at power down

BRosen

Member
Hey y'all

i've come across this problem a few times now.

When our Ion powers down, it sends a stray DMX signal to the dimmers which causes random lights to pop on at Full. With most dimmers its no big deal, and they turn off after a certain period of time without signal, but ours don't do that, so the only way to work around this problem is by unplugging the DMX on power down, which gets annoying. anyone experienced this/found a solution?
 
The theatre I work at which has an Ion generally leaves their console on 24/7 during tech, so I don't encounter this situation very often. But I have had the same problem - at least 75% of the time when shutting down the console, a random channel would pop on during shutdown and we just had to wait until the lack of DMX signal caused the dimmers to bring it down. I'd also be interested in hearing a solution.
 
What is your dimmer situation and how are you interfacing your dimmers?

I have had this using on Strand Shownet nodes outputing DMX. When the console shuts down (either with a 520i or with MagicQ) at least one dimmer will be take to full when the node powers down. I have never had this issue with going straight out of the console with DMX into the dimmers.
 
I'm having the same problem with my Element and I was actually considering calling ETC in the next week or two as it's starting to annoy me when 8 out of 10 times I shut down I get a random light jumping to full that then fades out with anything else I'd left on after the dimmer rack's memory feature releases everything. It's not a big deal but it's like a pet peeve that annoys me everytime it happens.
 
while i appreciate that link, the last post on it was from 2008, and mostly people complaining about a lot of ETC boards doing this occasionally... the last post talks about the ION doing it every single shutdown, always at full... in 2 years, im wondering if this has been addressed yet.
 
I think Derek might have linked you to that post because it was addressed, albeit not so much in a positive way. David North, ETC Technical Service Manager, explained in the ninth post that there isn't really anything you can do about it. It is simply the nature of DMX. When everything shifts to ACN (I'm still crossing my fingers) this problem should go away because, unlike with DMX, data isn't constantly being sent.

Sorry
 
By any chance do you have any Unison button or fader stations linked into your racks?
 
This happened to my old school with a Congo Jr.

They turned the board on and off several times until everything shut off, but it was very annoying. I don't think they ever fixed it.
 
Hey y'all

i've come across this problem a few times now.

When our Ion powers down, it sends a stray DMX signal to the dimmers which causes random lights to pop on at Full. With most dimmers its no big deal, and they turn off after a certain period of time without signal, but ours don't do that, so the only way to work around this problem is by unplugging the DMX on power down, which gets annoying. anyone experienced this/found a solution?

This unfortunately occurs on several products that have both a power switch and transmit DMX.
When consoles are powered down there is a brief amount of time where the DMX is still being transmitted yet the power supply is running down. This may corrupt part of a DMX packet which is recieved and then latched by the racks.

...David North, ETC Technical Service Manager, explained in the ninth post that there isn't really anything you can do about it. It is simply the nature of DMX. When everything shifts to ACN (I'm still crossing my fingers) this problem should go away because, unlike with DMX, data isn't constantly being sent....

xander hit the nail right on the head. There just isn't a great solution without putting another device downstream of the console to interpret and weed out a corrupt signal.

If possible, I would adjust your dimmer's hold last look time. If it is an ETC rack, it sounds like it is currently set to Forever. Common in many places (and default in our racks) is 180 seconds (3min).

Studio's idea would work as well (because it is a device down stream of the console) but you may need to play an all-on preset then an all-off preset for the unit to take control as it is a "vampire" tap on the DMX line instead of processing the DMX going through it and retransmitting.
 
... take control as it is a "vampire" tap on the DMX line instead of processing the DMX going through it and retransmitting.


VERY interesting terminology, glad I read everything up to this point! (My neck was getting rather tingly.)
 
You'll have to excuse me if I missed this seeing as how I just recently finished driving 22 hours back from Kansas City, but what software version are you using with your console?

It could be an issue with your particular setup that has been addressed by ETC in a later update. Speaking of which, they released a great new update (1.9) just a few hours ago!
 
Studio's idea would work as well (because it is a device down stream of the console) but you may need to play an all-on preset then an all-off preset for the unit to take control as it is a "vampire" tap on the DMX line instead of processing the DMX going through it and retransmitting.

This unit only vampire taps when you are setting presets. It takes control of the DMX signal after the console shuts down. It will even tell you when the console is in control or when it is in control. The reason why l like this is because our previous "Vista Panel" System caused a ton of troubles. It even does a nice fade from what was on on the console to the preset that was selected before the console takes control. Very seamless.
 
This issue has been around for as long as DMX has. Anything that transmits DMX and has a power on/off switch (that is, a physical switch that connects/disconnects the transmitter's power supply) is, by definition, capable of cutting power during transmission of a DMX packet. At the moment of power loss, the receiver at the other end of the line has been happily reading in, serially, each dimmer byte (or slot/frame for the terminally terminological out there) and the next few bytes before total data loss are garbled but apparently still readable enough that the receiver will process them as valid data. Cycling power again will cause the disruption to occur somewhere else in the packet stream, and with luck it will happen in the idle time between packets, or at least in the higher number range where you might not have any receivers addressed (Murphy being alive and well in the theatre environment, you know what'll usually happen).

With ETC desks, you can test this by (temporarily) changing the DMX "speed" setting to slow, which will result in much longer idle times between packets and a corresponding lower likelihood of dimmers stuck on.

True, some inline DMX processors have the ability to reject the faulty packet, but you may not want the slight delay they introduce while they check each packet for errors before passing it through. The delay can be minimized, however, by setting the board's DMX speed to maximum (44Hz), and if all you're running are dimmers, scrollers and movers, you won't notice the delay. LED systems could be a problem, though.

Running Ethernet out of the console (and using Ethernet-DMX nodes) solves the problem because of Ethernet's built-in rejection of bad packets. The only other option you have is to set the DMX signal loss hold time on your dimmers or other gear to zero or near-zero.

And for the guy I know who said he'd try watching the DMX on a scope and see if he could shut off the console between packets, I'm still waiting to hear how that worked out!:rolleyes:
 
I've had an Ion in our space for over 3 yrs now [we got one of the first ones off the shelves], and have had this problem since day one. We've just put it as part of our shut-down process to unplug the DMX from the board before fully shutting down.

We've tried everything to get around it, including installing all the updates [currently running the newest 1.9]. It just seems like one of those facts of life that boards run into in general.

I saw somewhere on here that someone had mentioned the idea of DMX consoles spitting out that jargled last spit of DMX before turning off. I believe [and totally correct me if I'm wrong] that it has to do with the overall DMX signal being stopped, and that if the stream of DMX is halted mid-stream, the addresses [in simple terms] get confused, and don't quite know how to handle it. I agree that a processor downstream would be able to handle this information better.

However, the simpler/cheaper option is just to unplug the DMX before fully shutting down the console.
 
In a console, you have some sort of microprocessor outputting DMX data as a TTL signal. That TTL stream is fed to an RS485 transceiver (like the Max485, 1487, etc), which converts the TTL voltage levels to RS485 voltage levels used in DMX signaling (it has zero effect on an other aspect of the signal). When you cut off power to the console, the power supply voltage will wind down as its filter capacitors discharge, and when the supply voltage drops to a certain level the TTL stream can become unstable, and turn into 'garbage'. The transceiver, however, may still continue to translate voltage levels until the supply voltage drops further and it shuts down completely--in the intervening time, the transceiver dutifully converts the TTL garbage to RS485 garbage, and sends it on down the DMX line, and any receiving devices will respond to whatever ones and zeros they receive as best they can. In practice, this can lead to stuck channels like the OP is suffering.

There are a couple ways to address this problem. One is to enforce an ordered shutdown of the console: where a 'soft' power button is provided that tells the microprocessor to initiate a shutdown sequence that has it complete the current DMX packet, and then during the break between packets switch the RS485 into high impedance or receive mode, then tristate its own UART pins (with pulldown resistors on the transceiver's input pins to hold them low). Those steps should keep the DMX output stable as supply voltage drops, and the microprocessor can then tell the power supply to shut down (much like how a modern computer works).

On the other end of things, this would be entirely a non-issue if the DMX protocol incorporated even rudimentary error checking. If it were mandated that receiving devices verify a checksum against each packet before acting on any data received, then any garbled/corrupted data would be simply rejected. This would also go a long way to help with issues caused by cable/termination problems, since it would be very easy to verify a problem with the data itself as opposed to, say, a dying dimmer. As it is now, a receiving device has no way of knowing whether the actual ones and zeroes it is receiving are the same ones and zeros the console intended for it to receive.
 

Users who are viewing this thread

Back