Part 5 - In The CMM Marketplace, Perception Is Reality

The way in which products are developed and the way in which they evolve is not always as straightforward, clean, and logical as we would like to believe it to be. Still, we endeavor to do the best we can and trust that in the long run we will prevail.

We must take heart in knowing that our competitors are subjected to similar peculiar situations.

In 1967, when Sheffield first began pairing a CMM with a computer, the computer chosen for the job was the PDP-8/S model by DEC (Digital Equipment Corporation). This computer was the first computer system commercially available for under $10,000. The computer itself was organized around a 12-bit word. That is, each memory cell contained 12 individual bits of data.

For those who do not know, one bit can store only the information that it is on or that it is off. These two states (on and off) are typically assigned a value of 1 and 0 for easy reference but a computer programmer can assign them to mean anything desired. For example, they could be assigned meanings of hot and cold, up and down, greater than 100 and not greater than 100, etc. Much of what a computer programmer does is to assign meanings to bits in the computer's memory and write a program that processes information using those assignments.

Just as today, the computers back then progressively provided ever more bang for the buck. Little by little they grew less expensive while at the same time growing faster and more powerful. The DEC PDP-8 line accumulated new models one after the other, most of which were paired up with the CMMs at Sheffield as they became available. The main reason for staying with this line of computers was that while the newer computer models ran faster, they were organized around the same 12-bit memories as before and were capable of running the same programs as the earlier PDP-8 models. That is, they were "backward compatible".
Over time at Sheffield we continued to build on our library of computer programs and to develop ever more diverse and advanced programs for the PDP-8 line of computers.

Sheffield's engineering personnel were divided into two groups. One group was referred to as R&D whose primary function was to develop new standard products. The second group was an application engineering group. This group developed systems for custom applications. By 1973, all of our software engineers (there were three of us by then) had been moved to the R&D group. Although our little software department also wrote some custom software applications when needed, we were writing and maintaining all the standard CMM software products. Over the course of the next few years more software engineers were added to keep up with the increasing demand for software products.

One day around 1974, we in the R&D engineering group were given a message from our marketing folks. Our competition had begun using other models of computers that were not organized around 12-bit memories. They were using computers with 16-bit memories. The advertising brochures from our competitors indicated that their CMM computers and software were better than ours because their computers used more bits than ours. The message from our marketing folks was that we needed to change to a computer with 16 bits to keep up with the competition.

We engineers tried to counter the message with several arguments. One argument was that we had too much time and money invested in developing our existing library of CMM software packages which would all be useless if we made a switch to a different line of computers. Another argument was that the number of bits being used does not tell the whole story about the capability of a computer hardware and software system. After all, our CMM systems were out-performing those of our competitors, even those who were using 16-bit computers.

In the end, apparently perception is reality and so the force exerted upon us to change to a 16-bit computer line over-powered our arguments and we began developing an entirely new line of systems built around the 16-bit DEC PDP-11 line of computers. We bent over backwards to squeeze as much software capability as possible out of the new systems. We wrote a new high-level CMM language called BMIL which was modular, powerful, and as memory efficient as anything we had ever done.

Unfortunately, a parallel in-house project involving an ill-fated industrial robot based on a different 16-bit computer forced our electrical engineers into trying to build a single interface system suitable for use with either a six-axis industrial robot based on one 16-bit computer or with the three-axis or four-axis CMM systems based on the PDP-11 line. While there may have been some savings in engineering costs, the dual purpose interface electronics proved expensive to build.
One notable improvement that came with this generation of software and hardware was the use of software driven axis displays. Starting at this point in time it was then possible to have a CMM system that displayed the probe's position in part coordinates instead of machine coordinates. The displays could also be used to prompt the operator and serve a few other purposes.

That software and hardware interface combination proved too expensive to displace our own PDP-8 based manual CMM product line. So for several years beginning in 1975 we were selling servoed CMM systems based on the PDP-11 line of computers along with manual CMM systems based on the older PDP-8 computer line. To top it off, the two systems were totally incompatible with regard to part programming. We certainly could have done a better job of dealing with that issue at the time.

At about this same time microprocessors were beginning to invade the newest engineering designs. One small processor line, an 8-bit microprocessor developed by Motorola, the MC6800, was soon designed into a new type of product from Sheffield, a self-contained Measurement Processor, or MP. The firmware in the first model performed only very primitive CMM measurement functions. (Note: Firmware is simply software that is stored in ROM (Read Only Memory), that is, memory that cannot be rewritten by the computer.) It was roughly equivalent in its scope to the original Cordax Measurement Monitor software for the PDP-8/S in 1967. A couple more models followed, still based on the same MC6800 processor, each with more advanced functionality. All of these MP units were limited to use with manual CMMs and were unable to be paired with a minicomputer.

By 1977 or 1978, just as before, our marketing folks came to us engineers with a new message. Once again based on the not-always-logical pressures of the CMM marketplace, the new perception was that a CMM system was not as good as it could be if it was not based on a Hewlett-Packard computer system.
We began surveying the HP computer offerings that seemed most appropriate for our use. The most logical entry was the HP-9835 computer which was programmed in HP BASIC. We conceived how this computer could be used to store and execute part program steps for CMM inspections. The biggest problem was that the computer was too slow for performing the high speed real-time operations necessary for the actual control of a CMM's servo motors and other functions. If this computer line was to be the basis for our next generation of CMM controls, there would have to be more real-time computing power coming from somewhere. The obvious answer was a microprocessor-based controller.

Since we already had experience with the MC6800 series of microprocessors, it seemed like the place to start. We wanted to have a controller arrangement that would prove competitve on a manual CMM but which could also be expanded to permit it to run three or four axes of CMM servos. We also wanted some sort of handheld controller for the user right at the CMM when it had servos.

