Automated cal software

guy48065 · 05-10-2016 -- 12:04:17

I am a 1-man self-supporting cal department for a medium-sized product testing company.
We recently upgraded my main calibrator to a Fluke 5522A and purchased Met/Cal at the same time. I have no experience with Met/Cal and am NOT a programmer...and there's my problem. Rather than improving my productivity through promised "easy to use" automation, I'm now mired down in modifying procedures, report templates, etc, etc and my efficiency has dropped significantly.

Is there another software solution that simply WORKS, doesn't have a vertical learning curve, and doesn't require re-writes of supposedly tested and approved procedures and templates?
(and if there's a better/more active place to ask than here, feel free to pm me)

silv3rstr3 · 05-10-2016 -- 12:36:28

If you have money to spend, Cal Lab Solutions backs their procedures for Met/Cal. If you're on a limited budget like most of us better get used to modifying procedures in Met/Cal Editor. A lot of the procedures I fix straight off the Fluke website have fairly simple fixes.

flow · 05-10-2016 -- 12:48:35

If I were you I would have went with SureCal it is ready to use right out of the box and the standards are flexible. They have hundreds of modules to choose from. Good luck!

Hawaii596 · 05-10-2016 -- 14:05:31

Michael Schwartz who runs Cal Lab Solutions is very knowledgeable with Met/Cal, and has done some great things with the procedures, and I believe, his own software.

As for MetCal, depending on what models you have, I'm not sure if the Gold Disk (costs $$) may have the answers. Yes, it is a definite learning curve modifying MetCal procedures. SureCal by Northrup Grumman is a little more user friendly out of the box. It's procedures use flexible standards, so they are a little more flexible in that regard. But unless you get the programmers package, they can't be modified and are locked down.

Maybe take a look at what instruments you need to support and see which package covers more of it. MetCal does have the advantage that for a similar UUT, you can modify the procedure to match it (for handheld DMM's anyway). But in that case, you have to deal with syntax.

guy48065 · 05-11-2016 -- 07:50:13

I like the ability to modify procedures, for example if my standards won't cover a particular function but that function isn't needed I don't want to FAIL the item--I want it to PASS a Limited Calibration. Another example is choosing proper uncertainties. The problem is I don't know the syntax. I expected an experience similar to Labview where choices made to a graphical front end results in code changes being made to the procedure. Met/Cal is hugely expensive, popular and "mature" and I expected it to have evolved over the years. I do have a Gold membership so I'm getting support for the procedures that already exist, but not for those which don't, and education (programming) isn't included.

The problem with Cal Lab Solutions is it's an expensive band-aid to my issues with Met/Cal, where I would prefer to dump Fluke entirely (refund has been offered) and purchase a complete, working, configurable, flexible, INTUITIVE platform.

CalLabSolutions · 05-11-2016 -- 18:18:03

We have a huge library of MET/CAL procedures. But you are correct: they are Band-Aids to the bigger issues of automation. Believe me I know.. I was told this by a senior manager from then Agilent when I won best paper for the track at NCSLI a few years back for our implementation of uncertainties in MET/CAL. It really made me think!

Cal Lab Solutions as a company is headed toward Metrology.NET (www.Metrology.NET). We will still do MET/CAL procedures. But all new MET/CAL procedures will be first created in Metrology.NET, then we will use a tool we have to create about 75% of the MET/CAL version of the code.

I have been talking to customers about what we are doing. Trying to change the frame of reference about automation. Mostly because as an industry we have been doing automation wrong for 30 years.. So here is how I look at the problem..
1) Metrology is about standardized test process.
2) Uncertainties are tied to our standardized test process
3) UUT's are flexible, we should have flexible drivers for our UUT's not our standards. (because 1 & 2 are not flexible!)
4) UUT's have test points because that is what we are testing.

So in a nutshell.... Metrology.NET takes a UUT's test points and sends them to a standardized test process based on our lab standards and uncertainty calculations. The UUT is the variable, and the VISA driver can be build on the fly. So because the UUT is directly related to the test point the flexible driver can run 100% of the test points without error...
This means Automated calibration procedure can (and should be) built as follows:
1) Create the Test Groups and Test Points for the UUT or Family of UUTs.
2) Add Detailed data about a test point (Frequency, Voltage, Impedance, Range, ect)
3) Add the UUT's commands and our build a custom driver for the UUT.
4) NOW run it!

There will be issues, command's wrong, typos ect.. But that is expected as in any newly developed UUT procedure.. But it takes less time to define your test points and settings then call your standardized test process than it takes to write a whole automated calibration procedures..

And it takes less time to take your 5500 or 5520 standardized test process and uncertainty calculations and create a 5522 version. And when you are done creating the new 5522 test process something magic happens.. EVERY SINGLE procedure that runs on the old standard now runs on the 5522.

Mike

Hawaii596 · 05-11-2016 -- 19:23:00

Michael,

I am leaving for a week and a half in Haiti, but when I get back, I'd like to converse about this. We need to implement a systemic approach to uncertainties that comply with ILAC P14. I have some complex questions. Send me an email around the 23rd or so.

CalLabSolutions · 05-11-2016 -- 23:32:00

