It was a busy work day and tomorrow will be even more jam packed, but I did get some time to test the keypunch interface box.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I added in support for XON/XOFF flow control in a way that will protect us from deadly embrace problems and fits in cleanly with the logic flow. When we detect an XOFF from the user side, we flag the occurrence and will not pass along completed commands to be parsed and processed. We won't be sending any data to the user during the accumulation of a command line, thus won't overflow their buffers. On our side, we are vulnerable to buffer overflow during the long duration activities when we are operating the keypunch, so we will send an XOFF at the start of command execution and XON at the end.
If the user terminal sends an XOFF to us in the middle of a command, when we are sending text with status responses or a card image in the case of a read, we might overflow the user terminal. To fix this would require us to write into a buffer and have a separate process emptying it subject to flow control. The impact of losing part of a status message is low, so we will accept this risk.
The card reading routine, however, could overrun the users receive buffer because of the 89 or 409 characters we will send as a single action before completing the read command. The Serial1.print() call will block until it can pump the last of the data into the 64 byte output buffer, which means we can't read the incoming serial stream to spot an XOFF.
If we could peek at the incoming serial buffer to spot an XOFF, we still wouldn't be able to stop the output in time. The Serial library in Arduino has no flow control - it will just pump out bytes until the buffer is empty. In order to guarantee successful flow control, we would have to institute a separate buffer for outgoing messages and pump it out by some method that would be given control in spurts to send out just enough to fit in the output buffer. Peeking at the receive buffer is also a challenge because the Arduino environment only gives us the immediate next character, not any behind it.
The user serial link issue was resolved - wire snapped in a harness inside my interface. I continued to debug code and clean up behavior. The relays appear to be operating correctly except for the row 12 punch relay which makes no sound. I will check that wiring. In addition, some of the relays sound but the signal LED on the relay board doesn't illuminate. Not sure if that is significant or just a flaw in the board. I will do some connectivity testing of the relay contacts before hooking up my keypunch cables.
After a bit of double checking, I discovered that one of the pin assignments was incorrect and that two signals were assigned to the same relay leaving the other relay disconnected. After making quick changes, I retested and everything clicked and lit as it should. Next up was a test of the DB25 cable connections to ensure that I am controlling each wire I expect inside the keypunch.
Everything checks out for the connections that are switched through the 16 relays. I also checked the pair of wires in each cable which are shorted to allow the Arduino to detect if the cable is connected or not. Finally, I tested the pair of contacts that hook to the reed switch detecting when a card is registered at the punch station.
The only part not tested is the reader cable which will detect the presence of holes in cards as they are moved through the dup (reader) station. Once I do a quick sanity check of the wiring in the keypunch, I will plug in my cables and run the diagnostics.
No comments:
Post a Comment