John,
To answer your questions,
1, No hardware de-bounce: I'm unsure of the behavior of your Arduino code and what it would do with a changing input. In the code I'm working with only the first transition matters, so the "button" can bounce all it likes and it will have no effect on the operation of the rest of the code or hardware. My timers start from that first transition when a button is pressed, and the code ignores all additional triggers of that input pin until it's matched second input has been tripped. EX: when you press the button to set a switch to 'through' pressing the button again does nothing. you first must set it to the diverging direction before it will respond to another through command. Set up this way allows for parking a train on a switch with out the coil being fired.
All that said, I'm thinking of adding provisions for a hardware de-bounce in the circuit so that the same board can be used to read inputs for devices other than switches such as uncoupler sections and accessories. I think the final design will include a hardware de-bounce, but also be designed such that the components can be omitted if de-bouncing is not needed in the intended application.
2, Pull-up resistors: 100k Ohms should be just fine and would reduce current draw as stan suggests. 10k Ohms is sort of a generic pull-up value and I didn't put any thought into it. I will probably take some time to optimize the value of several parts before establishing a "final" design.
3, Decoupling capacitors: At the speed we are sending data with the Arduino's shiftOut function and over short distances between the Arduino and the shift register of a couple inches, you could probably get away without the caps if you really wanted to. That said when working with reasonably high frequencies it's a good idea to use them. If using the Arduino's SPI bus to send shift data then the decoupling caps would become necessary. For the 5 cents or so per cap I would recommend using them.
On the board location, also remember you nee 16 wires for the inputs from the anti-derail isolated rails, 16 more from push buttons, and 16 more for dwarf/panel indicators. That's a lot of wires. I can get by with 4 wires between each module instead of 18 (16 data, Power, and Ground). I'm thinking of adding a RS485 chip to each module here, allowing for distances between boards of easily hundreds of feet, but this would add about a dollar to the cost of every module. It also makes the coding and hook-up a bit more complex. Another option I'm kicking around is adding Bluetooth or similar radio transceivers to each module that would allow all the data to be sent between devices without any data wires, just a power source. Cost is similar to RS485 at about a dollar per radio, but the code is significantly more complex to make this work, and it may have range or interference issues in some installations. Over all I like the radio method the best because it allows for really easy installation, but I'm not really decided one way or another. For modules places near each other ( within a couple feet) the Arduino's built in I2C interface would work great, but that requires all the parts of this system to be in one place with over 60 wires running about to various switch machines, buttons and signals. Over all just thinking about ways to reduce that mess.
On the second topic, yes, it is not hard to do the code to prioritize the anti-derail inputs. The difference is that you need a second set of 16 inputs to do this, so a whole extra input board. I'm thinking of programing for the option, then letting folks decide if they want the feature or not, but posed the question because I thought, " Well, what if I'm over thinking things and no one needs or wants the feature?" I'll keep thinking it over for now.
JGL
