I was in the wrong impression the orientation of the Dotty buttons didn’t really matter. I did place them all in the same orientation, didn’t mix it up but didn’t check also. Later found out I was lucky on most of the Dotty’s I build.
The buttons are read by a 4051 chips 8 buttons at a time I call them rows. All four rows worked most of the time. But one build had a problem with row three. When installed in one way the buttons Dotty stop recording steps. I rotated the buttons and Dotty worked again.
Thought it was strange never had it before on the previous versions, put it aside as a glitch to sort out. Then a beta tester reported the same. Now I had to dive into this problem and fix it.
The code for row three is a bit different then the other rows. So what happened, let’s do a compare with the other rows code and try to find out whats wrong here.
All row first check if the voltage is over a threshold value, I do this to prevent further code to be run unneeded. This is equal for all rows.
Then for row one, two and four a marker is set to high meaning it’s pressed. The marker is set to prevent double clicks. Arduino sometimes has a problem called debounce to prevent this the marker is set then compared too the previous value of the marker. If these markers are different then the code will run further.
If the voltage is below threshold the previous marker is set to low so when can use it in the compare when the button is pressed.
Then code for all row is pretty much the same. Setting the button that is pressed and letting other parts of the code know there was a button pressed.
Only for rows one, two and four markers are set to compare values. This is needed to prevent debouncing and only running the code once (for example: set step). But not row three.
Row three buttons it’s important to know the buttons is still pressed. These buttons are meant to do some thing when hold down. The code has to be run over and over again and not only once. While being held down it wait until a other button is press from the other rows to do some functions (for example copy track or paste track).
So what happened here. We have to look at the physical buttons first. It seems rotated one way the pin are connected when pressed en unconnected when unpressed. This is the way it should be on Dotty. This will prevent code from running to much with the threshold.
When the buttons are rotated the pins used are connected and pressed they are unconnected. This way is not intended on Dotty. But why does it works for row one, two and four.
When the buttons are “wrongly” placed for row one, two and four. The code starts running. The current value is compare to the previous value. code is run, previous value is set as the current value. Again the function is run because the button is still connected/unpressed. The previous value and current value are the same to prevent debouncing and code is not run. So its failing the second check on second run.
When the button is pressed the value goes low. The previous value is set to low and when the button is released… The code runs again, setting the step. So the code isn’t run when pressed, but when the button is released.
Row three doesn’t have this check for debouncing. So when it is placed rotated, it will run and run and run. Like it should when being pressed. This will prevent recording steps, cause it meant to do some other functions.
So how to fix it. Still thinking about it. The build notes and check your buttons with a multi-meter, would be the first solution (maybe not the best). Writing code to solve the issue with row three would be a other option, but that might be a lot trickier.
Again many thanks to the beta testers for the input, build tips and errors they found.
Any questions, tips, suggestions the comments are open