Traveling today from the west coast to Raleigh-Durham where I will spend the next two days with a client, coming home again on Thursday. I was fortunate not to be caught up in the blizzard affecting the northeast US.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I started banging out code to deal with the 1130 Simulator formats when I ran into the realities of Unicode. I had naively expected characters encoded as 16 bit values, thus an 80 column card record would be 160 bytes long. Instead, I had to learn about codecs, encodings, UTF-8, various encodings used on Windows and other operating systems, and all the esoterica of handling strings with Unicode characters that are not part of basic ASCII.
In order to handle the files used with the IBM 1130 Simulator on Windows, it is necessary to deal with Unicode files, not simple ascii text files. I can't just substitute a regular ASCII character for the cent sign and logical not sign characters which Brian Knittel represents with U-A2 and U-AC. While these could fit in a byte, allowing a potential encoding that is still one byte per character, that wouldn't work for any Unicode character above U-FF.
The binary format for the simulator is much simpler - it is just two bytes per card column in pure binary. I just have to read it in fixed sized records instead of with a readline() function, then translate it to the ascii oriented standard binary encoding in this system. It is, however, yet a third way to do I/O that I must select depending on the users choice of encoding - codecs, ascii lines or binary fixed records.
The usual read and write facilities in Windows will return ASCII but for Python, they would throw an exception for values above basic ASCII (U-7F and below). I have no idea how Windows is encoding these characters in files and it seems that one can configure Windows to use different encodings depending on the localization, i.e. language, country, region etc. That means the only safe way to read 80 Unicode characters from a file is to use the codec module and tell it to use the Windows configured encoding.
It is possible get oneself into trouble easily when mixing ordinary (ASCII) strings and Unicode strings in Python, so I have to be careful to isolate all the Unicode handling away from the rest of the program. I only need to get things into Unicode just before I write them out, and on input I will immediately translate Unicode into my EBCDIC encoding in plain ASCII.
I am generating the code for this, then will give it a try with some files from the IBM1130.org simulator. Now working through the code making sure it works.
Monday, January 26, 2015
Sunday, January 25, 2015
Disassembled part of console printer, fixed vectrex game consoles, and moved forward on a few tasks
I had a pile of prep work to do in advance of my trip tomorrow morning, but did manage to get free by the afternoon to work on various parts of the project.
1053 CONSOLE PRINTER RESTORATION
I finally gave up on finding the spring by inspection, determining I would have to partially disassemble the machine to get to the bottom of the issues (and probably find the well hidden spring). I removed the operational magnets, a cluster of five solenoids that trigger space, tab, backspace, carrier return and index operations when energized.
I have incurred the need to set and check quite a few adjustments because of what I disturbed by removing the items, but if I can get to the bottom of the spring-mystery and take advantage of the access to further clean and lubricate it.
I looked at the motor pulley I removed from the printer due to corrosion, decided I might be able to clean it up enough to put on the Itel/Dura selectric mechanism instead of buying a new one. After a bit of scraping and cleaning, it looked serviceable. I tested it out manually by bending a new belt around the pulley to test whether the belt would push up a bit when the formerly bad grooves came around. It looks very good indeed which means this part will go back on the Dura.
With the operational magnet assembly removed, I could see the entire path of the mechanisms that trigger the various operations and get reset at the end of the mechanical function. I still don't see the spring but I should be able to discover where it is based on drag and sticking. I ran out of time before the trip but I am feeling like I am finally making some progress again.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I did blast through the User Guide and update it to reflect the four IBM 1130 Simulator encoding types, but will hold off on touching the program itself until I begin traveling tomorrow. These encodings are the file types as used by Brian Knittel's IBM 1130 Simulator.
Those files are stored on the PC in Unicode in some cases, if they are in his default 029 keypunch format for card images, because his encoding uses two characters that are not in the plain ASCII character set, whereas I substituted one ASCII character for each of them. His binary mode is not a text file, instead packing the bits for each card column into a 16 bit word.
I decided to handle these by translating the IBM 1130 oriented files during reading into my program and when data is written out, so that inside the program and over the link to the KPgolem interface box they will be in my binary or EBCDIC modes. The keypunch interface box doesn't know about these or care, leaving the work to the PC program.
QUICK BUILD OF BRIAN'S CARD READER INTERFACE
All materials needed to build this are now on order or in hand. I plan to build it to fit inside the card reader controller box I built for my 1130 replica, since it grabs the wires from the Documation reader at this point, and to avoid the expense of building a separate enclosure and power supply.
1053 CONSOLE PRINTER RESTORATION
I finally gave up on finding the spring by inspection, determining I would have to partially disassemble the machine to get to the bottom of the issues (and probably find the well hidden spring). I removed the operational magnets, a cluster of five solenoids that trigger space, tab, backspace, carrier return and index operations when energized.
 |
