Page 57 - Practical Control Engineering a Guide for Engineers, Managers, and Practitioners

32 Chapter Two

source code but since I did not have the software system expertise to
link everything together I had to create quite a brouhaha to get the
necessary and scarce software resources in time for the bring-in. I
was careful not to castigate Bill when he came home blithely
exhausted and nearly penniless. Because of the stink I had made
about getting software resources, his return was less than pleasant.
Ironically, about 15 years later Bill became my boss for a short
time-we got along swimmingly.
In retrospect, I was at fault as much as anyone. I should have
consulted closely with Bill. Unfortunately, the approach of the soft-
ware-engineering arm of the instrumentation and control group, of
which Bill and I were members, had been to code, compile, link, and
turn on the data acquisition and control software. If the computer did
not crash at that point then they "shipped it." Unfortunately, this
experience did not have a major impact on the managerial approach
of the company's software-engineering arm and this kind of nonsense
continued for quite a while.

Totally Covering Myself
After several more years of avoiding major installation projects and
doing fun process analysis and control design projects in our manu-
facturing plants I stumbled onto a project in the research wing of the
company where I got a chance to design and, with the help of a great
team and a great team leader, install a nonlinear dead-time compen-
sation control algorithm that was later patented. It was for a batch
process where we started with a "blank" of material, heated it, and
formed it into the final product. A batch run would take approxi-
mately an hour and consume the blank, which was quite expensive.
After some initial fumbling around we got to the point where I
would cook up the latest modifications to the algorithm (it went
through some 200 versions before we finally installed it in a manufac-
turing plant) on my desktop computer terminal as a FORTRAN (and
later, C) subroutine. I would link the subroutine to a FORTRAN (and
later C) test program of my design, also accessed by my desktop ter-
minal, which simulated the inputs to the process and put the control
algorithm through an approximate start up. The process model
embedded in my test software was purposely crude and simple but
in a qualitative sense it behaved roughly as the real process and it
made my algorithm jump through the correct hoops.
After verifying that my algorithm would bring the simulated pro-
cess up properly, I would e-mail the subroutine to my software team
member, located at the research facilities. He would link it to the on-
the-floor control minicomputer. Unfortunately, the control computer
was used by many other scientists and the software guy always
seemed to have trouble with the linking. It appeared that the only way
to find out if the linking had gone well was to start the batch process
up and see if things worked. (Some alarm bells should be going off in