Ping me when you get back..
I will try to keep up with you on ILAC P14..
Mike

guy48065 · 05-12-2016 -- 09:01:53

Mike will metrology techs and operators be able to accomplish what you are proposing, or will this still be for programmers?

Maybe my ignorance is showing--do programmers & lab managers PREFER it the way it currently is? Maybe they don't want techs to check a few boxes to modify a procedure template to make changes affecting uncertainty calculations, communication options, special cals, etc.

guy48065 · 05-12-2016 -- 09:07:52

Case in point: On the bench today is an old but reliable Fluke 8842A. I have 3 of this model to support and THIS one doesn't have IEEE. There are no "official" Fluke procedures online, or on the old procedure CD that used to ship with MetCal for a manual cal of this model. WHY should there be separate procedures for manual and automated cals of the same meter, with the same test points & specs?

CalLabSolutions · 05-12-2016 -- 18:08:15

Guy... I actually agree with you 100%.
A longtime ago, Dave one of the best software / automation guys I know told me "You as an automation engineer should never think you know more than the guy performing the calibration day in and day out." "You should never tie his hands, instead you should work with him."

It is hard to sell someone an automated calibration solutions where the tech's can still enter manual calibration data. But I think that is one of the best selling points to Metrology.NET.
1) Not everything should be automated. 10 MHz / 24 hour drift.. That test is best done manually..
2) Sometimes automation doesn't work. A good tech can do a couple test and get the product out the door (And fill out a bug report for the programmer)
3) Sometimes the automated standard is out for calibration.

Taking the Fluke 8842A as an example, with Metrology.NET the data points. The two that have IEEE could be ran Automated... There the computer would set up the equipment and take the readings.. The one without GPIB you would do it manually. You would enter the data from the user interface. The only real difference between the two is how the system collects the data. Manual or automated.

And to answer your other question, the work of creating automation in Metrology.NET is scalable in the true sense of the word. A programmer could do all the work, but it doesn't make sense having the most valuable guy in your company creating data points for a Fluke 8842A calibration. That is a task for a more jr technician. But he may not have the skill level to look up the commands and specifics of calibration. Or what test process and standards it takes to calibrate the instrument. So in comes the more senior people (People like me, who really don't like entering test point data, we focus on the more complex problems.)

In automation you will always have to have a programmer. But the idea behind Metrology.NET was to stop duplicating the work. Why have a manual version of the software in Manual MET/CAL or a spreadsheet and the automated version of the procedure in something else. Why have a special tool for automating temperature, another one for pressure and yet another one for electrical. And why have 4 procedures for a DMM because you have 4 multifunction calibrators. (There are abstractions of my company's problems having .NET, MET/CAL, LabView and MUDCATS automated solutions.)

Mike

USMC kalibrater · 05-13-2016 -- 04:22:02

Mike,
Have you read A Systems Engineering Approach to Calibration Procedure Development Cp-09 from NCSLI. It appears to support what you are saying about how Metrology.net procedures will be developed. We are reviewing it here to see how we can begin to incorporate some of these practices into our procedure development processes (both manual and automated).
I owe you a paper too per our conversation in Orlando. I need to catch up to you soon about details and Ill start getting it put together.

N79 · 05-13-2016 -- 17:06:04

Currently I'm writing software that attempts to engineer the measurement system, increasing the scope of what measurement software should do. I'm an electrical guy, so I don't know how well it would translate to other areas, but through a combination of inputting a lot of details and properties about our available instruments, artifact standards, cables, adaptors, etc., some brute force all-possible-combinations-of-equipment-are-considered methods (most being irrational), and SPICE simulations, it's possible that the software can figure out the best most efficient way to verify an test item's specs with really no procedure writing at all. The computer does all that work, without bias, for you.

Of course, this leaves out actually adjusting a test unit as those procedures tend to be really specific to the test unit, but it's relatively painless if that test unit allows remote commands to calibrate.

CalLabSolutions · 05-19-2016 -- 10:37:46

Last week I created a video showing two HP 8648 signal generator calibrations running at the same time on a single GPIB card.
https://www.youtube.com/watch?v=gy6IkKITINM

One of the things we accomplished in Metrology.NET is a fully threaded execution engine. This means people who are writing their automation in Metrology.NET can create multi-threaded automation without having to leaner all the complexities of synchronous and asynchronous programming.

Mike

richlstubbz · 05-20-2016 -- 07:54:22

Sometimes I am amazed at how some folks think automation is easy and takes no experience and it just works with no issue. It really doesn't. It works when they build it in their setting and their equipment but not 100% for everyone.

Even programming with met/cal is programming and not having any programming knowledge and expecting to take on this with ease is silly. Sure with some time and practice and a little reading/training you can probably make a basic DMM procedure. but to try and tackle complex items or to try and fix some met/cal gold procedures your going to have an up hill battle.

You can not lack computer skills and hope these things just work. Calibration is really a small business so the software part of it is not all that great for main stream use.

At least with met/cal you do have the ability to edit things. Not so much the case with other automation software. That's sort of how they want it though, so you cant make changes or make your own automation programs.

on another note.. yes automation takes a good amount of time up front. but the benefits once you get it going continue to pay for a very long time.