Met/Cal and VISA

PMEL · 07-07-2011 -- 15:52:36

I have been slowly doing test runs on Met/Cal using VISA commands not IEEE commands. The benefit of this is that you can write one procedure and communicate with your instrument over GPIB, LAN, USB or serial. Met/Cal implemented this in service pack 7.1 or 7.2 I think. It is a hidden function that must be turned on. To do this place the line "NI-VISA" on your bottom line of your metcal.ini file. Make sure you have the newest NI Measurement Automation Explorer installed and that nasty TekVISA is not. To implement this in your Met/Cal procedures simply replace all your IEEE commands with VISA. Like I said I am still testing this but it has been working great. I see a great need in the coming future to easily communicate with items over USB and LAN. GPIB is becoming less standard on newer equipment. If you need any more help please post here and I will get back with you.

Hawaii596 · 07-07-2011 -- 19:14:26

This may be an unrelated question, but I have a Fluke 8846A that I want to run the automated adjustment routine on. I was thinking of getting aa MetCal procedure for this, but found out that I need to upgrade my version of MetCal for about $50K. So that was out. Then I tried contacting Surecal to see if they could write a procedure. They quoted about $14K to write it. I wonder if this would make my MetCal work with the procedure for the 8846A without having to do the upgrade. I'm not sure what the differences are. I THINK I have 7.1 or 7.2 and need to get to 7.3.

Does this slight modification perhaps circumvent the issue with my slightly older version of MetCal that is keeping me from being able to run the adjustment on the FLuke 8846A?

CalLabSolutions · 07-08-2011 -- 01:22:09

Hawaii,
I can save you some money. And you don't need MET/CAL 7.3. We will have to talk about standards though. You will need more than the typical 5700 to test these.

Most of our customers are running 7.11 or 7.2. There are not may features in 7.3 that justifies the cost of the upgrade. That and 7.3 has moved a lot of file locations, so many companies are having to re-write some exe to point to the correct path before they upgrade to 7.3.

Our Price on this procedure is $1,500 for the standard version $2,250 for a A2LA expanded uncertainties compliant version.

I know Fluke Gold is expensive, but if it does not make economic sense, then it is not worth the investment.. $50k for a meter procedure is very expensive. Event $14k is very high. With us 50K will buy you a whole lot of automation, and we guarantee our procedures to work,

We also have the Tek DMM40x0 version of the procedure ready to go.

Mike
Cal Lab Solutions
http://www.callabsolutions.com

PMEL · 07-08-2011 -- 04:38:20

Mike is correct I see no reason to go to 7.3. Until Fluke starts listening to their customer and implement changes that must be done to successfully bring Met/Cal into this century I will not be upgrading.

RFCAL · 07-08-2011 -- 13:34:46

We will not be upgrading to 7.3 or 8.0 ( when it comes out) because we also run a lot of old procedures that use the .exe. Fluke Gold is not worth the $$.Especially when they don't listen to their customers and their procedures do not work.

PMEL · 07-08-2011 -- 16:24:54

It might be a little to late for FLuke to pull Met/Cal out of its slump and bring it to the place it needs too be. The question is will Fluke listen. I know you can not please everyone but it is clear they need to please some. I think a good start would be to open up the API so we can make Met/Cal the way we want to. And for the love of Metrology stop making us put SUBs in the main directory.

scottbp · 07-11-2011 -- 10:46:16

It looks like everytime Fluke updates MET/CAL whether upping the number (e.g. 7.2 to 7.3) or releasing a service pack (or band-aid as I like to call it), a lot of it is to add instrument drivers/FSCs. I've told them that if the instrument drivers were .dll files, upgrades would be so much simpler...

RFCAL · 07-11-2011 -- 18:14:49

The way they write procedures is Archaic and they do not want to change!! This will eventually cause the demise of Metcal.
If someone else were to design a platform to compete with Fluke and use the Metcal basis, I bet they would get alot of customers deserting Fluke.

measure · 08-09-2011 -- 13:19:06

Quote from: RFCAL on 07-11-2011 -- 18:14:49
The way they write procedures is Archaic and they do not want to change!! This will eventually cause the demise of Metcal.
If someone else were to design a platform to compete with Fluke and use the Metcal basis, I bet they would get alot of customers deserting Fluke.

MET/CAL, unlike instrument control software packages, is purpose built to support metrology applications. While the user interface is perhaps not as flashy as some may prefer, the current version of the software will reliably execute procedures going all the way back to Version 1.0.

Regarding your statement, can you please identify the following:

What is archaic about the procedure structure?
What is your source for the statement "they do not want to change"?
What other software packages are you comparing MET/CAL to?

CalLabSolutions · 08-10-2011 -- 15:39:50

I know there is going to be some back lash for this, but I will chime in on structure..
Most people who write MET/CAL procedures have a mess of Spaghetti Code, it is hard to follow and event harder to fix because you don't know where or when your variable are getting updated. When you have a unit with a bunch of options (procedure branches) you have to run the code for every option configuration available to make sure it is jumping correctly. (or you just skip writing code to cover the options)

See..
http://www.callabsolutions.com/Download/Spaghetti_Code.CDR.pdf

Our procedures are better structured, they run in an End-to-End mode, or Test-Selection mode allowing the user to select an individual test group. They give the correct connection message, only when its need, no mater the order they run the procedure in. This is because we have applied the principles of structured programming from other languages to our MET/CAL procedures.

Mike

CalLabSolutions · 08-10-2011 -- 15:45:20

Oh By the way for those of you are are not MET/CAL programmers. MET/CAL does not have a GOSUB, something I have been asked for several times over the past 10 years.

1.058 JMPL ResolutionBandwidth
1.059 LABEL ResolutionBandwidth_done
This equates to
1.058 GOSUB ResolutionBandwidth
Go test Resolution Bandwidth and come right back here

Mike

measure · 08-12-2011 -- 14:06:04

Thanks for the background on Cal Lab Solutions ideology and subsequent clarification, Mike.

My interest, however, was in RFCAL's post comments and what specific references he drew upon in forming them.

RFCAL · 08-12-2011 -- 14:55:42

you know, I know you work for Fluke and you REALLY don't want me to post all my concerns.

BuffaloWings · 08-12-2011 -- 15:41:53

RFCAL, it seems like he is asking for your details. If he really does work for Fluke, this would seem to contradict your earlier post about Fluke not listening to their customers. Whether he does or not, why do you hesitate to post your opinion now when you weren't holding back earlier, or even in other threads? Do you really want Fluke to address your concerns, or do you prefer to just complain instead?

RFCAL · 08-12-2011 -- 15:56:17

I'll save it for the Fluke user group meeting at NCSLI