Program testing finished for PC side of new keypunch interface

NEW KEYPUNCH INTERFACE DEVELOPMENT

I worked through a few minor issues, such as a hangup in one of my dialogs between the program and the interface box, where I had temporarily changed the interface box to send a specific message to the programming USB port, not the serial port; my PC code never received the confirmation message.

In another case, I added an extraneous character to a command that would be sent to the keypunch interface box, which caused a few behavioral issues. I was lucky to have a particular card in one of my test files on the PC which was maximum legitimate length, pushing the entire command line over the limit and triggering an error message from the KP interface box. Also it was fortunate that I had a diagnostic print showing me the messages being received by my program, allowing me to see the message.

I added a logging system, a hidden window collecting status that the user can make visible with a menu command. The wxPython implementation does not match the wxWidgets documentation, which claimed that the logging command LogGeneric took a format string and then a set of parameters as needed to complete the string (such as %d to include the parameter as a decimal number). However, it actually uses a single string which must be formatted separately if parameters are to be folded in.

The keypunch itself is still a fussbudget and unreliable, which hampers my testing when I run into misfeeds from the hopper, jams in the punch station or similar issues with the machine itself. I am not seeing a release activating at the end of every card, which I think is a dirty relay contact problem in the 029.

In spite of the 029 issues, it punches binary and regular (BCD or EBCDIC) cards well, it is easy to pause and go to a specific card number in file to resume punching. The reading function worked well, to the extent I could nurse the physical keypunch to behave.

Nonetheless, I will release the software as a beta version now, so that my partners at CHM and other places can build and begin testing with their own machines. As soon as there is a more reliable 029 wired up with the proper cables, I can move the interface box over and test at volume. Or, I might be able to convince this keypunch to work more reliably.

I put in the time to sort out the problems using pyinstaller to create a single executable file to send around. There were a few, but essentially the way that my Canopy python system has wxPython installed caused the problem. First I had to learn that by creating a console version and reading the error message when the program tried to start. Then I fixed the python issue.

My new 3.0 version is installed the new way, a level down in the site-packages, allowing the wxpython.pth path file or wx.version program to select among the wx-### directories that have the wx folder inside for their respective ### version. However, the older version in Canopy was as a wx folder directly in the site packages, which caused it to be fetched in spite of the path file, unless I used the wx.version in my program.

Next issue, pyinstaller doesn't understand wx.version and fetched only the direct wx folder, which was the wrong version, causing my program to fail. I created a dummy wx-### folder for my old version, them moved the wx folder into that one. Now, the system correctly uses the path file and more importantly, pyinstall bundled the right files.

Github is up to date now, other than the remaining documentation I need to create and post. For now, this will be put on hold until I have a more usable keypunch and/or receive problem reports from beta testers. I did spend the evening writing up the User Guide, finishing the PC program portion.