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.
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?
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 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.
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.
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.
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...
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.
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?
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
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
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.
you know, I know you work for Fluke and you REALLY don't want me to post all my concerns.
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?
I'll save it for the Fluke user group meeting at NCSLI
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.)
•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.
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.
Quote from: Hawaii596 on 07-07-2011 -- 19:14:26This 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
Quote from: CalLabSolutions on 07-08-2011 -- 01:22:09Hawaii, 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?
Quote from: CalLabSolutions on 08-10-2011 -- 15:39:50I 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?
(http://images9.fotki.com/v114/photos/1/134180/5291524/cls_actual-vi.jpg)
Quote from: CalLabSolutions on 08-12-2011 -- 20:00:31
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.
Quote from: RFCAL on 08-14-2011 -- 19:13:34
•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).
Thanks for the responses.
Quote from: RFCAL on 08-14-2011 -- 19:13:34
•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.
Quote from: RFCAL on 08-14-2011 -- 19:13:34
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?
Quote from: RFCAL on 08-14-2011 -- 19:13:34
•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.
Quote from: RFCAL on 08-14-2011 -- 19:13:34
•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.
Quote from: BuffaloWings on 08-15-2011 -- 11:02:08
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
Quote from: CalLabSolutions on 08-15-2011 -- 12:11:20
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 SWITCHINGI'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?
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.
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.
Quote from: BuffaloWings on 08-15-2011 -- 13:40:14
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?
Quote from: CalLabSolutions on 08-15-2011 -- 13:51:49
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.
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!
Quote from: measure on 08-15-2011 -- 14:00:11
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!
To bad you wont be there.. You will be missing a great paper on MET/CAL Programming..
Maybe next year..
Mike.
It would be nice if they could incorporate MET/TEMP and Compass into MET/CAL. I think as of now they already communicate with MET/TRACK and use Crystal Reports, but it would be nice if they used procedures the same way as MET/CAL, e.g. if I could write or download a procedure to calibrate (for instance) a TI30 infrared gun using a blackbody and have it report the uncertainties, rather than having to manually configure MET/TEMP everytime a calibration is done and attempt to calculate the uncertainties by hand (not even knowing what all uncertainties go into an infrared calibration using a blackbody).
Scott I agree, but currently they don't so we have created a set of drivers (sub procedures) to calibrate IR guns and and other items in MET/CAL. We have a large librarty of Interchangable drivers we use in place of FSC to support Flexible Standards. This has came in very handy as we have started updating the drivers to include expaded uncertanties.
This issue of Cal Lab Magazine's then "Metrology 101" article is on IR Calibration. Frank also did some uncertainty bugets that we plan on posting Online.
The e-copy of the magazine is already posted Online.. The printed copy is being mailed.. And If you plan on attending NCSLI, we will have copies at booth 203.
Quote from: CalLabSolutions on 08-16-2011 -- 14:04:43
And If you plan on attending NCSLI, we will have copies at booth 203.
Cool... See you there. :-D
Quote from: BuffaloWings on 08-15-2011 -- 11:02:44
....
- Out of curiosity, 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.
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.
Yes we also have a work around for these problems as well, any good programmer can figure out how to get it done. But if you look back at this thread there are a lot of people saying they see no value in upgrading MET/CAL. I have followed MET/CAL for years, been to several user group meeting. Heard the requests, and seen the feature added with each update.
Sense the IF FSC, I have not seen any upgrades that help me (as an advanced programmer). And before that it was JMPL.. But I solved that problem with MATH MEM=MEM to keep my jump destinations the same as I edited code and the line numbers changed.
I don't have access to MET/CAL source code, so I am not 100% sure. But I have requested a few features I believe are easily feature enhancements. I don't want to delay 8.0 but I need a reason to tell my customers they need to upgrade to 8.0.
I hope some day we will have an opportunity to meet.
I don't have much time to read many of these threads. Buffalo Wings asked if I was sure about the upgrade price for MetCal. My understanding is that we have a couple of lab sites which run MetTrack and MetCal and have numerous licenses. I am not involved in the details of these upgrades or purchases. I just know that I was told that bottom line for all of the license we have would come to around $50K or so. I can't substantiate it, that's what I was told. I can get clarification if it sounds like someone is figuring something out incorrectly. I think there are somewhere around 10 licenses (not exactly sure about that figure either). If there is something seriously amiss about the dollar amount I mentioned, I'd like to figure it out.
I do not believe the $50K price.I think it is more around 10K.We also have 10 licenses and that was the price we were told.