9640A with 8594E fluke procedure

[HarryBee]

Hey people.  I have an odd problem.  I am trying to run the 8594E procedure and when I get to any part which uses the 9640A RF reference source it prompts me with the following error;
E386:  The run time system does not allow a non-required standard (Fluke 9640-50 attached to Fuke 9640A) to be used by the procedure.  This check is done to prevent potential traceability problems.  The procedure should be re-written to correctly reflect the required standards.
My config file is set up correctly and this is a fluke warranted procedure with the required standards listed in the beginning of the procedure.  The standard is properly configured.  I tossed this back and forth a few times with fluke support.  Has anyone seen this error/problem or could possibly suggest some variables? 

[CalLabSolutions]

It has been a while sense I have worked on 859xE automation.. But if I remember correctly they came in both 50 & 75 Ohm options.   I do remember when we wrote those procedures it was a lot of work to get ALL THE OPTIONS and  the spec correctly matching the manual based on the serial number prefix and installed options.  Back in 1999 it was the largest procedure I had written to date.   

I don't use the 9640 FSC so don't quote me.  But fond a similar problem with the 9500 FSC generating errors when the customers configuration did not 100% match mine. To resolve the issues I had to have my customers open the procedure in editor, find a blank line, press space key, then re-compile the code for each sub procedure called.   It was a lot of work.

That was one of the reasons we moved to 100% driver calls dropping all most all of the instrument specific FSCs.   

Mike

[HarryBee]

Yes, I use the IEEE commands almost always as well.  Especially since the new version of MetCal seems to want to take over (ie default/forced user prompts).

The procedure I'm using is the one created by Fluke.  The error makes me think it's a MetCal problem but I admit I could be 100% wrong.

[CalLabSolutions]

I am at a trade show this week.  If you have having the problem next week maybe I could remote in and see if it is something I could fix.

[HarryBee]

As much as I appreciate that generous offer I don't think my employers would appreciate that especially with the sensitivity of information within my organization.  Even though I don't think that this is an equipment problem I still don't enjoy the fact that this is the only 9640A I have to test this warranted procedure with.  I am going to mess with this again this evening before I leave and try different things.  This is definitely a weird problem.  Maybe I can send the unit to another division where they have an older version of metcal and make sure it's not a problem with version 8? Just trying to isolate the variables.... Will post results.  Thanks again, Sir.

[NavyCalMaster]

Don't know if you have resolved this issue yet, but you may want to try running the procedure on a computer that doesn't have MetCal 8.0

I have experienced a couple of items that come up with odd errors when running automated on 8.0, but when they were run on 7.3 or earlier they ran just fine.

I haven't had the chance to try to find out what is causing the problems with 8.0 but maybe this will fix your issue, at least temporarily.

[RFCAL]

We have had the same problem with several of our old procedures. They ran fine on 7.2 or 7.3, but won't run on 8.0. That's what they don't tell you in the fine print--that you may have to modify your old procedures to 8.0. All of us are pretty disappointed with 8.0--not as smooth as they said it would be.

[Chad Dodds]

The MET/CAL procedure language has not changed for a long time, older procedures will continue to run in 8.0 without modification.  The only exception to this that I'm aware of is if your procedure uses hard-coded paths to an external file (*.exe, *.ini, etc.), and that path changes for any reason.  In this case, the procedure won't be able to locate the files it is looking for, and will require modification.  Note that this does NOT apply to the Program Files installed by MET/CAL, only to auxiliary files that a procedure is designed to work (e.g. multichoice.exe).

The upgrade to MET/CAL version 7.3 or higher changed many installation paths to allow support for Windows Vista and Windows 7.  If the types of files described above were also moved, it could prevent the procedure from operating.  You could then either just move the files back to their original path, modify the procedure to reflect the new path, or better yet read the path to the User Program Directory from metcal.ini using MATH FSC's INI() function:

  1.001  MATH         Path = INI("startup", "user_prog_dir")

