Embedding Linux for Instrument Control: a Case Study

Our project was to develop an instrument for measuring viscosity in anode paste for the aluminum industry. The mechanical and electrical hardware requirements were carved in stone, as the instrument was to be built on an existing design. Our job was to design a new version of its computing part to replace the earlier incarnation built on a 15-year-old Siemens microcontroller. The complete theory behind the instrument is given in Knut Torklep's ``Viscometry in Paste Production'' (Light Metals 1988), but in short it works as follows.

A sample is placed between two plates, and the upper plate is then lowered by hydraulic pressure. The speed of the upper plate, the force on the lower plate and the temperature are all determined during the measurement. Every ten seconds the immediate viscosity is calculated and shown on an LCD screen. Finally, the calculations are run again with the average of the measurements as in-parameters, and the final results are displayed on screen and optionally as a printout.

The specifications for the system were fairly simple: control relay switches, read voltages, perform calculations and present the result to the user with as little user interaction as possible. For normal operation, the user should only have to use two push buttons on the front panel of the instrument, one for resetting the weight and another for starting the measurement.

Some settings are rarely changed in the instrument, which has a calibration routine for the position sensor. The operating environment is more challenging, however. The instrument must be dust-proof, as there are large amounts of conductive carbon dust in the air around it. It also must be reliable in ambient temperatures from -20 to +70 degrees Centigrade and may be required to operate in magnetic fields of 150-300 Gauss or up to 0.03 Tesla.

The weight sensors are critical in two respects: they are extremely sensitive (an accuracy of 1 gram with a span of 750kg) and may be subject to vibrations. The only way to compensate for this is to measure the weight over an averaging period longer than that of the vibrations. Other requirements must be taken care of by the hardware implementation. Vibrations exclude using any moving parts, particularly hard disks, which are unreliable over time in such magnetic fields, even with heavy shielding. High-speed processors also do not work in such environments. The reason for this is unknown, but we have established that Pentium-II class and newer CPUs do not work reliably in such magnetic fields without heavy shielding. Even with such shielding, they prove unreliable over time.

We have some experience with roll-your-own OSes written in assembly, as well as with GUIs and data acquisition systems (DAQs) under Windows NT. Neither was particularly suited for this project, however. The roll-your-own approach would have entailed too much work; copyright law prevented us from using customer-owned systems we'd previously developed, thereby requiring us to start from scratch. The time hardly seems ripe for writing a new embedded OS today.

The GUI approach simply did not fit the bill when we considered reliability and simplicity. The viscosity measuring instrument is built for heavy use by people who have other things to worry about than navigating window-based user interfaces.

So we decided to use an embedded distribution of Linux and write the application in C. In most embedded applications there is little benefit in using C++ or other OO techniques because the application normally is small and simple, and one has more or less complete control over the hardware.

We were essentially new to Linux. We do have a web server running Apache under Red Hat 6.2 and have used various flavors of UNIX over the years. However, we fell into the trap of abandoning UNIX in the early 1990s when it seemed these workstations were losing the battle. Thus, we started from scratch on the OS (not to mention embedding the thing).

We decided to use NuDAM modules from Adlink Technology (http://www.adlink.com.tw/) for the I/O. These modules are fairly robust, support any conceivable configuration of analog and digital I/O and can be daisy-chained on an RS485 network. Since space was not a primary concern, we decided on a single-board computer from ICP Electronics rather than one of the smaller solutions. The board was equipped with a Cyrix 486-class CPU, sufficient processing power for our purposes. For storage, we decided on an IDE-compatible 2.5" Flash disk rather than the disk-on-chip solution. The application was not to be networked, but we did put in a floppy drive for upgrades. This hardware solution corresponded closely to a normal standalone PC while still fulfilling our requirements. We felt this solution would minimize embedded-specific problems, allowing us to focus on the problems we knew would arise from using a largely unknown platform.

We decided to purchase all the equipment from one supplier because we thought this would provide some degree of interoperability. Unfortunately, when we needed some support later on, this perceived benefit was outweighed by the fact that our supplier turned out to have even less experience with Linux than we did. This left us with the unenviable task of figuring a lot out on our own. I strongly suggest you verify that your supplier has some real experience with using Linux before purchasing.