mstanley:
I apologize for how blunt I am about to be but I need to figure out your level of programming knowledge before I start explaining really basic things like scope, array indexing, and objects.The reason I say this is because you are using
encodermatrix.key[6].kstatecompletely incorrectly.
encodermatrix.key[indexNumber].kstate is only used when you are expecting several 'encoders' to be pressing their associated buttons "at the same time".
So if I understand you correctly your encoder is something like a wheel with a bump on it that first presses and releases one key and then some short time later the bump presses and releases a second key? Are you doing this so you know which direction the encoder is turning?
I also need to point out that in order to generate any kind of code (grey code in your case) requires multiple bits to be high or low at the same time which directly implies that you should be using getKeys().This is just pure luck. What's happening in reality is that you are only registering one button pressing at a time when you see this output.
The key list always starts storing active keys at index zero. So when your encoder is going CW button 2 is actually being recorded in the key list at index 0 and when it reverses in the CCW direction button 1 is being recorded in the key list index 0 position. It looks good for this example of your output but it's not working the way you think it is. That is why you can't get keys 3 and higher to work.I'm off to bed for the evening so to get an idea of what I am talking about take a look at two example sketches.
File --> Examples --> Keypad --> EventKeypad : for when you are reading single keys at a time and,
File --> Examples --> Keypad --> Multikey : for when you need to read multiple keys at a time.
OK I am pretty novice at programming, but once I find out exactly the way something works I can usually logically figure it out and then find examples of such to get things to work and figure it out fairly quickly.. Your explanation of how kstate actually works indicates that my thought process on how kstate worked is flawed as I thought by what I was reading was flawed and after such I was trying to figure out what was wrong.
In reality I am basically trying to replicate the Grey Code that is output by the Encoder which can be replicated on button presses when the encoder is turning rather than by actual pinstates. This is so that I can have Multiple encoders in a Matrix rather than using up a ton of inputs on the processor for those encoders.. ie 6 encoders would use 12 wires + a ground normally. Where in a 4x3 matrix it would only need 7.
So with what you are saying about kstate and the dumb luck on finding something that worked.. is it possible to limit the list of the multi key to ONLY look at say keys 3 and 4 or 7 and 8 at any given time based on the initial key that was received through geyKey that determined that the encoder had started turning. What I am afraid of with just reading the Keys from the multi key code is the possible loss of synchronization between the Key pairs that would create the Virtual Grey code based on the button states to determine direction.
I could probably jerry rig this code to work with any pairs as I do know the initial turn and button used by turning all the encoders to be at the 0, 1 positions since more than likely encoders will only be turned at one time. But I know that won't be "proper code" and it could cause oddities later.
The encoders that I have are full step encoders that put out the following signals on each index (output A, output B) of (0,0) (0,1) (1,1) and (1,0).. and the virtual grey code I would hopefully be able to track these presses and then be able to process the pairs to figure out the direction of turn and then have a single output command for the direction that the encoder is being turned.