Wow, how the world can change in just a few months. And each of us have had to adjust to the changing times. We at Cal Lab Solutions decided to start a Metrology Automation Lunch & Learn and so far, we have completed three of them in the past six weeks.
This was an idea I had last year at NCSLI in Columbus, Ohio. Talking to other automation engineers and managers, we all thought it would be a good idea to virtually meet up once or twice a month and discuss how to write better metrology software. So thanks to COVID-19, we had free time in our schedules. I hope this will continue well into the future.
The first Lunch & Learn we did covered how Cal Lab Solutions writes flexible drivers in Fluke’s MET/CAL® platform. We have been using this driver model for more than 18 years. I firmly believe it is the best way to support flexible standards in MET/CAL—especially when you have a good revision control tool.
The interesting thing in that Lunch & Learn was how this 18 year old driver model is very similar to much of the work we are doing with the NCSLI 141 Metrology Information Infrastructure and Automation Committee. The concept of writing drivers around metrology functions, instead of equipment types, has lasted the test of time.
The next Lunch & Learn focused on drivers in an OOP (Object Oriented Programming) language. Unlike write drivers in an antiquated scripting language, in an OOP language like VB.NET, child class functionality can be inherited. This allows the programmer to write code once and share it with several specialized parent classes.
For example, in Metrology.NET® drivers, all the I/O calls are contained in the instrument base class. If you want to send a command to an instrument you simply write Me.Write(“*RST”). All the I/O pointers, VISA Resource strings, and multi-threading tools are all contained in the base class.
We also covered how ISO/IEC 17025 uncertainties can be managed without having to update the automation scripts, all done in the base class. This allows the automation engineer to focus on writing better automation and the metrologist to manage uncertainties.
The third Lunch & Lean focused on Control Charts. As this is something I am currently adding to Metrology.NET, I thought it a good idea to share with the community and get some valuable feedback.
We reviewed a control chart for a Fluke 742-1 resistor that had been calibrated six times. Using an Excel file as a reference, we converted all the mathematical functions to a VB.NET class called “ControlChart.” This allowed us to load the ControlChart class with all the calibration data in the Excel file and validate the math in the class.
When evaluating the VB.NET class compared to the Excel file, it became apparent the VB.NET class was easier to support and maintain than the Excel File. The problem with the Excel file is every time a new calibration data is added, some of the fields have math statements that need to be updated to include the new calibration data. Whereas the VB.NET code has a List(of CalData) object that holds x number of points. In the VB.NET code all you have to do is add more data and all the calculations adjust automatically.
We plan to do more Lunch & Learns and hope that other engineers in the community would like to show all of us some tips and tricks. If you have knowledge you would like to share, please feel free to email me MSchwartz@CalLabSolutions.com. For those of you who missed the first three Lunch & Learns, they are available on our website: https://www.CalLabSolutions.com.
Note: the ControlChart Class will also be made available to the metrology community. It’s about all of us creating better software.
