Arduino IO Expansion

Im not using a nano. Yes the mega has 6, I'm using 4 encoders so Id need 8 if I wanted to use 2 interrupts per.

There are just override knobs, they should be fine without interrupts, only the MPG really needs them. The project states it can work with non-interrupts so there must be an issue as a different sketch not using the interrupts does work. This is wired to a PCB so I can't change things around without respinning it

I misspoke about the 3rd encoder, it is NOT connected to interrupts. The PJRC encoder lib that this is using mentions:

If neither pin has interrupt capability, Encoder can still work. The signals are only checked during each use of the read() function. As long as your program continues to call read() quickly enough, you will get accurate results. Low resolution rotary encoders used for dials or knobs turned only by human fingers are good candidates for low performance polling mode.

So conclusion is this project currently does not work with non-interrupt connected encoders. I may just respin this PCB and get them all interrupt attached as I should actually have enough interrupts on a mega.

My suspicion about the key and LED matrix issue is that the code is assuming the addresses based on pin number order. I make this assumption because the specific row/column pins are not defined, just which pins are rows and which pins are columns. My 2 examples both define the row/column numbers specifically. My PCB runs the column and row numbers in reverse pin number order for easier routing. I asked a friend to take a look so he can tell me for sure.....I can't read code for shit.

I am not sure why you are having problems with the encocders not connected to non interupt pins. I have not encountered this issue myself yet, but will try to reproduce it.
What I see right away is, that you should change your .ino file to these settings:
const int QuadEncSig[] = {2,2,1,1};
const int QuadEncMp[] = {1,1,1,1}; (propably you want {4,4,4,4}, or else one mechanical latch will output 4 electrical pulses. )
I don't think it will help with your problem tho.
Please try to comment out Joysticks by putting //#define JOYSTICK.

Not sure if I understand your issue correctly. What do you mean with "the code is assuming the addresses based on pin number order."?

The specific row/column pins are defined in the arrays in the config. first row is first entry, second is second and so on. What you did in the provided Files, looks good.

However it seems you did not configure the Multiplexed LEDs correctly.

First of all uncomment this line: //#define MULTIPLEXLEDS
also these lines should not be edited, please change it back to:
int ledStates[numVccPins*numGndPins] = {0};

and also this line in keypad :
int keys[numRows][numCols] = {0};

Please try it and report back your results. Fingers crossed it works now.

The encoder issue happens with the sketch I posted that uses the same library. The first 2 encoders are fine, the 3rd and 4th don't read. If I swap the encoders around between ports they all work if they're connected to the first 2 encoder channels. This is a library issue, I'll see if I can figure that out outside of this project.

I did miss that commented #define again, the way the notes are commented makes it hard to spot things like this. The other stuff I probably started messing with when I couldn't get it working and just walked away from it and forgot. 

I made the changes you mentioned, setting aside the encoders there's still something quite wrong with the whole matrix/mux thing. Hard to explain what's going on so if you can stand to watch a 6 minute shaky cel phone video:
drive.google.com/file/d/1120jefPOA8bVBPt.../view?usp=drive_link

The specific row/column pins are defined in the arrays in the config. first row is first entry, second is second and so on. What you did in the provided Files, looks good.

That's pretty much what I thought and was asking.

Thank you for the video.
I think what you could test is talking to the arduino directly, like you did in the Video.
Now send commands like M1:1 and key No.2 should light up. M1:0 and it should shut off again. If this works we know, it is something wrong with the py file.
If it still doesn't I'd try to get the LEDs to work seperately from the keypad first. Since both functions share pins it's possible they are messing with each other somehow.
I'd reccommend to disable Keypad by commenting out the #define again.

Something weird is going on with the Keypad aswell, the behaviour seen in your video is not usual. The lagging propably happens, since the rapid firing of Key presses clogs the serial port and linuxcnc takes some time to process it.
Something confuses the arduino and makes it rapidly set keys to true / false, which is the root of all other weird behaviours you mentioned.

