Met/Cal and VISA

[CalLabSolutions]

I can't speak for RFCAL, but we do get together over beers every now and then and talk.  I know we share a lot of the same frustrations.  He runs one of the better calibration labs I've been in, where they do mostly high end RF and uWave calibration (something that presents a set of challenges when using MET/CAL).
RFCAL, like me and many of my customers I have a laundry list of features we been requesting for years.  If you have ever attended two (or more) Fluke User Group meetings you know there is an ongoing theme.   Every meeting someone will ask for "Spell Check" as well as an Undo feature.  Me I always ask for the following:
•   More room in MEM2, enough to pull the trace on an Oscilloscope (this is request that goes all the way back to MET/CAL 5.0). 
•   The ability to test single sided specifications with measurement uncertainties.  That would be <-30dBc where it reports JUST the measured value, upper limit and measurement uncertainties.
•   The ability to use variables when overlaying text on a picture with the PIC FSC
So I would like to propose the "FLUKE CHALLENGE." This year at NCSL's Fluke User's Group Meeting, Fluke will take a list of all feature requests at the meeting. Then let the attendees vote on each one, Fluke will then take the top 20 requested features WHATEVER THEY ARE, and implement them in 8.0.  (Not 8.0 SP1 or the version due out in the year 2025.) 

[RFCAL]

•What is archaic about the procedure structure?

Let's start with MEM and MEM1..  I have dual core processors, but still have to program in memory registers?

I agree with Scottpb, there are a lot of BandAids

I could go on and on, but there comes a time when you just have to put an old horse out to pasture. 



•What is your source for the statement "they do not want to change"?

                I have been to several Fluke meeting, at each meeting people collect a laundry list of requests. And I don't know what they do with it, but I don't see those changes.   Simple things like undo,  graphs and single sided test points with measurement uncertainties.  VOC, I have grown tired of asking.



•What other software packages are comparing MET/CAL to?

Agilent TME for one... it just works.  I've been on a tight budget sense 2008, if I am going to pay for procedures I want them to work.

[BuffaloWings]

Hey guys, I think this is a great thread.  I have been thinking about it over the weekend, and wanted to offer some replies.  I started to make one long multi-quoted reply, but it got too long so I am going to split it into single replies instead.

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?

Hawaii596, are you positive about the upgrade price?  That sounds extremely high to me, I've never had to pay that much even when I bought several new licenses for a networked laboratory.  Fluke Gold does come with a lot of nice features; it is much more than than just software updates or a single meter procedure.  You get their entire procedure CD, which is almost up to 1,000 UUTs now:
http://assets.fluke.com/metcalproc/html/index.html

It looks like their 8846A procedure is compatible with version 7.20 Service Pack 3, and does not require version 7.3:
http://assets.fluke.com/metcalproc/html/fluke_8846a_1yr_ver_ieee_5720_5725_5520_8508.html

[BuffaloWings]

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

Mike, I agree that Hawaii should not require 7.3 to run a meter procedure, unless he wants to use a brand new FSC or requires support for Windows 7 or Vista (which is why the file/path locations were changed).  I think it is more than a little misleading to imply that Fluke is charging $50k for a meter procedure.  Maybe he was quoted for an entire system: the software plus a calibrator to go with it?

[BuffaloWings]

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

Mike, I hope this is not perceived as backlash, but I did review your Spaghetti Code document and I have a few questions.  It looks like your paper may be leaving out part of the Strucured Code story, as it only illustrates JMPLs and LABELs.  Where is the actual "work" being performed?  Those JMPLs have to be going somewhere...

I have also reviewed Fluke's Gold procedures, and understand why both methods are used.  Some technique must be employed to maximize efficiency when the results need to be printed in a certain order (typically matching the OEM documentation), but the procedure needs to operate in a different sequence to minimize connection changes.  However, aren't your Structured Code example and Fluke's inline method just two different ways of accomplishing the same thing?  Is one method really better than the other, or is it more a matter of coding style?

