Ion not responding to numeric keys

Recently we've had a strange situation occurring where for some inexplicable reason in the middle of programming the ion suddenly stops recognizing numeric keys, and sometimes, in the middle of trying to form a command, will display the error message that the spacebar is disabled, use Ctrl-G as if the software were being used off line on a PC. We haven't been able to work out quite what key combination led up to this situation, and the only way to regain control of the keyboard has been to power down and restart the console. Anyone else seen this behaviour? How did you rectify it if so?

Parents Reply Children
  • Yes, I've had a confirmation from Matt that it's being looked at. Thanks. Fingers crossed something turns up.
  • And an update from Matt that the console is seeing a tab down event but no tab up event, suggesting a stuck key (or a lost event - as a developer I can see how easy it would be for events to be dropped when a system is busy). If it's a stuck key that's a pretty bad show as the console is only about three years old - I'd expect a key to last longer than that.

    OTOH, I'm not sure why power cycling clears the problem - surely if the key was stuck down it would still be stuck when the power came back.
  • If it was missed events more people would be seeing it, I'm sure a lot of people are driving there Eos hardware harder then you're driving your Ion. Also ETC developers are at the top of there game and they won't be missing key press events.

    Sounds like a single component fault and ETC's top technical support and customer service will fix it. I'm sure this is single component out of a few thousand that has failed in Ions around the globe. It could also be misuse or some bad maintenance.
  • I am thinking maybe something was on the keyboard ...
  • My thoughts too, or a bad keyboard.
    The amount of times I think my touch screens have stopped working only to find the mouse isn't sitting on my desk properly.
  • First thing I asked the user when the fault was reported. And when it happened to me, there definitely wasn't anything on either keyboard.
  • I take your point, although the desk is treated with kid gloves (as was our last desk, which lasted about 15 years IIRC), so misuse is unlikely, but I will of course make inquiries. Component failure - possibly. Rebooting the machine via the CIA menu with the mouse wouldn't clear something physically off the keyboard, of course. I'll have to find out the cost of getting it investigated of course.
  • It's just always better to remove all auxiliaries apart from the monitors when having these problems to see if they are the problem.
    Or just change the keyboard to see if it goes away.
  • Yes - but if Eos registered a BUTTON Down Press - meaning something was laid on top of the Keyboard, and then the console rebooted, and something was still lying on the Keyboard, it won't send another button down press until its picked up and placed down on the Keyboard again, so the Problem would seem to have gone away with a reboot. But as Nick suggested - keeping an active thought about whats on the Keyboard and also swapping out the possibly defective Keyboard may possibly keep the Problem from reoccurring.

  • Hmm, well I'll see about having an alternative keyboard to hand. It's just a standard USB PC keyboard, isn't it?

    Do't get me wrong, i think the Ion is a great product. Just a bit deflated that something as simple as a keyboard fault could be letting us down. But now I know, I know what to look for.
  • Yes it's a standard keyboard.

    Unfortunately the Ion can't decide that it's a bad keyboard and stop the keyboard functions.
  • I did a bit of digging in the logs myself. I found the point where when my colleague was using the console it suddenly stopped responding to numeric keys, where, as was noted, a Tab -> Tab_Down occurs without a matching Tab_Up. What then follows is that most of the keys appear to be acknowledge, but the numeric keys don't. Any operation then appears to refeence Cue 1, pallete 1 etc. At various points the numeric keys can be seen being dequeued as a number of long numeric sequences which of course makes no sense to the console (the non numeric keys having been processed but of course in the wrong context. so it discards them and raises a syntax error.

    The thing is, the identical problem had happened to me on the previous show. So I did some detective work and found the same Tab->Tab_Down without matching Tab_Up, followed by the out of sequence dequeuing  of the numerics. So far so good.

    What is more surprising however is that the "stuck" keys both happened in the same, and I mean exactly the same, context. The Tab->Tab_Down occurred immediately after the Label key was pressed during a record cue.
    May be relevant?
  • Spurred on by this, I've just tried an experiment in the offline editor. Let's suppose you are recording a cue and you're typing the label on the little keyboard, and let's suppose you accidentally clip the tab key with your fat fingers while you're typing. So you think you've typed

    Record Cue 3 Label With Tabs

    But actually you've typed

    Record Cue 3 Label With Ta<Tab>bs

    You get no visual indication of this, as tabs aren't valid in labels so just get discarded, except they don't completely, because when you press enter to complete the label the console still thinks the tab key is down, and the next numeric entry does indeed appear with the tiny, tell tale red "tab 34" (or whatever) legend showing that the console"thinks" it's processing a tab selection command. This is reproducible, and I think it's a bug, as it has the whiff of an error in the keyboard processing's state machine.

    Pressing tab does clear the condition, however, so now we know about it it's not catastrophic but it is something I think needs looking at as it is confusing.

  • Oh I see you, so someone made a mistake when labelling and they didn't noticed that when they used the numeric keys it was posting a Tab command.

    So it was a PICNIC error as well!
  • My contention is that inconsistent handling is a bug - certainly if I was presented with this sort of report from one of my end users I'd consider it my problem, not theirs.

    The tab key has different processing to most other keys anyway; it is pressed to start a tab operation, then other keys are pressed while it is held down, then it is released to end the tab operation (and the operation performed depends on whether numeric or arrow keys were used while it was held down. But this behaviour I saw is inconsistent - pressing tab when in label mode doesn't begin a tab operation until after the current command completes. Similarly, pressing other, non alphanumeric keys, results in their representation appearing in the label (Time, Delay etc) but Tab appears silently lost. Except, as we've seen, it isn't completely. The flag indicating that a Tab operation is in force is still set, but contextually it isn't processed in the same way.

    I'm somewhat disappointed that someone described as a guru feels it is necessary to denigrate comments made by someone describing unusual behaviour by the console. Are you the Nick I met on a training day? This seems out of character.

    Anyway, since my thoughts are getting short shrift, I'll forward them directly to Matt to pass on to the R&D team to see what they think.
Related