I did try this just a little while ago. What is confusing me is that the M# when turning on the LEDs does not correspond to anything I can recognize. Over the serial terminal I can more or less turn some of the LEDs on and off reliably but there's no way to know which LED I'm turning on. I think it works upto about M20 then it doesn't really respond. When pressing keys it seems like it reports the correct key M# to the serial terminal, it's just all but the first 4 and last 4 do that rapid fire. I'll verify this later and I'll try disabling the keypad and turning on the LEDs soon.

The encoder issue just "went away". My 4th encoder  just started working when I was messing with the matrix keys and the 3rd encoder I had one pin # defined wrong, so it doesn't look like there's any issue there.

The Leds are counted from 0-total number of LEDs. So 0- 31 in your case. M0:1 turns on the first LED. M1:1 the second. By doing this you should see which way the rows are counted in your case. (left/right/up or down).
Possibly the LEDs are messed up because the Pin definitions dont match with the actual pcb.
I'd expect that M0:1 M7:1 lights up top left and top rigth LEDs in your setup.
I think you can go from there and try to debug your setup this way.
Also what Keys are you useing? Are they all normally open?

The keys and LEDs are exactly as shown in the drawing, that is the schematic for the PCB so yes, they are all normally open. If you look at the example sketches I posted for the Key and LED matrix's they work perfectly as shown in the video. The key matrix test only prints 1 character to the serial terminal so I reused characters but there's nothing strange about it, no stuck keys or anything like that.

Possibly the LEDs are messed up because the Pin definitions dont match with the actual pcb.

Not quite sure what this means, it would be very unlikely that the key numbers "matched" the Arduino pin numbers, nobody would wire it like that. The keys/LEDs are in reverse order opposed to the pin numbers but I asked about this before and you said before that this does not matter, it follows the order they are defined, which is why I defined them backwards.

I tried disabling the key matrix, the LEDs work the same. I'm not good with code but it looks like something is hardcoded to start the next row @ 4, as if it always assumes it is a 4 column keyboard. I made a note of how they print, this is why there is duplicates. Turning on an LED seems to grab one of the duplicates which is why it didn't make sense. All the keys that rapid print are duplicates, and they are colored green in my notes. I've checked and I don't think I misconfigured anything but I will post my current ino as well

 

 

I don't understand your drawing. Is this the output of the Keypad / Matrix keyboard?

The duplication issue is obviously wrong and propably the root of the issue with the keyboard.
I think we should focus on one first. Would you like to get the keys or the leds working first?



I know this is confusing, but I decided it was ok, since this is internal communication, but the Feature of Keyboard and Matrixled are both encoded by 'M', so when Arduino sends it, it is a Key pressed. When you type it it refers to an LED. From your wiring the LEDs i'd expect them to be numbered like this: (possibly the keys too)
0 4 8 12 16 etc...
1 5 9 13 17
2 6 10 14 18
3 7 11 15 19

It doesn't really matter, but just imagine your matrix flipped by 90°
In the Py file these keys get their value assigned, and there you can change it to match your setup.

The drawing is showing you what each key is printing to the serial terminal, this is just the Arduino firmware, it is not the Python stuff. The LEDs seem to match one of the numbered keys but since they are duplicated you would not know which key the LED is actually going to address. If you fix the key numbering issue I suspect the LEDs will work fine.

The Green boxes are the keys that rapid fire, they are also all duplicated M#s so that is likely the issue.

The problem is it should start the 2nd row at M8, not M4. It does this for every row, as it is assuming there are 4 columns when there are 8 columns.

I could be wrong about this but in your videos you were using a 4x4 keypad. You would not catch this issue if you were using a keypad with 4rows and 4columns

My Keypad is arranged 0-7, 8-15, 16-23, 24-31. It sounds like you are suggesting that it is expecting to count down through the rows, I am expecting that it counts across the columns left to right....which is exactly what it does, problem is it starts a new row x numRows, it should start numbering a new row x numCols.[/code]