Background values . . . what/why/and how to remove?

background values may be coming from several sources.  I would suggest you take a look at the ETC training videos that are available through the web site.  Going to cue out {goto cue out} should clear any background values that are coming from cues.  Going to cue 0 will not necessarily do this.  This is a move fade desk and as such once a channel has values in a cue list it will always have values in all the cues forward from where it was added to that cue list.   It would be helpful if you could state a specific example of data that you are trying to get rid of.  If there are specific channels you are trying to figure out where their data is coming from the {about} window will become your friend.  

I hope this helps some

The ION is it, no NPs- all conventionals on internal DMX 1. Values in question are green, and as I said prior, "about" showws nothing under" source".

4 lists defined - 1 cue each, each on a wing fader, movers in those cues only. Console op tried to put connventional 29 at full and record on a sub, and we think hit update instead. The sub didn't work, but the channel value went somewhere (no unaccountable subs on the sub list either . . .). All other lists idle- nothing on stage but the stuck value: 29 @ 0 responds, but sneak enter, and it comes back. 29 @ enter has no effect. Deleting the errant sub has no effect. Hitting stop has no efffect. Ion restart clears the value.

- Tim

green values mean that the level has gone down from the previous cue.  if you select the channel in question and hit the [about] key you should get some additional information in the CIA.  This information will include which cue is controlling that channel.

If you want to take all the channels out you can type [sub 1 through home enter] this will take all subs to their home value and then [goto cue out] which will take all cues out and clear all np values.

Perhaps I am dense, but when the channel is stuck at 100%, how can it have gone down?  Perhaps there is more than one shade of green, and this is a different one . . .

Channel# about shows exactly nothing under "current values" and a value of full as a background value . . . no list/fader/etc. as source, and hence my question . . . .

I'll try the other commands the next time it gets hung, but my basic question has gone unanswered:  what the heck is the definition of a "background value" on Ion?

- Tim

Is it always the same channel? Does it always come back after running a specific cue or fader?

Check the cues in each cue list/fader and make sure that the errant channel is not recorded into any of them.  Also check to see if your faders are set as LTP.

If that doesn't fix it, I would save your show, do a deep clear, and then reload the show.

-Todd

Please read more closely - there aren't any cues in this program, per-se.  We have the 40 slider wing, and cuelist 2 is on #21, cuelist 2 is on #31, sub 1 is on #39 and sub 2 is on #40.  We had just recorded conventional channel 11 on sub 31 (slider #31) and were trying to record conventional channel 29 on sub 32 (slider #32) via "record only" and stab both fader buttons.  Cuelist 2 has a mover ballyhoo - no conventionals at all.  Cuelist 3 has another mover look - no conventionals.  Sub 40 is house, and sub 39 a general stage wash - none of them contain conventionals 11 or 29. 

The op hit 29 @ full, and we think maybe update instead of record, and then the two buttons on fader 32 . . . that is the grey area.  This kid is sloppy as all get-out, and triggers this problem a lot . . . . myself, I never get it, so it is definitely something he does . . .

At that point, the sub did not control the light - we deleted the sub, and definitely did 29 @ full enter, record-only <stab fader 32 buttons> and the sub took, but would never go out.  Delete of that sub, and the fixture was hung at full as a background value.

The sub list did not reveal any subs other than as intended - IE didn't record to an sub not on a fader . . .

The two lists in use do not have any conventionals.

Sneak/enter, clear, and sneak/sneak/enter have no effect.  29 @ enter has no effect.  29 @ 0 will take it to 0, but either a sneak or @ enter cause it to bounce right back again . . . in green on live, which is interesting, since there is no cue with this value to transit from or to . . . just a sub, and not even that at this point.

29 about shows as above - no values in current, and "full" in background, with no listed source.

A simple exit of Ion and restart (not even a power cycle) and it clears and is good to go. No deep clear needed . . . Once it's gone, it stays gone . . .  but prior to the restart, it can't be gotten rid of to test to see if anything will bring it back . . .

It's been a while since this has happened, but this op managed to cause this to happen last year quite frequently.  Unfortunately, nobody was bored enough to watch to see what he did, and he is sloppy enough to no remember his own keystrokes, although I was standing there when this happened, and did note a very odd sequence to attempt to record the sub, but can't swear to what it was . . . but I did see "update" get hit.

This console typically runs only conventionals (96 channels), and this problem has been see t happen on pretty much any channel, and the story is almost always the same . . . something is done on the keypad in programming, and we get a hung value that we can't figure out how to clear short of an Ion application restart.  This may well be us, but yet another review of the manual, looking for "background value" shows nothing but the page for the "about" function - at no point in time does it define what a background value actually is, or where they come from, so that we might know how to actually *UNSET* a background value. 