[RFCAL]

Obviously you work for Fluke. I know better. Do you think people are making this up? We have had to modify several hundred procedures to work in Metcal 8.0.  We were sold a pile of tin when it should have been gold!!. If you are using .exe files in 7.2 or 7.3, the same .exe files will NOT be found in 8.0. You will have to modify any 7.2,7.3 procedure to a work around or update your .exe files to run in 8.0.We have had to spend considerable resources to get the older procedures to run.Now for the uncertainties. I hate to tell you, but the uncertainties do NOT print line by line in 8.0. Some columns are left blank in some procedures. The users at my facility would just as soon go back to 7.0,7.2,7.3

[Chad Dodds]

Yes, I work for Fluke.  I make no effort to hide that fact, nor my identity, as evidenced by my user name; but then again, why would I?  I suppose I should introduce myself before going much further.  My name is Chad Dodds. I have worked for Fluke since October 2010 and am currently the Lead for Fluke's MET/CAL Gold Procedure Development team.  Before Fluke, I worked for a large third party commercial calibration lab, and prior to that I was in Air Force PMEL.  I am not here to defend or debate our favorite version of MET/CAL.  Instead, I hope to exchange factual information to identify where problems exist so that they can be fixed.  Hopefully you find my presence here beneficial, as I can try to help diagnose and correct certain problems, while also gathering information to make MET/CAL and our Gold Support procedure selection better for all of us.  I have no hidden agenda, and no desire to deceive, disbelieve, or discredit anyone.  I do not work for Fluke Software Support, so hopefully you have communicated all of your product concerns and troubles with them.  I have no way to know if you have or have not since I don't have access to their call system.  Last but not least, I spend far more time on the Fluke Calibration Community forum than I do here.  If you need to reach me or the Fluke support staff quickly, please visit https://community.flukecal.com/.

I have already contacted the original poster of this thread via private message, in an effort to help resolve the 8594E procedure issue.  I developed the current 8594E Gold procedure and tested each variation thoroughly; it was even used for a few customer demonstrations after release.  However, all of these events occurred in MET/CAL version 7.3 SP1.  If a problem was introduced with 8.0 which prevents this procedure from running, then please let us know the facts by contacting softwaresupport@flukecal.com.  This is the best way to allow us (Fluke) to determine the root cause of the problem, and make sure it is fixed.

As I stated above, the only problem I am aware of that would impact your ability to run procedures after updating MET/CAL is if the procedures contaned hard-coded paths to external files, and the paths to those files change for any reason.  There are many reasons why a file path could change: moved to a network drive, moved to a thumb drive or external HDD, change MET/CAL versions to 7.3 or newer, etc.  Many MET/CAL paths were changed with version 7.3 in order to support Microsoft Windows Vista and Windows 7, but they then remained consistent from 7.3 to 8.0.  If the paths changed for any reason and caused problems, copying all of the files used back into their original path should have allowed the procedures to run the same way that they did before, without modification.  Are these the types of problems that you had to spend considerable resources to correct?  If not, could you please provide me with examples of what else you had to change?  Please include a few sample lines of code, and a description of the problem that was addressed.

RFCAL, if you (or anyone) experience other problems with your procedures outside of the path issue, please contact softwaresupport@flukecal.com.  Please note that all procedures on the Fluke Gold CD should not have this issue, as they were updated a very long time ago to prevent those types of problems by using other techniques like the MATH FSC's INI() function described above.  If you encounter any problems with a Gold procedure, related to path changes or otherwise, please also contact softwaresupport@flukecal.com or call the Gold Support number so we can get them resolved as well.

[CalLabSolutions]

I wrote a calibration procedure for the 859xE series spectrum analyzers like 12 years ago.  It was an education to say the least, these spectrum analyzers are very complex.  Different options and configurations even firmware version made this model a bear to support.  For example all models don't Instrument Preset exactly the same.

