I talk to many people about how long it takes to write an automated calibration procedure in various languages. Also, as a manager, I know just how bad developers are at estimating their own time. Unlike Scotty from the Starship Enterprise, software developers are notorious for underestimating the time required to write something. This is why I want to share some real-world numbers.
Last week, while I was onsite training CalRight Instruments on how to create test packages in Metrology.NET®, one of their younger technicians created three new test packages for the Keithley 2700 DMM, 7700 & 7701 Plugin Cards in less than three days. This is truly impressive for a technician, who has never written automation before, to have written and tested three units with an average time of about six hours each.
We started the training with our standard training package based on Keysight 34450A DMM calibrated with a Transmille 4010 Calibrator. Covering this training usually takes about four hours, and that is how we spent the first four hours on day one of the training.
After lunch, we moved on by selecting a DMM currently in for calibration, grabbed the manuals, and then started the training. Vince, the technician, was able to create his first test package in the second half of the first day. Before the end of the day, he successfully tested the Source.Voltage.DC test points on the 2700, ending the day on a high note.
On the morning of the second training day, Vince continued testing the 2700, and around noon, the Test Package’s VISAScripts (used to control the UUT) were thoroughly tested. So he asked his boss, “What’s Next?” David’s reply: “Do the cards too.” Before the end of the third day, both cards were finished and fully tested.
During the training, there were challenges and rewrites to the test package. The first challenge with all automation is figuring out the commands and how to control the UUT. This step is especially difficult for technicians who have never remotely controlled a device with SCPI commands. But part of the training is showing people how to use the manual(s) and look up, then testing the commands. There is a lot of trial and error, beeps from the instrument, closely looking, and the command for typos.
When starting on the second card, we discovered that the second card’s test points were 90% the same as the first card—the test package he just built and tested. This led to a rewrite of the first test package, updating it to support both cards in a single test package using the “AppliesToModel” parameter. Rather than copying all the test points and data into a second test package, Metrology.NET® uses “AppliesToModel” and other filters to sort and filter test points, allowing a single test package to cover several Make, Model, and Option configurations.
This rewrite of the test package took a little more time because the concepts were new to Vince, but well before the end of the third day, all their units were tested and ready for QA.
Manually testing these three units would have consumed approximately five hours of a technician’s time. Remarkably, in roughly triple that duration, a technician unfamiliar with automation successfully developed their initial automated calibration procedure, aptly named “Now That’s Fast!”
CalRight Instruments has contributed these three test packages to the Starter Pack, making them the fifth company to offer test packages in the Metrology.NET® Test Package Store. This is great news for the calibration community.
