To begin, the above did compile with the correct use of brackets (thank you TheMemberFormerlyKnownAsAWOL) and does work pretty well. It could be much nicer and I completely agree with the sentiment of "keeping the code simple and clean". I am learning and things are getting easier.
In answer to your questions.
1.) when you configure an input pins in setup(), should you read the input to initialize the state of the pin (possibly avoiding a mis-count?
Should I? I'm guessing the answer is yes. I had assumed that since all of the optical sensors are closed at machine start that they would all be LOW and as such I wouldn't have to check.
2.) presumably the BCD inputs are allowed to change while the system is running, otherwise you could just read them once when in setup?
The BCD inputs have absolutely no reason to change when the machine is running. It is often set to the same value for many months.
I honestly thought I was reading them once in setup. And then I look back and see that the bcd inputs are read in the weird space I have created between the end of setup and the beginning of loop.
3.) why have bcdtot75() instead of just
if (bulbcounter >= bcdtot() * 0.75)
Yes indeed, that would make a huge amount more sense. It's mind boggling how obvious this is and how I completely missed it.
4.) optical switches typically don't need debouncing. is this true?
Yes/No/Maybe
The optical interrupters in the machine are not what I am used to. I am used to a 4 pin optical interrupter. These are a 3 pin (5V - GND - Signal) mounted on a small pcb, the sort that I would normally associate with a build your own robot kit,
In practice I have found that these don't need debouncing at all. I have run the machine for hours today and it doesn't double count at all. That is not to say that there shouldn't be some accounting for debounce but in practice it doesn't look like it needs it, so I guess it would just be extra code for no reason.
- since this will loop pretty quickly, seems that the prints will report the same number often. could track the lastCount and only print the count when it changes.
This would be much nicer. The serial output is only there so I could initially keep an eye on it and will eventually be commented out as it really should be unnecessary but it be much nicer to read the serial output which is currently a high speed list.
- consider how chkButtons() monitors multiple inputs. there's no need to maintain the current state since the previous (last) state is set to the same value..
I have spent 10 minutes looking at chkButtons and am only just beginning to make any sense of it. I will go and look at this harder make a bit more sense of it and come back to you on this.
Even though the machine now works I'm going to rewrite the code anyway. I'm not happy knowing that what I have written is out there running in the clunkiest of fashions.
Thanks for your help, I really appreciate it.