My boss and I huddled over a large sheet of paper and began to work out how many of these little 8-bit microprocessors it was going to take to do all the work in all the right places. Soon there was a block diagram that delegated the various functions across six MC6800 microprocessors. Those of us who had not been directly involved with the development of the MC6800-based MPs, began to familiarize ourselves with the software development system that would be needed.
Within a few weeks, there was placed before each of us a non-disclosure agreement for us to sign. That allowed us to see advanced information for a new type of microprocessor, the Intel 8086. Not yet on the market, this was to be a 16-bit microprocessor. It had a fairly high clock rate and could handle a much larger address range than the MC6800. It also featured many more registers and was clearly a better match for most of our needs. It even came with a software package which performed floating point arithmetic. We began to rework our block diagram and soon decided that two controllers each based on a single Intel 8086 microprocessor plus one MC6800 family processor in the handheld control unit would meet all of our needs.

One software engineer was assigned the job of writing the firmware for the controller that would operate a CMM's servos. Another software engineer was assigned the job of writing the firmware for the handheld RCU (Remote Control Unit). Another software engineer and I were assigned the job of writing the firmware for the primary CMM controller. This controller, to also be called an MP, managed the CMM's axis counters, drove the LED axis displays, took measurements, performed coordinate transformations, scaling, and translations, as well as many other lesser tasks. I was assigned to take the lead in the MP's firmware development.
One software engineer with many years of experience who had been transferred to our facility from a different division was assigned the job of overall system engineer. He was to write a system specification describing how all the new system's elements were to interact with each other and describe how the system was to be tested.

Meanwhile, due to the pressure to get the project moving as quickly as possible, we were all told that based on our own CMM development experiences of the past, we should be able to begin designing the more obvious parts of the system. Work began to progress at a furious rate.

The engineer with the task of writing a system specification was having a difficult time getting anywhere. Eventually, he was relieved of that duty and I was told to take on an additional role as the system engineer. That sounds like pretty hot stuff but in actuality it just meant writing a compact document which stated the communication standards to be obeyed by all the system elements when communicating with each other. With few exceptions, most of us instinctively knew how such communications needed to be done. It also meant that when other engineers had questions about how certain CMM-related processes were to be delegated to the various system elements, I was the fellow who was stuck with choosing the answer from the possible ways that it could be done.

When we first began to work on the firmware design for the MP, one complication that arose was that the existing arithmetic software package proved entirely too slow for our real-time needs so we set about writing our own floating point arithmetic package geared for maximum speed.

At home, I had been playing with two Commodore PET home computers quite a lot and had read about some of the clever aspects in the design of that computer's floating point arithmetic package which was embodied in its firmware. Soon, some of those clever design aspects were being combined with our own creative efforts and coded into our own arithmetic package. We also threw in a few details of what we had learned from the DEC PDP-11 software designs.
As our detailed firmware design flowcharts for the MP were coming together on paper a bright young man who had worked in our area in the past while he was a student was hired full time. We began handing him our flowcharts as we finalized them. He began turning them into the countless computer instructions for the 8086 microprocessor. As we finished up the last of the flowcharts, all three of us were writing such code.

To squeeze maximum execution power out of our little system, we had created a multi-task operating system within our 8086-based unit which doled out computing resources as necessary in accordance with many levels of priority assigned to all the various software tasks from the fastest which were executed some 500 times per second to much more leisurely activities that only ran every few seconds or only when requested.

We also included some advanced startup operations that could help a technician know if an incorrect or defective ROM chip was installed or installed in the wrong socket. It also supported another feature to allow add-on ROM chips to replace processes in the standard firmware with specialized versions of them or to add entirely new processes to the system. The software tasks in such add-on firmware had full access to the communications and arithmetic capabilities of our little operating system.

When we were finalizing the design of our operating system, communication subsystem, and floating point math package, the software engineer in charge of the servo controller borrowed them to use in his 8086-based servo controller.

The ability to add new software tasks proved very useful in solving a serious complication that arose fairly late in the design of our firmware.

The marketing folks had decided they wanted a less expensive manual CMM system based on a new smaller HP computer called the HP-85. This computer had come out of an entirely different group within HP. It did not support near as much memory as did the HP-9835. As a consequence, the software engineer who was trying to code FLB (the Function Library) into this smaller machine just could not get it to fit into such a small computer. The purpose of FLB was to do part program oriented work such as data reductions (eg., geometric best fit operations), geometric constructions (eg., find the intersection of a line and a plane), measurement taking (eg., prompt the user while taking eight points scattered over a plane), produce formatted inspection reports, and more. When this crisis arose, we explained to the troubled software engineer how to code tasks into expansion ROMs for our controller and he proceeded to move much of FLB from the HP-85 into our MP controller without affecting anything we had already designed. From the point of view of any of our software tasks, it did not matter whether directives were being sent from the HP computer or from a software task running in the same system as they.

The HP computers did have one unusual characteristic. They were chiefly oriented toward communicating with their peripherals via a parallel bus called HPIB (Hewlett-Packard Instrument Bus). Also called  IEEE-488, this comprised the communication link between the HP computer and the MP. As originally conceived, the MP was intended to support both HPIB and RS-232C serial communications. However, when time began to run short, the apparently unecessary firmware for supporting the RS-232C serial interface was cut from the project. The hardware interface was still there but the MP just ignored it.

This brings us up to the latter part of 1979. The HP computers and their new software as well as the firmware for the MP and for its companion servo controller and for the new RCU were all about to be mated with all the new corresponding hardware prototypes so that testing and debugging of this fine new generation of CMM controls could begin. I had no way of knowing that fate was about to step in and give my software development career a big unexpected twist.