While I am generally OK with this console, frankly, the manual needs a lot of work . . . . .

- Tim

A background value is exactly what it sounds like.  It is an instruction from some sort of source (i.e. cue or sub) that has been overridden with a manual instruction from the programmer.  The channel retains this value in the "background" but it is not what is displayed live.

As for your issue, I have no idea.  The fact that in the about screen it doesn't have a source for the background value but does display its value is weird.  Clearly it acknowledges that it is getting an instruction from somewhere, but doesn't say where...And that it is green is also weird...I would say that it is an automark, but then [Goto Q] [out] should take it out...

I would wait for Anne to stop by or maybe try contacting her directly.  She'll know what is going on.

I think you are getting a handle on the frustration!  And since this channel is a generic dimmer, what can mark?  I wish we could cause this on command, but we can't, and if you save the show in this state, reloading it does not have the issue . . . so we can't send anything to ETC to demonstrate the problem either . . .

It's been a pain to say the least, but at least a restart gets us out of it . . . But there is the constant fear that if a tweak needs to be done live that it will hang, and we will be SOL . . . 

No huge rush on this at this point . . . I'll wait until ETC gets back online after the holiday (I see to have such great timing in that regard!) . . .

- Tim

tadawson said:

Please read more closely - there aren't any cues in this program, per-se.  We have the 40 slider wing, and cuelist 2 is on #21, cuelist 2 is on #31, sub 1 is on #39 and sub 2 is on #40.  We had just recorded conventional channel 11 on sub 31 (slider #31) and were trying to record conventional channel 29 on sub 32 (slider #32) via "record only" and stab both fader buttons.  Cuelist 2 has a mover ballyhoo - no conventionals at all.  Cuelist 3 has another mover look - no conventionals.  Sub 40 is house, and sub 39 a general stage wash - none of them contain conventionals 11 or 29. 

Tim,

I'm confused- you say there aren't any cues, yet you have cuelist 2 with a mover ballyhoo and cuelist 3 with another mover look.  These cuelists have to have cues in them to record the mover parameters.

My guess is that channel 29 got recorded into a cue in your mover cue list on fader #31 (it is right next to #32, so easy to accidentally hit the wrong one).   If you want to post the show file we can all take a look at it and see if I (or someone else) can figure it out.

-Todd

I say that since there are no proper lists - IE multiple cues to transition between, as in we don't ever run a stack in this case.  We use the "go" button to get into these and the other to exit.  Viewing them in blind shows no data whatsoever for these channels in the two lists.  I also fatfingered - list 2 is on #22 - totally different bank, nowhere near where we were trying to record. .

Also, were the list active, all else in the list would be active, and that is clearly not what is happening.

And lastly, if that *were* the case, a reboot would not permanently correct the issue, which it did. . . .

And if it was coming from a list, "about" should have clearly shown the source, which it did not . . .

I don't think this is as simple as everyone wants to make it . . . .

- Tim

Good Evening Tim,

could you post the showfile, and we could get a look at it, and see whats up here?

Not sure there is anything to see at this point . . . we restarted ION, rewrote the sub needed (as well as finishing other programming), and all has been fine for days . . . this isn't a showfile issue, or we would keep tripping over it, and it isn't triggered by a playback - it was triggered while programming. 

I have asked the op to try to recreate what he did when it went out . . . this one guy seems to cause this regularly, and none of the rest of us have the issue . . . so with any luck, he can figure out what he does . . . .

- Tim

Tim,  if you can reproduce, please send us the log files from the desk, noting the date and time that you saw it happen.   The logs can be sent to eos@etcconnect.com.  Files can be extracted by going to the shell/maintenance/save logs.

Thanks much!

a

Anne -

How long are the logs kept?  The problem was last Wed, but there hasn't been too much programming going on since then, and we know that the issue was at about 6:30 or so Wed PM. . . . .

Considering that this is  a school, and not much else is happening this year, not sure how much luck we will have reproducing.  If the logs show keystrokes, then maybe we have the chance to see what we did, which may help to reproduce the problem . . .

Any suggestions?

- Tim

Hi Tim,

I can help answer that --

We keep logs for a long time on the desk -- way past a week ago.  We'd definitely be seeing things logged back then.   We can look in the logs and find keystrokes as well, which definitely helps us find out what's going on.

So, please feel free to pull logs and send them in.  We can look back then and see if there are any "smoking guns," as it were, and try to reproduce.  

Hans

Could it be that you have this after loading a new showfile? If a previous showfile has a channel at a level, and you load a new showfile, these levels remain. Using [Go To Cue][Out] should get rid of them.

Nope, started with a clean show, and nothing was loaded at any time prior or after to this occurring.

- Tim

Nope, started with a clean show, and nothing was loaded at any time prior or after to this occurring.

- Tim