RFCAL.. Yes, There is more work to getting your procedure Z540.3 compliant than simply upgrading your version of MET/CAL.  You still need someone to calculate your uncertainties then edit / update the procedure to include all the contributors.
We have spent a lot of time upgrading all of our executables to be 7.3 compatible.  It is a lot of work... and EVEN MORE TESTING.   That is why I am recommending to all of my customers and customers running older Intercal procedures to delay their move to 7.3 and 8.0.  It will take time update all of the procedures then test them. (We are still developing procedures to run in MET/CAL 7.11, most companies I am working with are very happy with that version as well as 7.2.)

Mike
   

[RFCAL]

To Mr. Dodds--We can't wait that long for your support team to fix the problems. There are too many of them and we need to put orders out the door.There are 3 of us in this little thread that have expressed discontent with 8.0--are you listening?

[measure]

We have had to modify several hundred procedures to work in Metcal 8.0.

Who/what was the source of the "several hundred procedures" you had to modify? Did they come from Fluke or someone else? To be fair, I think that is an important fact that has not been mentioned in this discussion thus far.

Mike's comment that "We have spent a lot of time upgrading all of our executables to be 7.3 compatible.  It is a lot of work... and EVEN MORE TESTING.   That is why I am recommending to all of my customers and customers running older Intercal procedures to delay their move to 7.3 and 8.0.  It will take time update all of the procedures then test them" sounds more like a compatibility problem with older Intercal and Mike's procedures than with MET/CAL. Perhaps that is why he recommends to his customers to delay an upgrade? Maybe the source of RFCAL's problems as well?

[CalLabSolutions]

Measure... Yes.. It is a compatibility problem..  There are no options in MET/CAL 7.3 or 8.0 to keep the legacy file location structure.  When Fluke change locations of the executable and the location of the dosdose.dat; so every external executable had to be updated.

We as a company focus on the harder, more complex calibrations.  We do more with MET/CAL than any other company out there.  And when we need more power than MET/CAL has to offer we have to write an executable to fill the gap.  And we have worked hard to get our executable modified to work with MET/CAL 7.3 and above.

It is not secret I worked for Intercal, and I wrote most of their drivers and external executable.   But if you look back it was Intercal that had 859x procedures running 15 years ago, and now CLS that has the largest library of complex calibrations running in MET/CAL.  We are on the Leading Edge of MET/CAL technology pushing the limit of what it can do.  But we also have to protect our customers form the Bleeding Edge of that same technology.

I don't know what the source of the original problem is for this thread.  I offered to help, but it looks like that is not an option.  What I do know is, customers don't care about the source of the problem!  They want a solution, they want to get product out the door.  That is why we named the company "Cal Lab Solutions"

Mike

P.S. Just for the record I asked for the LIB FSC way back in version 5.0.  But I was told I can do everything I needed to do with the DOS FSC.  I also asked for an unlimited number of alias at the same time. In 5.1 I got dual aliases and not until 7.3 did I get unlimited and 8.0 for the ability to communicate with a COM object.  (That is over 10 years later.)

[measure]

Thanks for the explanation, Mike.

I am not a computer geek, but I thought the change in the "legacy file location structure" had more to do with, and was necessitated by, compliance with modern operating system requirements, ala Vista® and Windows 7®, not on some whim by Fluke.

I did not mean to imply that it was a "secret" you worked for Intercal, I just mentioned that as a timeline clarification for procedure origination.

I agree that for any problem, a solution is called for. Chad offered avenues for those with problems to respond. However, vituperative rhetoric with no specific problem description benefits no one. RFCAL states "To Mr. Dodds--We can't wait that long for your support team to fix the problems. There are too many of them and we need to put orders out the door." How can the "problems" be addressed if he is not willing to share the specific nature of them with those who can do something about it? Isn't that like telling the mechanic your car is broken without sharing the nature of the problem?

This discussion has already taken a detour from what the original post was about. I suggest that a new thread be opened if those interested in this topic want to persist.