Lights turn on at shutdown

hello,

Many/most consoles create this for reasons well explained in the replies on this thread.

Get into the idea of turning off dimmers over-night, it's a good idea for lots of reasons.

Yeah, no.  We'll just suck it up and deal with the DMX stuff.  We're not throwing 5 sets of 400A breakers for the 5 Sensor racks every day, killing the house lights for all other users of the space, the janitor, etc.  I only gripe because the Obsession 600 Did. Not. Do. This.

The thread can end.

But I think this is a real issue...and I think it probably has a hardware solution (though it may be software.)  I believet it has to do with the DMX drivers not being disabled before being powered down, resulting is last minute crap being send down the DMX line.   It would be nice if the board in fact disabled the DMX drivers with all levels at 0 before fully powering down.  Maybe a few caps to hold the driver's power rails up a little longer than the enable line is active.

The fact is, customer don't like this "feature."  The simple solution is to disable the held levels at the dimmer rack.  Of course, not all dimmers allow that.  And some customers believe they "need" to have a hold-last-look just incase.....Also, there are installations that don't have the service size to bump all loads on at once....which can happen at power down.

So maybe we see a fix sometime soon?

Thats my 2.5 cents worth....

I go back to what David North states in another thread.  DMX continuously streams information down the cable.  On power down all consoles stop this stream.  When the data stream is disrupted mid stream it can sometimes cause dirty data which in turn will drive DMX levels up.  Think of it like blocking a stream with a log.  There is going to be a splash.  Where that splash happens depends on when you shut down the desk.  Things to try:  Bring down the grand master, enable black out, or manually select all the channels to 0.  This way if there is a splash there is a good chance it is a value of 0. 

I had the same problem with the combination of Expression 2X and Lepricon touring racks, but didn't really think anything of it since we shut the racks down at night.

Perhaps there could be some kind of 'hold last look' momentary override.  That way when you shut down, if you get a dirty packet, the lights would flash for a moment but not stay on, and you'd still have the safety net if DMX goes out durring a show.  That would be a pretty nifty thing for Unison, or the like, to be able to do.

I don't believe the dirtiness (I know I'm making someone grone...) of the DMX is in its content (i.e.the data is garbage), but rather it is in the electrical. Specifically, the rs485 driver loosing supply power while still sending data.  If the chip was disabled before power down, I would think that should stop the electrical dirtiness.

Now, as this applies to ION, i have no idea.  I do know that ION sends DMX when ever it is powered up...even when ION isn't running.

so now I'm up to 5 cents

Is this really a harder to solve problem than I thinking?

brucek said:

Is this really a harder to solve problem than I thinking?

Could be.  If the problem is that the rs485 driver is sending data up until the power is cut, what difference does it make at what point in the shutdown you power down the driver?  Wouldn't it still be chopping the power off in the middle of the datastream?  Also, how do you deploy a hardware fix to all of the systems already out there?

I've had this problem with several consoles.  It's not just an Ion problem, it's a DMX problem

Jeff, that function is already there.

You can set the "Hold Last Look" time anywhere between 1 second and several hours, followed by a fade-to-black over user-configurable time.

The default value for this is 3 minutes, after which they fade to black over 5 seconds.

Sure, you can set it to whatever you want, I was suggesting a momentary override.  Such that you could have it set to three minutes just in case disaster strikes, then when you're ready to shutdown, you push a button and the time setting goes from three minutes to zero minutes for a little while then goes back to three minutes.

