I recently visited one of my largest customers. They have a huge internal self-maintainer calibration program and years ago they decided they wanted to get all their calibration system on a single platform.
They went from having one metrology engineering position to four metrology engineers today. But I noticed their ratio of engineers to technicians had changed. Before, they had one metrology engineer for five technicians. Today, they have one engineer for every two technicians. Why such a change in the ratio?
So, I asked what they were doing. “The current project was to rewrite a bunch of procedures because they have the new Fluke meter.” I then asked how they were doing this. Their answer was “We open up the current procedure, copy it into the new project file and go through changing all the commands. We keep the original procedure in case we need to use it if the meter is out for calibration.” I asked “So if you find an error or a specification change in the UUT you have to fix it in several places?” Their answer was “YES.”
This is an example of software that is NOT SUSTAINABLE! Lab managers, if your staff is increasing because your code base is increasing exponentially, your software development effort is not sustainable! You need to rethink the investment in your software development efforts.
The root cause of the problem is: Every line of code you write is a line of code you have to debug and support! The hidden cost (i.e. the REAL COST) of software is not in the development of the software, it is in the support and maintenance of the code.
In school I had some amazing instructors. One taught part-time, because his day job was writing code. He always said “This is what will be on the test; this is a better way to write the algorithm and why.” But the most import thing he said was “Anytime you want to copy and paste something, think again, then write a function and call it. Because, now that you have less code, if there is a problem, you can fix it in one place.”
So, back to my customer. I understand their problem; they don’t have the time to design a better solution and need to get the new DMM integrated and product going out the door. But by doing this, they are trading a short-term gain and creating a long-term problem!
What’s the solution? To be honest, I don’t know the perfect solution, but I do know what works for us at Cal Lab Solutions. We have the world’s largest library of MET/CAL® procedures and don’t spend a lot of time doing technical support. What we did to support all the UUTs using all the possible standards was architect a development methodology using Object Oriented Programming principals.
We write ONE piece of code for the UUT and ONE piece of code for the standard, and then link them in a _Config Sub Procedure. A little confusing at first, but if you download the free procedure for the Agilent DSO-X3000 scopes from our website, you can see how a single UUT procedure works with a Fluke 5520, 5820, 9500, even a Fluke 5700 and PSG. That one file—and good architecture—makes it all work.
The driver method we created 20 plus years ago in MET/CAL® was a great step forward in the progress towards sustainable software. It was a good foundation to build on, but it has limitations. For one, it only works at compile time, meaning all the standards have to be known when the automation is written. And two, it only works in one language. These two limitations are bad for sustainability.
As I said before, I don’t have all the answers to sustainable metrology software, but I have been writing automation for 25 years. I have learned what works and what doesn’t. Big long monolithic scripts in MET/CAL®, LabView® or any other language is a bad idea. Modularity is the key. We proved that with our MET/CAL® procedures, by creating the largest library in the world, with a fraction of the people.
Now with Metrology.NET®, we are taking another big leap forward on the evolution of sustainable software for metrology. The demo we did at this year’s NCSLI Workshop & Symposium showed the new Fluke 8588 calibrating AC Volts on the Fluke 5522A. It’s not a 4 to1 TUR, but it took less than two weeks to write the driver. And, it worked calibrating the 5522A with absolutely zero code changes to the 5522A test package. Now you can use the 8588A anywhere you used the 3458A, 8508A, 5790A, LCR Meter, etc., and do it with one engineer… way more sustainable!
