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?
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
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.
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.
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.
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.
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.
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")
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
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
[email protected]. 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
[email protected]. 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
[email protected] or call the Gold Support number so we can get them resolved as well.
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
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?
Quote from: RFCAL on 09-23-2012 -- 11:59:38
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?
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.)
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.
Yea, we get off topic, sometimes as much as 7 degrees of separation. But most of us on this site and in the community know and trust each other.
I have a couple sites I use and follow.. But non of them are as good as the PMEL Forum when it comes to metrology questions. And I like it when I am at NCSLI and someone comes up and introduces themselves with their PMEL ForumID..
Not trying to stray off topic here, but as an everyday user of Fluke Metcal I have to say that their product is often very frustrating. It is a good thing that you can modify them and fix errors that their own programmers cannot locate. Still, it is very annoying when you download a procedure straight from their disc, that they claim has been tested and verified and it has multiple errors. Even when you are using the same standards they have "verified" the procedure with. I have run into this a lot with Tektronix scope procedures. I am not trying to make this about slamming Fluke, but when they say they verify a procedure, I really don't believe it anymore.
AMEN!!! to that!!We have seen the same problem and have had to fix it ourselves rather than wait for Fluke to get around to it. I have seen procedures that would not even run from the start to procedures that do not test the full performance ver from the OEM. Anyone should be verifying any automated procedure against the manufacturer's performance ver or cal procedure. As I stated before--inmy opinion,Fluke 8.0 does not live up to the hype.
Navy/RF/Harry (and all),
It takes a lot of work to get a procedure up and running to where it is 100% rock solid. One person explained it to me in an analogy. It is like writing a thesis paper to the level that no-one can find a single error in it. It is a lot of work.
We know how complex a calibration procedure can be; and if you look at our procedure list we have the most complex procedures available in MET/CAL. Some of the people and Fluke and I have been bumping heads for years about how to write quality automated calibration procedures. At this point all we agree to dis-agree.
If you go to the Cal Lab Solutions web site you can download an Agilent DSO-X 2000/3000 verification procedure absolutely free. (http://www.callabsolutions.com ). This procedure should run right out of the box (fingers crossed) with the IEEE, VISA FSC or our VisaComm.exe for older version of MET/CAL. What we do drastically different is spate the UUT code from the standards code. This allows us to validate and lock down procedures quickly; then only up update small sections of code, fixing bugs quickly and keeping our customers operational.
8.0 is introducing the procedure package / procedure executable. Allowing user to store all the files needed to run a calibration in single file. This is something we have been recommending to customers for years. We have been an advocate of keeping your procedure in a sub directory structure abandoning that massive procedure directory. https://docs.google.com/a/callabsolutions.com/document/d/1n-qO-yICDlWbiaamtkdVBYUcYAN2jjVegOOODSIU3XQ/edit
Mike
Hopefully HarryBee doesn't mind me contributing to this thread's derailment, as I am communicating with the Original Poster (OP) about the 8594E procedure via PMs.
Quote from: RFCAL on 09-25-2012 -- 08:55:02To 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?
To Mr. RFCAL--As I mentioned, I'm not part of the Software Support group but I
will do everything I can to help resolve problems that I know about. I can't do this without more information from you. When did you contact Fluke about the problems you are experiencing, who did you speak with, and what was the nature of the problems you discussed with them? Please help me by providing as much detail as possible, as I have been using 8.0 for my own daily production since before it was released and I have not experienced problems of the magnitude you are describing. I am not saying that problems don't exist; I'm only saying that I haven't encountered them myself. Perhaps my use model is different than yours.
I think it's pretty obvious that I'm listening, so I'm not sure why you ask that question. I'm participating here and offering to provide as much assistance as I can. I can't end world hunger or anything, but if there is a problem with the software, I'll try to get it fixed. If it's a training issue surrounding the significant changes that came with the 8.0 Editor, maybe I can help with that too. I have already made many contributions to the Fluke Calibration Community forum, and will continue to do so.
Quote from: CalLabSolutions on 09-25-2012 -- 12:24:07I 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.)
Agreed. If there is a problem, let's find a solution. To do that, I need detailed information about reproducible problems, which is exactly what I'm asking for here. If a Fluke Gold procedure is broken, I can address that. If MET/CAL has a problem, I can do my best to get that fixed too. Hopefully our customers recognize the recent increase in the frequency of MET/CAL updates and MET/CAL Gold procedure releases. MET/CAL went for a VERY long time without a major update. Now, within a fairly short period of time, 7.3 was released to support modern Windows operating systems, 8.0 was released which completely updated the Editor, and 8.1 has now been released to introduce MET/TEAM. Major changes like the LIB FSC may not have been introduced rapidly before, but things are obviously changing now. Others on the development team and I are listening. MET/CAL is a great platform and an outstanding tool for helping us all get our jobs done. I'm saying this both as a Fluke employee, and also as a previous customer and long-time user of MET/CAL. Let's continue making it better! Personally, I think this is in all of our best interests, and no I'm not trying to sell you anything (that's not my department either).
Quote from: measure on 09-25-2012 -- 13:20:16Thanks 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.
measure, it is also my understanding that the file location structure was necessitated by Windows operating systems. I am also interested in providing the solution, and agree that the path to this is via an exchange of detailed, factual information. Hopefully the OP is OK with the post getting derailed, as I am continuing to provide HarryBee with assistance via PM. If not, I'm glad to post in a different thread too.
Quote from: CalLabSolutions on 09-25-2012 -- 15:11:56Yea, we get off topic, sometimes as much as 7 degrees of separation. But most of us on this site and in the community know and trust each other.
I have a couple sites I use and follow.. But non of them are as good as the PMEL Forum when it comes to metrology questions. And I like it when I am at NCSLI and someone comes up and introduces themselves with their PMEL ForumID..
That's pretty cool Mike, I'll be sure to introduce myself using my ForumID as well. ;) I will try to check in here when time allows, but as mentioned, the best way to reach support is via the Gold Support phone number or
[email protected], and I regularly post at https://community.flukecal.com/.
Quote from: NavyCalMaster on 09-25-2012 -- 21:39:14Not trying to stray off topic here, but as an everyday user of Fluke Metcal I have to say that their product is often very frustrating. It is a good thing that you can modify them and fix errors that their own programmers cannot locate. Still, it is very annoying when you download a procedure straight from their disc, that they claim has been tested and verified and it has multiple errors. Even when you are using the same standards they have "verified" the procedure with. I have run into this a lot with Tektronix scope procedures. I am not trying to make this about slamming Fluke, but when they say they verify a procedure, I really don't believe it anymore.
Hi NavyCalMaster, I completely understand your frustration. We have identified a group of Gold procedures, produced during a certain period of time, which appeared to have a variety of shortcomings. Some errors are very subtle in nature, and very difficult to locate, especially as the procedure complexity increases. Detailed descriptions from you and other customers, help us identify and correct problems more efficiently. One of the most common problems I've encountered has to be timeouts while waiting for a Tektronix TDS oscilloscope's Self Test and/or Signal Path Compensation routine to finish. Someone tried to get fancy here with countdown timers, but it sacrificed reliability. I'm a fan of the K.I.S.S. principle!
I think we have identified most of them now, but we are still working to get them all fixed and tested. In addition to fixing these procedures retroactively, we are also implementing processes to prevent errors from being introduced into new and updated procedures. Each Gold procedure CD release (which now occurs every 2-3 months) includes new procedures as well as bug fixes, so please always make sure you are running the most recently released version. Please note that even if a procedure's main revision number listed on the CD doesn't appear to have changed, one of its subprocedures may include the fix that you are looking for!
If you encounter any problems at all with the current version of a Gold procedure, please notify
[email protected] with a detailed description of the problem, and we will make sure it gets fixed as soon as possible. Bill Spath runs that group, and he seems to love telling me about procedure bugs. :D
Quote from: RFCAL on 09-26-2012 -- 09:09:36AMEN!!! to that!!We have seen the same problem and have had to fix it ourselves rather than wait for Fluke to get around to it. I have seen procedures that would not even run from the start to procedures that do not test the full performance ver from the OEM. Anyone should be verifying any automated procedure against the manufacturer's performance ver or cal procedure. As I stated before--inmy opinion,Fluke 8.0 does not live up to the hype.
Software validation is extremely important for all software, including what is produced by the OEM, sold by 3rd party vendors who write stand-alone or MET/CAL procedures, and also to calculation-only tools like Microsoft Excel. All software procedures, purchased or written yourself, need to be validated to ensure that they meet your quality system's requirements. Just because these types of products were validated at someone else's facility does not mean the same validation will hold true in yours. With that said, it is our policy to test
ALL Fluke Gold procedures before release. Previously, I acknowledged that Gold procedures released during a certain period of time did have bugs which we are now aware of, which, I believe, were introduced by not following existing policies and processes. These types of bugs are being both corrected and prevented.
Regarding MET/CAL procedures specifically, I do not agree that problems with procedure code, or the code used in external procedure utilities, points to any problems within the MET/CAL platform itself, regardless of version number. I spend plenty of time debugging newly-written procedure code, due to no fault of MET/CAL or the Editor. This has been the case since I started writing procedures in version 7.01, and has nothing to do with MET/CAL 8.0 or higher. Let's make sure that we are identifying the true source of the problem, and not laying blame or pointing fingers at something or someone for the wrong reason(s). I, for one, don't like chasing my own tail.
Quote from: CalLabSolutions on 09-26-2012 -- 12:16:50Navy/RF/Harry (and all),
It takes a lot of work to get a procedure up and running to where it is 100% rock solid. One person explained it to me in an analogy. It is like writing a thesis paper to the level that no-one can find a single error in it. It is a lot of work.
We know how complex a calibration procedure can be; and if you look at our procedure list we have the most complex procedures available in MET/CAL. Some of the people and Fluke and I have been bumping heads for years about how to write quality automated calibration procedures. At this point all we agree to dis-agree.
If you go to the Cal Lab Solutions web site you can download an Agilent DSO-X 2000/3000 verification procedure absolutely free. (http://www.callabsolutions.com ). This procedure should run right out of the box (fingers crossed) with the IEEE, VISA FSC or our VisaComm.exe for older version of MET/CAL. What we do drastically different is spate the UUT code from the standards code. This allows us to validate and lock down procedures quickly; then only up update small sections of code, fixing bugs quickly and keeping our customers operational.
8.0 is introducing the procedure package / procedure executable. Allowing user to store all the files needed to run a calibration in single file. This is something we have been recommending to customers for years. We have been an advocate of keeping your procedure in a sub directory structure abandoning that massive procedure directory. https://docs.google.com/a/callabsolutions.com/document/d/1n-qO-yICDlWbiaamtkdVBYUcYAN2jjVegOOODSIU3XQ/edit
Mike
As I'm sure you are aware, even the most perfectly written procedure that was tested and validated today, can break tomorrow when someone updates the firmware on one of the instruments being remotely controlled. The chances of this go up exponentially with procedure complexity.
I'm not sure that we disagree about how to write quality automated procedures, I think we just have different company policies in place which allow us each to use our own preferred methods.
The new PXE functionality in 8.0 should be extremely powerful. I'm excited to use it myself!
I want to play this the PXE & LIB FSCs too. They will open some doors and ideas to write better code that I closed years a go. I have some big ideas. But they are still on hold becuase users have to upgrade to MET/CAL 8.0 before I can invest in any development efforts.
From my prespective I don't get many orders for PXI calibration procedure. NI and most PXI companies provide a solution to support their products. It is good that Fluke is moving into that market, because it is a growing market. But on the same note, many of these products will require a developer with more programming knowledge and a solid understanding of COM objects.
Mike