I don't think fiddling with the racks will keep Nfarwell's scenic element from tripping (unless he's using a relay module).  Still, we all are using more and more devices that don't go through dimmer racks.  Nobody wants their DMX coffee makers and shock collars going off inadvertantly.

Surely its not ridiculous to hope that someone will find a more graceful way to shut the DMX stream off than throwing a log across it.   

HI all,

I haven't posted in a while but this topic looks like something I can dig in to....again.  That's not to be snide, it's just that this problem is indeed universal to all consoles and all dimmer racks, whether ETC or not, that have a last look hold function.  No doubt that the first thing to check on a system having this issue is proper DMX wiring and termination.  Yes, it worked with my old console so why should I check it.  Without getting into detail here, suffice it to say that differences in how DMX common is derived at a console can expose pre-existing wiring conditions.  We used to cover DMX shield with black heatshrink and that looks an awful lot like a black conductor for Data - in a dark building being installed.  We changed over to clear heatshrink years ago to reduce these errors.  Yes, check for proper termination too.

Oh yeah, we thought that Last Look Hold was such a cool feature because if for some reason a console hiccuped, a DMX cable got unplugged, or an elephant stepped on the console power cable and unplugged it during a show (yes, this did happen), the lights would stay on long enough for someone to fix the issue and get back online.  There are of course flaws with all of this.

Many times when DMX was lost, people were not paying attention or did not happen to notice an unplugged cable (or unplugged power cable to the console!) until the Last Look Hold expired and the lights went out anyway.  So much for preparing for the worst.

Indeed the issue is that as the console is powered down, the DMX chip is powered down as well (obvious, sorry) and since data is being sent continuously, the data gets corrupted.  The rack is doing its best to do what it is told and will latch that data because it is valid DMX, although not what you want to see.

I can tell you this discussion has been happening around here since before I arrived and that was over 15 years ago.  The real problem in solving this knowing what to do for shutdown, oh, and we don't know yet that it will work. 

Just as several of you have stated, dimmers and DMX both are being used for many more things than originally designed or intended (solenoids? cool!).  This causes complications.  Some people want DMX values to be sent to zero when they shut off a console, and some want the DMX values to not move from where they are.  Let me explain....

A number of facilities leave a few lights up on the console (houselights and a few works backstage), turn off the console and then as they exit the deck, the lights fade out about 3 minutes later.  Perfect for a small space with only a couple of people working in it and no houselight system.  It gets even more complicated when you start looking at moving light and scroller power, potentially, depending on how systems are setup and run.

I propose that we default the console to output a stream of zeros for a few DMX frames and then power down.  Optionally, you could select a function in the console setup that would instead continue to output currently set levels until power down.  I would like your opinions.  Again, we can't promise we can fix this but I can promise that we have been in talks about this for some months and will continue.

David-

I like the idea of outputting a stream of zeros for a few frames and then powering down, especially if this is a option that can be toggled on/off in the setup screen.  

I do have one question however, in regards to this problem.  With the increasing use of Ethernet as the primary control signal between consoles and new install dimmers/devices, aren't we less likely to see this DMX Death Gasp when consoles are turned off?

My understanding of the problem is that this little hiccup of levels is primarily associated with the DMX driver chips in the console, and that we likely wouldn't see this with networked control signal. Even a DMX Node/Gateway will default to it's programming (Hold Last Look or Fade out after loss of DMX,) and devices shouldn't react in unknown ways. 

This isn't meant to suggest anyone who has this problem needs to convert to EDMX or sACN, just inquiring as to whether or not we may see a reduction in this issue with newer systems.

David-

I like the idea of outputting a stream of zeros for a few frames and then powering down, especially if this is a option that can be toggled on/off in the setup screen.  

I do have one question however, in regards to this problem.  With the increasing use of Ethernet as the primary control signal between consoles and new install dimmers/devices, aren't we less likely to see this DMX Death Gasp when consoles are turned off?

My understanding of the problem is that this little hiccup of levels is primarily associated with the DMX driver chips in the console, and that we likely wouldn't see this with networked control signal. Even a DMX Node/Gateway will default to it's programming (Hold Last Look or Fade out after loss of DMX,) and devices shouldn't react in unknown ways. 

This isn't meant to suggest anyone who has this problem needs to convert to EDMX or sACN, just inquiring as to whether or not we may see a reduction in this issue with newer systems.

hi Dennis,

Yes, you are absolutely correct.  This is exclusively an issue with DMX systems.  If your control system is ENET from console to dimmers, there is no issue on power down.  ACN, for example, packets are so much more structured and error checked (remember, no error checking in DMX!!) that crap packets get thrown out.

Now, interesting that you mention DMX Gateways, and the like, as there can be issues there too.  They also have a Last Look Hold that can be employed when converting ENET input to DMX output.  It is wise to know your control system and set this feature appropriately.  If you set Last Look Hold forever and accidentally leave some dimmers up and turn off the console, well, those lights will be on next week when you come back in to the space.  But, you may wish to set LLH for a long time or forever in case you are running relay power for movers or scrollers from the Gateways in case the control system goes down.  For example, some MLs do not like to be rapidly restruck as their power supplies may fry.  Don't get me going on the design issue.  But if you use a Gateway, not set to LLH forever, to send DMX to a SmartSwitch and then someone accidentally repatches the network line in the patchbay, you could smoke some supplies.

So yes, the ACN, sACN, EDMX, NET3 systems that are exclusively networked based are not a problem.

The features are there to give you options.  Choose wisely Grasshopper.

Ok, so here I am already changing my mind.  If you have scrollers and movers on your DMX system and you send a bunch of zeros before powering off, all that gear will swing wildly in the air and run through strings.  So maybe zeros before off is bad and instead the default should be send the last look set on the console for a few frames and then off.....with the option to send zeros in the setup menu.

Forgive my ignorance, but wouldn't it be better to figure out how to have the console terminate it's transmit on a packet boundary (break) prior to powering down the interface instead of playing games with the contents of the packet and how a downstream device might interpret an interrupted packet?

Yes, and in fact that's exactly what we're talking about.  Based on a couple of conversations, it looks like I haven't been 100% clear on what we've been discussing.  In order to stop the DMX stream, likely we would change the transceiver chip from transmit mode to receive mode (or tri-state it) at the break.  However, the remaining question is, what do we do just before that.

I think most people want nothing to change on the console output and we turn it off.  That's what I meant by saying we would transmit a couple of pacekts of the current console control state.  Others, however, might wish everything to go to zero no matter what the state is and then turn off.  Ie, they don't want to manually stop playing cues and bring down subs and want the lights all to go off when they turn off the console.  To do this, we would have to transmit some zeros and then turn off the chip and then the console.  A number of sites just leave a couple of subs up all the time and turn the console on and off when they need basic classroom lights and this meets that need.  The former situation is better for movers and other such devices.

So, we would only play with the packet contents to meet shut down needs on an option select basis and then disable the transmitter prior to final console shut down.

Make sense?

It seems like the data you're sending at shutdown has no influence on this glitch.  My experiences of this were mostly with an Express console and slightly questionable wiring practices.  The order of operations was always to set all channels to zero, and then power-off.  It was pretty common for a light or two to then pop on.

The only way I see to completely prevent problems would be to stop sending data cleanly at the end of a DMX frame, and then remove power from the DMX transciever (ideally doing that first, then powering off the rest of the console, but it might not be that critical).  That way any garbled data generated while the chip is turning off should not be interpreted as a valid DMX frame by the receiving device.

edit: I should probably refresh the thread when I get interrupted for long periods between reading and posting... Basically; do what David says, he's usually right.

If I understand what David is saying, is that even though the console is sending DMX values of zero across the universe(s), the chip hiccups at power down regardless and that in turn is interpreted by the racks as a "valid enough" DMX data that something pops on, randomly.  Which would explain why setting the console channel values to zero doesn't solve the problem.   And why the only know solution has been to set console values to zero, THEN pull the DMX from the console, THEN power down the console, THEN re-plug the DMX cable.  That has generally been the known procedure among old time users of Expression.

Steve B.

Kind of related, but I was wondering...

on say a CEM or CEM+...

If I send it an empty DMX frame (just a break-delay-break with no channel info), will the missing channel data be held (as loss of DMX)? or taken as 0%?

What triggers Loss-of-DMX?  Is it no wiggle on the line?  No break on the line? No data on the line?  I know this is going to be specific to dimmer type.

Maybe if the dimmer could interpret the last look to hold as a few packets before the last valid packet (causing it to dump the last few corrupted packets)?

Anyway, my assumption has always been that no DMX data stream should be interpreted as all levels at 0%.  The hold last look is purely for just-in-case.  I would never turn on a work light or something using hold-last-look.  I never use hold-last-look-forever.  If the board goes down in a show, the worst case is going to be 1-2hrs. You never want to hold for ever without intervention (unless maybe you are an investor in electric utilities)

So then in the console at shutdown, DMX should put all levels at 00, and then disables the driver (right before? or right after? the break)  I would think that there must be an available driver chip that has fail safe protection for its data lines

I'm late to the party but I like MPenisten's way of saying it. End a frame, and don't start a new one.

I would suggest that both data lines then be connected to the shield - thus preventing further garbage. This technique could probably only be done on new hardware...

Anyone sending a signal has a responsibility to not send garbage. I'm sure somebody said something like that to morse code operators, sailors waving flags and smoke signalers.