While it would have been perfectly possible to write an MSc thesis based purely on literature search, theory and analysis it is always nice to do something practical. My supervisor said that the university had been given an old conveyor system by IBM which was currently dumped in the corner of one of the laboratories. He said there was a long-term goal to assemble a group of machines that could work together as a demonstration machine cell set up around their Rediffusion Reflex Robot. Perhaps I could have a look at it?

Going down to the basement laboratory I found the conveyor still linked by its heavy umbilical cable to a rack of control gear. Alongside was a pile of bits that had been slowly growing smaller as they were 'borrowed' for other projects. As there were no drawings or any other information I opened up the rack and found a cage with various discrete logic boards in it. In the base of the rack was a star/delta transformer and a panel with various solid-state relays and contactors. It would have taken too long to try and work out how the discrete logic worked - if it still worked. However it was easy to demonstrate that the track motor and auxiliaries operated when their relays were energised. So if a new control system could be fitted between the existing control panel and the relays the conveyor could be brought back to life.

Various industrial controller from the 'famous names' were surveyed - and their high prices noted! Fortunately I found a small modular computer system made by Warwick Designs - CHUM 1 for a total price of £250. Would the university foot the bill?After a bit of muttering about meagre university budgets my supervisor agreed to find the money. We now had a project which would discuss the theory of interfacing machine tools to computers and give a practical demonstration involving the conveyor and the robot.

The first practical difficulty was that the conveyor and the robot at that time lived in two different laboratories. Another problem was that the robot was jealously guarded by a PhD student! However right next to the conveyor was a line of BBC B computers that were available for student use. One of these could be used to simulate the connection to the robot.

Once we had got the CHUM and its Input/Output modules wired into the rack the next step was to connect the CHUM to the BBC B and get to grips with the programming. The hardware was straightforward, just a simple RS-432C cable connection. Getting the BBC to speak to the cable took a little while to sort out as it involved using the correct commands to the serial interface with the arcane "*FX" statements peculiar to the BBC B that are not well documented. After a few trials; ignoring what it said in the manual; stealing from 'working routines' I found a sub-routine that worked and I was in business.

As computers go the CHUM was not very big. Its instruction manual wasn't very big either and it left out a few things that it would have been nice to know early on. One such thing was the fact that each line of code was probably 'tokenized' and took up a fixed block of memory. All of the examples in the manual showed simple programs using the conventional line numbering used in the BASIC language, i.e. 10, 20, 30 ..etc. Perfectly correct but it would have been nice to know that CHUM was reserving space for all the missed lines in between! Suffice it to say that if convention was followed the limited memory space was reduced to a tenth of its actual size by all that reserved space. OK if you have 1Gb to play with but not if you only have 2k!

The result of that discovery was that I ended up writing 'expand' and 'compact' routines on the BBC that could 'open up' a CHUM program for modification and 'close up' the program for download to CHUM. About that time I discovered a little habit of the BBC that I might not have found if the CHUM had been bigger. CHUM restricted variable names to the letters A#-Z#, where # could be null or numbers 0-9. I had been getting on well with the main CHUM program which was nearly complete. Just as well because I had the thesis to write up and exams to pass. Then it all went wrong. Code lines simply went missing. Where had they gone? Of course the first place you look is around the place that you put them. When you can't find them you re-write them. Now you know they are there. Then they go missing again. Not funny.

Time was getting short and I set myself targets like if it wasn't fixed by Wednesday I would abandon the routine and do something else like writing code close-spaced. In the event because the routines were so useful I over-ran my self-imposed time limit so as to fix the problem. It turned out that I whenever I used the variables E0-E9 the BBC stuck its own little oar in, (something else not in the manual?). The BBC decided that E0 really meant 1, E1 meant 10 and E2 meant 100, a form of scientific notation. So if I wrote something like:

20 E2=5
30 F1=9
40 J1=11

this became:

20
30 F1=9
40 J1=11
100 =5

and after compacting:

1
2 F1=9
3 J1=11
4  =5

Of course in practice the lines represented by 30 and 40 could be a major block of code and the remains of the broken line 20 would then be well separated. After this problem was fixed, the thesis written up, the degree awarded and I left, the robot went to live with the conveyor. I wonder if they ever did get to speak to each other though?