Ever since I got into the metrology field, I have witnessed several changes related to how we interface with the test equipment. In the 1980s, there was very little automation; all the standards I had in my lab had a manual interface. Then shortly thereafter, computer control instruments started appearing on the market with RS232 or HPIB/GPIB interfaces. Now, the computer could send the instrument a string of information that instructed the setting on the instrument. This was great—what could take several minutes could now be accomplished in milliseconds.
Today we are in the midst of another great change in instrumentation with software based instruments. As computers, memory and buss speeds get even faster, so are the capabilities of our instrumentation. One project we worked on last year we were able to take 64k samples of data and compute an FFT, then average 32 FFTs, measure the average power in 5 frequency bands, and return the results in just over one second!
To me that was amazingly fast, but it presented a problem: How is a calibration lab going to support the new instruments and all the old instruments in a single platform? The industry needs a support strategy that covers all metrology disciplines and all forms of instrument control—manual, command, and software based instruments. Each of these interfaces presents a unique challenge in software and how we design the next generation of metrology software.
One would think a manually controlled user interface is the easiest of all the interfaces to deal with, but it’s not. To me it is the hardest and most problematic to deal with. First you have to give clear and concise instructions to the operator on how to properly set up an instrument. The operator has to understand these instructions and properly execute them. And in the end, you have no way to verify the instrument is set up correctly. You have to trust the operator’s skills level.
Many years back I had the opportunity to run some scope calibration software from Tektronix. They did a very interesting thing by programming all the settings into a state machine. This allowed the technician to see only the settings he needed to change from one settings state to the other, or see all the settings on the instrument. I really liked the usability of feature and have used it in many of my solutions.
Command controlled instruments are the most common instruments we see in the calibration lab. They are simple and relatively easy to program. Most are VISA, RS232, IEEE 488.2 or LXI compliant which function on the same basic principle of text based commands. These instruments are relatively easy to interface with so I will not go into much detail.
Newer, software based instruments are for most calibration technicians much harder to interact with and control. Some manufactures like National Instruments and Keysight Technologies have done a very good job at providing users with drivers.
These instruments are designed to be installed in a dedicated system and present themselves as being fast and inexpensive compared to traditional equipment. They usually have a dll, COM Object or some other type of driver library that is directly called from the software installed on the system. This is great for the system and the end users, but it is difficult for the calibration lab to support, mostly because the calibration of modular instruments usually requires it to be moved into another calibration system owned by the calibration lab. This in itself is not huge problem, but to support these modular instruments the calibration lab has to own several different systems—one for each type and generation of hardware they are supporting.
One area where we can update and improve upon is how we interface with modular/software based instruments. Just because the manufacturer didn’t provide a text based, command interface for the instrument doesn’t mean it can’t be easily added. A relatively simple program can be written and installed on the same system with the software based instrument. This then allows the instrument to be called remotely—similar to how you control GPIB instruments. It is worth reading “An Enterprise Resource View of Metrology Software Systems,” a paper I presented at NCSLI on how to do this in MET/CAL® and check out www.Metrology.NET™, a system-of-systems approach to metrology.
Software based instrument as well as manually controlled instruments both present very different challenges when it comes to how we interface with them through our software. When we are designing our software and automation we should keep in mind that not all instruments will be controlled with text commands. Making allowance for both extremes will be beneficial in the long run.