| Shift magnet on right and operational magnet assembly on left |
 |
| Interposers and other operatonal mechanisms now accessible |
With the operational magnet assembly removed, I could see the entire path of the mechanisms that trigger the various operations and get reset at the end of the mechanical function. I still don't see the spring but I should be able to discover where it is based on drag and sticking. I ran out of time before the trip but I am feeling like I am finally making some progress again.
 |
| Magnet assemblies hanging out of the way |
NEW KEYPUNCH INTERFACE DEVELOPMENT
I did blast through the User Guide and update it to reflect the four IBM 1130 Simulator encoding types, but will hold off on touching the program itself until I begin traveling tomorrow. These encodings are the file types as used by Brian Knittel's IBM 1130 Simulator.
Those files are stored on the PC in Unicode in some cases, if they are in his default 029 keypunch format for card images, because his encoding uses two characters that are not in the plain ASCII character set, whereas I substituted one ASCII character for each of them. His binary mode is not a text file, instead packing the bits for each card column into a 16 bit word.
I decided to handle these by translating the IBM 1130 oriented files during reading into my program and when data is written out, so that inside the program and over the link to the KPgolem interface box they will be in my binary or EBCDIC modes. The keypunch interface box doesn't know about these or care, leaving the work to the PC program.
QUICK BUILD OF BRIAN'S CARD READER INTERFACE
All materials needed to build this are now on order or in hand. I plan to build it to fit inside the card reader controller box I built for my 1130 replica, since it grabs the wires from the Documation reader at this point, and to avoid the expense of building a separate enclosure and power supply.
REPAIRING VECTREX GAME CONSOLES FOR DIGITAL GAME MUSEUM
I had two Vectrex game consoles, early gaming systems, that had been donated to DGM but these two didn't work right. When turned on, we could hear the music and sounds of the game, which varied when the hand controller was operated, but the display had only a one inch long horizontal line in about the middle of the screen. I did some diagnosis, hauling out the oscilloscope and meters to narrow down where the problem lay.
I didn't have much time but I was able to find problems that I could test with a temporary replacement part - both screens displayed a full image which was excellent. I have to find a good replacement that is as consistent as possible with the original part. One of the two machines is working perfectly, needing only the last permanent part replacement to wrap this repair up. The other didn't look right to me, which means I have some more diagnosis to do next week.
I had two Vectrex game consoles, early gaming systems, that had been donated to DGM but these two didn't work right. When turned on, we could hear the music and sounds of the game, which varied when the hand controller was operated, but the display had only a one inch long horizontal line in about the middle of the screen. I did some diagnosis, hauling out the oscilloscope and meters to narrow down where the problem lay.
I didn't have much time but I was able to find problems that I could test with a temporary replacement part - both screens displayed a full image which was excellent. I have to find a good replacement that is as consistent as possible with the original part. One of the two machines is working perfectly, needing only the last permanent part replacement to wrap this repair up. The other didn't look right to me, which means I have some more diagnosis to do next week.
 |
| Startup screen of the console |
 |
| Game operation |
 |
