Dead end with plotter drum fix, but moving ahead on GUI restructuring

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Debugging the resilient high speed link between fpga boards

This is going to be a priority since I can't properly test my paper tape interfacing if the link to the slave fpga board isn't solid. Since I am restructuring the entire GUI program at the same time, I have to keep the 'old' GUI around in order to do the link testing.

Restructuring the GUI

I began moving code from my old GUI program to the new MVC model. The device functionality is the most straightforward to move since it is closest to the model pattern. First up was the virtual 2501, but I ran into design problems stemming from how Python deals with dividing a program into multiple files. In that scenario, there are no global names.

Design is everything with OO code, and then refactoring will clean up the program even more. Since I will build this out of many classes and separate modules, I will put in testing for each bit I build in order to validate how it behaves. This will be faster than completing the entire program and then debugging complex functions such as virtual peripherals.

Another dimension to designing this is the use of threading for the various peripherals. The code that communicates over the USB and to PC based files is in a separate thread per device. However, the GUI interactions have to occur in the main thread. Thus the View part of each device is running in the main thread and getting notifications from the Controller and Model in the device thread.

The challenge exists of updating data in the Model since the requests come from the main thread during some GUI interaction but have to change data that is also being manipulated independently by the device thread Model. I have to figure out a solid thread-safe method for doing this.

I came up with a few methods for this:

1. Use Queue which is thread safe
2. Introduce interlocking protocol and data fields that are globally accessible
3. Stage changes via device methods and use a lock to control collisions

I chose method 3 where I will provide a method to set up a change, add a method to look for existing requests, have the main device loop look to see if there is a pending change, and use a lock to ensure that I can't lose any changes. To do this in the best spirit of Python, I should factor out the code and generalize this so it can be used by all the device handles with minimum duplicated code.

I created the generalized approach and piloted it in the virtual 2501 model, where it looks like it will work fine. Now I have to work on the controller and view modules for the virtual 2501, to process the file open, mode setting, and boot button events and to properly display the status in its window.

RESTORING CALCOMP 565 PLOTTER

I drove over to the Service King auto body repair shop which advertised that they worked on aluminum car parts, but when I got there they told me that they didn't have the specialized tools to work on aluminum and would instead send that work over to their Fremont location. Wasted trip, have to drive over to Fremont later.

I spoke with them on the phone and was told they would not consider a small job like this. At least I saved the time involved in a drive. Time to look for some alternatives.