9640A with 8594E fluke procedure

[CalLabSolutions]

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..

[NavyCalMaster]

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.

[RFCAL]

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.

[CalLabSolutions]

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

[Chad Dodds]

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.

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?

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.

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.)

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).

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.

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.

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..

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 softwaresupport@flukecal.com, and I regularly post at https://community.flukecal.com/.

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.

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 softwaresupport@flukecal.com 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.

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.

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.

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

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!

[CalLabSolutions]

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