| Some game graphics - vectors |
Saturday, January 24, 2015
Fighting the shed alignment, hunting lost springs and building a card reader interface
1053 CONSOLE PRINTER RESTORATION
I put in a good two hours examining the mechanism, hunting, testing linkages. I still have odd behavior with the space button and part of the carrier return release is not working all that well, which could be a trapped squished spring in the works. This is so tedious and time-consuming but it will be essential to use the console printer.
QUICK CARD READER INTERFACE FOR READING DECKS
I decided to quickly build a version of Brian Knittel's Documation interface to PC, as that would involve almost zero design or debug time, The aim was to get the fastest time to digitizing card decks. The design uses a couple of out of production chips, but I lined them up and expect them by the end of next week.
I already have the cable wired up to my interface to the replica 1130, which means I can piggyback on the wires in the box rather than having to wire up the complex multipin connector used with the reader.
All the prices of the components seemed quite modest until I came to realize that getting the code onto the SX microcontroller chip requires a SX-Key or SX-Blitz module, or supporting a complex protocol I would have to design for and debug just to program the EEPROM on the controller. The processor itself is under $2. The SX-Key module to program it - $60. Argh. Bit the bullet and ordered it. Perhaps I can sell it on ebay or elsewhere to recoup part of my money. I don't expect to program this obsolete family of controllers, that are long out of production, ever again.
I put in a good two hours examining the mechanism, hunting, testing linkages. I still have odd behavior with the space button and part of the carrier return release is not working all that well, which could be a trapped squished spring in the works. This is so tedious and time-consuming but it will be essential to use the console printer.
QUICK CARD READER INTERFACE FOR READING DECKS
I decided to quickly build a version of Brian Knittel's Documation interface to PC, as that would involve almost zero design or debug time, The aim was to get the fastest time to digitizing card decks. The design uses a couple of out of production chips, but I lined them up and expect them by the end of next week.
I already have the cable wired up to my interface to the replica 1130, which means I can piggyback on the wires in the box rather than having to wire up the complex multipin connector used with the reader.
All the prices of the components seemed quite modest until I came to realize that getting the code onto the SX microcontroller chip requires a SX-Key or SX-Blitz module, or supporting a complex protocol I would have to design for and debug just to program the EEPROM on the controller. The processor itself is under $2. The SX-Key module to program it - $60. Argh. Bit the bullet and ordered it. Perhaps I can sell it on ebay or elsewhere to recoup part of my money. I don't expect to program this obsolete family of controllers, that are long out of production, ever again.
My first few reading tasks will be the ECAP program that a fellow 1130 enthusiast wants to run on his 1130 emulator, some line printer art decks I have since these have wide applicability for retro computing fans, and then some 1130 system software decks.
NEW KEYPUNCH PROGRAM
I want to support the file formats of the 1130 simulator, which adds a bit of complexity for the ASCII encodings. The binary format is easily converted into the KPgolem binary notation, but the ASCII based files can be in one of three encodings, called 029, 026Fortran and 026Commercial. None of these are exactly aligned with BCD or EBCDIC.
The interesting difference caused by the format is the inclusion of extended ASCII characters for ¬ and ¢ where I used ^ and [ to represent them. The files will have to use 8 bit ASCII, which is not transmissible over the link to KPgolem given its restriction to 7 bit ASCII. Not a problem, as I can map the 1130 formats to my encoding for punching, while retaining the other characters for screen and PC file use.
I am kicking around the exact way I want to support this, before I start coding. It will be a good thing to work on while I am on my business trip to the east coast next week, while I can focus on physical objects tomorrow.
DATACENTER SHED CONSTRUCTION
My first shot at using a winch to pull the shed sideways into better alignment didn't work - the nylon strap sat across the roofline, since I could only find a natural place to hook up at the far side roof overhang, but winching downwards put so much friction on the tape on the roof that the downward resistance dominated the leftwards resistance of the shed. No movement.
I have to find a good attachment point on the shed and a good anchor point for the winch. Nothing obvious presents on the shed, but I do have a pipe secured in cement which had previously held a Dish Networks antenna years ago when it was the only way to get Internet connections faster than dial-up.
The pipe is about four inches from the side wall and ends about five feet off the ground. Not ideal, as there isn't much room to pull the shed till it abuts the pipe and there is a big downward angle if I hook to any part of the roof. Some contemplation required.
The shed is a few inches from the property line fence, which would be the right place to stick in a lever and push the shed away from the fence, except that the fence is a bit delicate and wouldn't stand up to the forces necessary. No room to put something on the ground, angling up to push against the building because of the tight clearance.
The other side, where I have to pull instead of push, has the metal pole a few inches away, but overall there is a reasonable amount of space between the shed and the wall of my house. I don't have a good point for anchoring anywhere on the Stucco wall of the house or the roof overhang.
I will try to mount a board vertically behind the pole, using a few clamps, with it extending far enough up to allow the nylon strap from the left side of the shed to stretch up to its ratchet without having to touch the rest of the shed roof. I will have to use a ladder to get up to where I will connect and operate the ratchet.
Once I tried to set the board up, I found that my roof overhand and gutter are in the way. I can extend the pole up to just under the gutter, which doesn't fully keep the nylon strap off the roof but improves the angle a lot. I set it up as best I could given the constraints.
The mast is bent over to touch the roofline, however it appears to have made no difference to the fit of the doors. The pivot for the doors is in the floor tile on the bottom and in the gable on the top. The pivot points on the floor plate are to the right compared to the openings in the gable.
Since the walls snap down into a slot in the floor plate, it seems to me that the left-to-right alignment of the floor tile is not firmly determined by assembly. It seems to be more a matter of random chance as the shed is assembled. I can see from the fit of the gable to the front left and front right wall panels that the line under the gable including two wall panels is skewed leftward.
If I can find a quick and dirty way to correct the doors, I would apply it in a heartbeat. The shed seems fine except for the terrible fit across the front especially the doors.
If I had a board about 80" long I could use a floor jack with the board to twist the lower left and upper right of the doorway, pushing the gable rightward. Of course, I don't have anything on hand that is close enough. I will wait for inspiration.
NEW KEYPUNCH PROGRAM
I want to support the file formats of the 1130 simulator, which adds a bit of complexity for the ASCII encodings. The binary format is easily converted into the KPgolem binary notation, but the ASCII based files can be in one of three encodings, called 029, 026Fortran and 026Commercial. None of these are exactly aligned with BCD or EBCDIC.
The interesting difference caused by the format is the inclusion of extended ASCII characters for ¬ and ¢ where I used ^ and [ to represent them. The files will have to use 8 bit ASCII, which is not transmissible over the link to KPgolem given its restriction to 7 bit ASCII. Not a problem, as I can map the 1130 formats to my encoding for punching, while retaining the other characters for screen and PC file use.
I am kicking around the exact way I want to support this, before I start coding. It will be a good thing to work on while I am on my business trip to the east coast next week, while I can focus on physical objects tomorrow.
DATACENTER SHED CONSTRUCTION
My first shot at using a winch to pull the shed sideways into better alignment didn't work - the nylon strap sat across the roofline, since I could only find a natural place to hook up at the far side roof overhang, but winching downwards put so much friction on the tape on the roof that the downward resistance dominated the leftwards resistance of the shed. No movement.
I have to find a good attachment point on the shed and a good anchor point for the winch. Nothing obvious presents on the shed, but I do have a pipe secured in cement which had previously held a Dish Networks antenna years ago when it was the only way to get Internet connections faster than dial-up.
The pipe is about four inches from the side wall and ends about five feet off the ground. Not ideal, as there isn't much room to pull the shed till it abuts the pipe and there is a big downward angle if I hook to any part of the roof. Some contemplation required.
The shed is a few inches from the property line fence, which would be the right place to stick in a lever and push the shed away from the fence, except that the fence is a bit delicate and wouldn't stand up to the forces necessary. No room to put something on the ground, angling up to push against the building because of the tight clearance.
The other side, where I have to pull instead of push, has the metal pole a few inches away, but overall there is a reasonable amount of space between the shed and the wall of my house. I don't have a good point for anchoring anywhere on the Stucco wall of the house or the roof overhang.
I will try to mount a board vertically behind the pole, using a few clamps, with it extending far enough up to allow the nylon strap from the left side of the shed to stretch up to its ratchet without having to touch the rest of the shed roof. I will have to use a ladder to get up to where I will connect and operate the ratchet.
Once I tried to set the board up, I found that my roof overhand and gutter are in the way. I can extend the pole up to just under the gutter, which doesn't fully keep the nylon strap off the roof but improves the angle a lot. I set it up as best I could given the constraints.
The mast is bent over to touch the roofline, however it appears to have made no difference to the fit of the doors. The pivot for the doors is in the floor tile on the bottom and in the gable on the top. The pivot points on the floor plate are to the right compared to the openings in the gable.
Since the walls snap down into a slot in the floor plate, it seems to me that the left-to-right alignment of the floor tile is not firmly determined by assembly. It seems to be more a matter of random chance as the shed is assembled. I can see from the fit of the gable to the front left and front right wall panels that the line under the gable including two wall panels is skewed leftward.
If I can find a quick and dirty way to correct the doors, I would apply it in a heartbeat. The shed seems fine except for the terrible fit across the front especially the doors.
If I had a board about 80" long I could use a floor jack with the board to twist the lower left and upper right of the doorway, pushing the gable rightward. Of course, I don't have anything on hand that is close enough. I will wait for inspiration.
Friday, January 23, 2015
Finalized documentation of keypunch interface
NEW KEYPUNCH INTERFACE DEVELOPMENT
I finished up the User Guide and uploaded it along with the latest version of everything to the KPgolem site on Github. I also made videos of binary mode punching and of reading a few cards to show those capabilities, which I posted to YouTube.
Link to video of punching binary mode
Link to video of reading cards
All that remains is to clean up the condition of my 029 keypunch and to work with my fellow keypunch owners to have them wire up their machines and build their boxes too.
I finished up the User Guide and uploaded it along with the latest version of everything to the KPgolem site on Github. I also made videos of binary mode punching and of reading a few cards to show those capabilities, which I posted to YouTube.
Link to video of punching binary mode
Link to video of reading cards
All that remains is to clean up the condition of my 029 keypunch and to work with my fellow keypunch owners to have them wire up their machines and build their boxes too.
Thursday, January 22, 2015
Polishing up the keypunch interface software and documentation
I visited the Computer History Museum mid-day Wednesday to meet with my fellow 1401 restoration team members, on top of a full day of job-related tasks, but did find a bit of time to put into the 1130 restoration anyway.
At CHM, we finally made progress on a troubling intermittent problem with the 1402 card reader on the 'Connecticut' 1401 that intermittently throws off reader checks. While most of the work in past weeks has focused on mechanical parts and adjustments in the card reader, we traced the issue to spurious additional read pulses issued by the 1401 processor that confuse the reader which has not yet completed a read cycle from the initial pulse.
This was clearly coming from the processor, but the ultimate cause is not yet nailed down. We traced the signal problems back further and further into the machine, but had to stop work when it was time for the scheduled demonstrations of the systems at 3PM. When we next work on the machine, we can trace further back to see what is causing the problem.
We see that the processor, which should be resetting the read command trigger once the cycle begins is occasionally staying active for extra cycles, long enough for the processor logic to emit additional read pulses to the card reader.
Work was extremely heavy on Thursday - never got into the garage today.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I created a punched card as an icon and assigned that to the program. I then shot a short video of the program operating and punching cards, which I uploaded to YouTube and cited in the project on GitHub. Finally, I wrote more in the User Guide, part of the interface box protocol and some of the reference information such as encoding data that users will need.
The video is here: New keypunch interface punching cards from a PC file
I spent the evening Thursday updating the User Guide and polishing the code. I had found a small problem with reading cards - which worked fine but the resultant file had spurious carriage returns added, thanks to Windows intervention behind the scenes. I made a tiny change to open the output file in binary mode, even though it is a text file containing only ASCII, because that disables the unwanted conversion of the end of line.
I spoke with one of my collaborators on the keypunch program, deciding whether to change the BCD encoding to include more BCD characters, such as Word Seperator. The main use of this mode will be the CHM accessing files they already built, which makes this a legacy compatibility mode. As such I won't extend BCD mode. If other characters are desired, they can be added on the fly using the _LOAD commands to the interface box before punching a deck that includes the additional characters.
At CHM, we finally made progress on a troubling intermittent problem with the 1402 card reader on the 'Connecticut' 1401 that intermittently throws off reader checks. While most of the work in past weeks has focused on mechanical parts and adjustments in the card reader, we traced the issue to spurious additional read pulses issued by the 1401 processor that confuse the reader which has not yet completed a read cycle from the initial pulse.
This was clearly coming from the processor, but the ultimate cause is not yet nailed down. We traced the signal problems back further and further into the machine, but had to stop work when it was time for the scheduled demonstrations of the systems at 3PM. When we next work on the machine, we can trace further back to see what is causing the problem.
We see that the processor, which should be resetting the read command trigger once the cycle begins is occasionally staying active for extra cycles, long enough for the processor logic to emit additional read pulses to the card reader.
Work was extremely heavy on Thursday - never got into the garage today.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I created a punched card as an icon and assigned that to the program. I then shot a short video of the program operating and punching cards, which I uploaded to YouTube and cited in the project on GitHub. Finally, I wrote more in the User Guide, part of the interface box protocol and some of the reference information such as encoding data that users will need.
 |
| Two cards punched by the demonstration on the YouTube video |
I spent the evening Thursday updating the User Guide and polishing the code. I had found a small problem with reading cards - which worked fine but the resultant file had spurious carriage returns added, thanks to Windows intervention behind the scenes. I made a tiny change to open the output file in binary mode, even though it is a text file containing only ASCII, because that disables the unwanted conversion of the end of line.
I spoke with one of my collaborators on the keypunch program, deciding whether to change the BCD encoding to include more BCD characters, such as Word Seperator. The main use of this mode will be the CHM accessing files they already built, which makes this a legacy compatibility mode. As such I won't extend BCD mode. If other characters are desired, they can be added on the fly using the _LOAD commands to the interface box before punching a deck that includes the additional characters.
Tuesday, January 20, 2015
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.
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.
Monday, January 19, 2015
Debugging of completed PC software for controlling the keypunch interface box
NEW KEYPUNCH INTERFACE DEVELOPMENT
I finished all the coding and debugged everything possible without the keypunch connected. I uploaded the alpha level code to GitHub to allow others to look it over. I then attempted to build a windows executable to make it easy for other project members to download and run the program without having to install Python or the various packages I used.
I did get pyinstaller on my system but the executable it produced vanishes without throwing up a GUI. I need to rebuild it with a console window and debugging, to see what might be wrong, but this is not a priority so I put it aside in order to resume testing.
At that point, I moved out to the workshop, hooked up the 029 keypunch and began testing the connection sequence and other communications between PC and keypunch. I found a few flaws and began correcting them, as well as adding some additional diagnostic output to help until I see that the communications mechanism with the keypunch works correctly.
One example of the bugs is that the Arduino returns \r\n for every line, carrier return followed by new line, while we were looking only for the newline at the end of a line. Now we drop both the terminating characters if it is CR NL, otherwise just the NL.
I ended the evening with solid communication between the keypunch interface box and this program, leaving me the opportunity to try out one test output file which I put together for the purpose. It punched properly except I was off by one on the card being punched (due to origin 0 used on the language arrays but origin 1 used for human counting of cards in a deck).
I had a few other small errors to work on, but I do see that the essence of the program is correct. I discovered some odd characters in the stream, which turned out to be XON and XOFF flow control characters, because I forgot to put my pySerial port into software flow control mode where it would strip these out automatically.
I will do some cleanup and resume testing tomorrow, when I hope to be able to deem it ready to release as a beta version. I had made a few minor improvements to the Arduino code as well, which I should also upload to Github.
I finished all the coding and debugged everything possible without the keypunch connected. I uploaded the alpha level code to GitHub to allow others to look it over. I then attempted to build a windows executable to make it easy for other project members to download and run the program without having to install Python or the various packages I used.
I did get pyinstaller on my system but the executable it produced vanishes without throwing up a GUI. I need to rebuild it with a console window and debugging, to see what might be wrong, but this is not a priority so I put it aside in order to resume testing.
At that point, I moved out to the workshop, hooked up the 029 keypunch and began testing the connection sequence and other communications between PC and keypunch. I found a few flaws and began correcting them, as well as adding some additional diagnostic output to help until I see that the communications mechanism with the keypunch works correctly.
One example of the bugs is that the Arduino returns \r\n for every line, carrier return followed by new line, while we were looking only for the newline at the end of a line. Now we drop both the terminating characters if it is CR NL, otherwise just the NL.
I ended the evening with solid communication between the keypunch interface box and this program, leaving me the opportunity to try out one test output file which I put together for the purpose. It punched properly except I was off by one on the card being punched (due to origin 0 used on the language arrays but origin 1 used for human counting of cards in a deck).
I had a few other small errors to work on, but I do see that the essence of the program is correct. I discovered some odd characters in the stream, which turned out to be XON and XOFF flow control characters, because I forgot to put my pySerial port into software flow control mode where it would strip these out automatically.
I will do some cleanup and resume testing tomorrow, when I hope to be able to deem it ready to release as a beta version. I had made a few minor improvements to the Arduino code as well, which I should also upload to Github.
Subscribe to:
Posts (Atom)