When comparing these two methods, your example will result in twice as many JMPL and LABEL lines since there is now a pair of lines going to the actual test, and another pair for the return.  To me, this equates to double the number of spaghetti noodles in our bowl of pasta (we're going to need more sauce!).  I have tried to illustrate what I expect to be the remainder of the story in the attached image below.

Test selection menus can certainly be a convenient feature, but they can also open a lab to compliance risk.  What happens when a tech is performing a cal by running individual tests (not end-to-end), and forgets to select that one last test from the menu late on a Friday afternoon when he or she is in a hurry to get home?  Will they remember to run it separately on Monday morning, or will they send out a non-compliant certificate due to human error?  Will this mistake be caught during quality review?  How many lab managers or quality directors are aware of these risks that may be present within their outsourced procedures, and are they comfortable with it?

[BuffaloWings]

I can't speak for RFCAL, but we do get together over beers every now and then and talk.  I know we share a lot of the same frustrations.  He runs one of the better calibration labs I've been in, where they do mostly high end RF and uWave calibration (something that presents a set of challenges when using MET/CAL).
RFCAL, like me and many of my customers I have a laundry list of features we been requesting for years.  If you have ever attended two (or more) Fluke User Group meetings you know there is an ongoing theme.   Every meeting someone will ask for "Spell Check" as well as an Undo feature.  Me I always ask for the following:
•   More room in MEM2, enough to pull the trace on an Oscilloscope (this is request that goes all the way back to MET/CAL 5.0). 
•   The ability to test single sided specifications with measurement uncertainties.  That would be <-30dBc where it reports JUST the measured value, upper limit and measurement uncertainties.
•   The ability to use variables when overlaying text on a picture with the PIC FSC
So I would like to propose the "FLUKE CHALLENGE." This year at NCSL's Fluke User's Group Meeting, Fluke will take a list of all feature requests at the meeting. Then let the attendees vote on each one, Fluke will then take the top 20 requested features WHATEVER THEY ARE, and implement them in 8.0.  (Not 8.0 SP1 or the version due out in the year 2025.) 

Hey, where was I during these beer drinking sessions???   I agree that Undo is sorely needed, and I hear it is coming with 8.0 along with a slew of other new features.  I'm not sure I agree with you about spell checking though; it would only be useful on certain FSCs where human-readable text is being entered like DISP and OPBR.  Most of what we type into the Editor is either command syntax, or engineering terms that won't be included in a standard dictionary (like the one Microsoft ships with Word).  Even if the checker's scope was limited to certain FSCs, the number of "mis-spelled" words is going to be enormous until the dictionary is taught which words are acceptable.

• Out of curiousity, have you encountered many situations where more room is required in MEM2?  I have encountered less than a handful, and in these cases I was able to write the query response to a file and then read/parse the file to do what was needed.  For me, this has happened so rarely that I hadn't considered modifying MEM2.
  
• I haven't tried this, but I think reporting single-sided measurements along with their uncertainties can be performed by using a custom Crystal Report to suppress the fields you don't want.  For example, set a MEMCX negative tolerance to -9999U in the procedure, then instruct the Crystal Report to suppress tolerances that match -9999U?  I bet this can be done, but I would have to do some testing to confirm.
  
• I completely agree about using variables with the PIC FSC, in fact I made this same request to Fluke.  I want to create a generic picture, and overlay text with actual model numbers for the standards being used at Run-Time.

Adding 20 new features to any software package is going to delay its release.  I think MET/CAL 8 already has a firm release schedule, so I'm doubtful that 20 new features could be included in the initial release.  If the new feature set doesn't include something that people wanted, your idea is a good one for populating features in the next version.

[BuffaloWings]

•What is archaic about the procedure structure?

Let's start with MEM and MEM1..  I have dual core processors, but still have to program in memory registers?

I agree with Scottpb, there are a lot of BandAids

I could go on and on, but there comes a time when you just have to put an old horse out to pasture. 



•What is your source for the statement "they do not want to change"?

                I have been to several Fluke meeting, at each meeting people collect a laundry list of requests. And I don't know what they do with it, but I don't see those changes.   Simple things like undo,  graphs and single sided test points with measurement uncertainties.  VOC, I have grown tired of asking.



•What other software packages are comparing MET/CAL to?

Agilent TME for one... it just works.  I've been on a tight budget sense 2008, if I am going to pay for procedures I want them to work.

RFCAL,

• What would you propose as an alternative to MEM and MEM1?  Where would you store queried responses?
  
• When you suggest "putting MET/CAL out to pasture", are you saying Fluke should cease support?  I'm not sure their customers would too happy about this considering the decades of time invested, and the fact that they are still happily using MET/CAL, and want to use it for more things.
  
• From what I hear, Undo is coming.  As I mentioned above, single sided tolerances with their uncertainties should be able to be reported with a custom Crystal report.  I think the same could be done for charts and graphs.
  
• I have used Agilent TME software too, and it works if you don't mind paying their per-use fees, you have the hardware required, you don't mind some of its kludgy behavior, and you don't mind tending to a 6-7 hour spec an calibration (vs. 2 hours of mostly unattended time in MET/CAL).

[measure]

Thanks for the responses.

•What is archaic about the procedure structure?

Let's start with MEM and MEM1..  I have dual core processors, but still have to program in memory registers?

MET/CAL has had named variables for quite awhile... MEM and MEM1 are legacy variables and remain for backward compatibility. The new NVI FSC parameter values can be passed using either.

I agree with Scottpb, there are a lot of BandAids

I could go on and on, but there comes a time when you just have to put an old horse out to pasture.

I wouldn't begin to deny that MET/CAL is a mature product, but part of Fluke's strategy has been to continue to support existing procedures. Unfortunately, doing so has its own inherent limitations. Would you prefer to have all the changes you asked for implemented at a cost of making all of your existing procedures instantly obsolete?

•What is your source for the statement "they do not want to change"?

I have been to several Fluke meeting, at each meeting people collect a laundry list of requests. And I don't know what they do with it, but I don't see those changes.   Simple things like undo, graphs and single sided test points with measurement uncertainties. VOC, I have grown tired of asking.

I think any programmer will tell you that what appears to be a simple change on the outside can have large, if not disastrous changes if hurriedly implemented. I think all suggestions are welcome and listened to, but implementation is the more difficult task - it takes time, testing, debugging, retesting, all before any code can be released.

•What other software packages are comparing MET/CAL to?

Agilent TME for one... it just works.  I've been on a tight budget sense 2008, if I am going to pay for procedures I want them to work.

Thanks again for sharing.

[CalLabSolutions]

Mike, I hope this is not perceived as backlash, but I did review your Spaghetti Code document and I have a few questions.  It looks like your paper may be leaving out part of the Strucured Code story, as it only illustrates JMPLs and LABELs.  Where is the actual "work" being performed?  Those JMPLs have to be going somewhere...

I have also reviewed Fluke's Gold procedures, and understand why both methods are used.  Some technique must be employed to maximize efficiency when the results need to be printed in a certain order (typically matching the OEM documentation), but the procedure needs to operate in a different sequence to minimize connection changes.  However, aren't your Structured Code example and Fluke's inline method just two different ways of accomplishing the same thing?  Is one method really better than the other, or is it more a matter of coding style?

When comparing these two methods, your example will result in twice as many JMPL and LABEL lines since there is now a pair of lines going to the actual test, and another pair for the return.  To me, this equates to double the number of spaghetti noodles in our bowl of pasta (we're going to need more sauce!).  I have tried to illustrate what I expect to be the remainder of the story in the attached image below.

Test selection menus can certainly be a convenient feature, but they can also open a lab to compliance risk.  What happens when a tech is performing a cal by running individual tests (not end-to-end), and forgets to select that one last test from the menu late on a Friday afternoon when he or she is in a hurry to get home?  Will they remember to run it separately on Monday morning, or will they send out a non-compliant certificate due to human error?  Will this mistake be caught during quality review?  How many lab managers or quality directors are aware of these risks that may be present within their outsourced procedures, and are they comfortable with it?

I don't see it as a back lash..  It is a programming style..  Yes, I have twice as many JMPLs..  And Yes the both address connection efficiencies, but one reads easily and the other does not.   
It is easy to see I am testing Resolution Bandwidth, then Resolution Switching then Displayed Average Noise. Even the lines in your post of my code show some structure.

As far as allowing the operators to select the tests they want to perform.  You should ask around, TME, SureCal, our PS-CAL all of them allow the user to select the test they want to perform.  And lab managers seem to trust their technician can do their jobs correctly.  We added it to our procedures because that is a feature MET/CAL users are asking for. 

I would also like to point out our code comes standard with the ability to disable test selection mode if a lab does not want to allow their techs that ability.

I do question as it relates back to software, that the calibration is no good if all the test have been preformed.  I know of a lot of procedures that skip a lot of test.   

Mike

[BuffaloWings]

I don't see it as a back lash..  It is a programming style..  Yes, I have twice as many JMPLs..  And Yes the both address connection efficiencies, but one reads easily and the other does not.   
It is easy to see I am testing Resolution Bandwidth, then Resolution Switching then Displayed Average Noise. Even the lines in your post of my code show some structure.

As far as allowing the operators to select the tests they want to perform.  You should ask around, TME, SureCal, our PS-CAL all of them allow the user to select the test they want to perform.  And lab managers seem to trust their technician can do their jobs correctly.  We added it to our procedures because that is a feature MET/CAL users are asking for. 

I would also like to point out our code comes standard with the ability to disable test selection mode if a lab does not want to allow their techs that ability.

I do question as it relates back to software, that the calibration is no good if all the test have been preformed.  I know of a lot of procedures that skip a lot of test.   

Mike

I like how you provide the option to disable the test menu, that's a nice feature.  Menus are certainly nice, as long as the people using them understand their associated risk(s).  My concern when writing automated software is that even the best trained, most trustworthy technicians are still humans that can and will make mistakes.

Regarding programming styles, I still see the two methods being discussed only as different styles which accomplish the same goal.  Fluke Gold procedures include comments in each procedure describing their inline jumps, which to me provides a similar level of readability.  For example:

# NOTE: Results are reported consistently with the source documentation, in
# test number sequence.  This procedure uses JMPL/LABEL statements to navigate
# this sequence for minimum connection changes and operator intervention.
#
#  Order  Results                            Run Time (Execution)
#  -----  ---------------------------------  ---------------------------------
#    1.   10 MHz REFERENCE OUTPUT            DISPLAYED AVERAGE NOISE LEVEL
#    2.   CALIBRATOR AMPLITUDE               RESIDUAL RESPONSES
#    3.   DISPLAYED AVERAGE NOISE LEVEL      10 MHz REFERENCE OUTPUT
#    4.   RESOLUTION BANDWIDTH SWITCHING     SWEEP TIME
#    5.   RESOLUTION BANDWIDTH ACCURACY      RESOLUTION BANDWIDTH SWITCHING

I'm not sure I understand your last statement about skipped tests in procedures.  If not all of the required tests are performed, how can a person state that the UUT is in compliance?

[CalLabSolutions]

BuffaloWings, it sounds like you are agreeing with me; that it looks like a bowl of pasta, so it has to be heavily commented.   

My structure requires little commenting because it is easy to read and easy to follow.  Yes it is more work to write, but I would rather spend time writing better code than commenting it up the top.

Mike.

[BuffaloWings]

I don't like either method actually, both are workarounds within MET/CAL.    I am requesting that Fluke add the ability to directly specify results order vs. execution order, so we don't have to jump around within the procedure to achieve our desired effect.

[CalLabSolutions]

I don't like either method actually, both are workarounds within MET/CAL.    I am requesting that Fluke add the ability to directly specify results order vs. execution order, so we don't have to jump around within the procedure to achieve our desired effect.

Well Sense you are with Fluke, you may have better luck than I have had in the past.
Most of the posts on this thread have been defending the product.  Yes we need a better way.   
You and I may become best friends after all this.  Will you be at NCSLI?

[measure]

Most of the posts on this thread have been defending the product.

Funny, I thought some people were making specific comments about the product (MET/CAL) and others were soliciting information or offering opinion, based on their experience with it - just like some people like ales and others prefer pilsener (beer), based on their experience drinking it.

[BuffaloWings]

Mike, why would I need to defend MET/CAL?  Is it under attack?  Defense has not been my intention, I'm just trying to help the community realize that there is always more than one way to skin a cat, especially when it comes to automation.  Some ways may be right, some ways may be wrong, and some ways may just be different (stylistic).

I certainly understand a customer's frustration over a perceived lack of product support for ANY product.  However, I don't know which of the complaints expressed in this thread have been relayed to Fluke, or when they were submitted.  I can only speak from my personal experience, and Fluke has always been very responsive.

Unfortunately, I will not be able to attend NCSLi this year.  I do hope we get a chance to talk one of these days though!

Funny, I thought some people were making specific comments about the product (MET/CAL) and others were soliciting information or offering opinion, based on their experience with it - just like some people like ales and others prefer pilsener (beer), based on their experience drinking it.

Yes, let's get back to the the important stuff.  Beer!