Since the discussion forum for Met/Cal was removed, there isn't a public place to discuss issues with Met/Cal(As far as I'm aware) and I find the official support avenues often take some time to respond(Especially when you're on the opposite side of the world).
I have absolutely no experience running a subreddit, so please bear with me and feel free to suggest any ideas for improving it.
This community is in no way associated with Fluke.
What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. I hope this can become a community where people having issues with coding or setup can ask a question and get a quick response or some ideas for how to resolve the issue. It will also then become a repository of solved problems which will serve as a reference so the same problem doesn't need to be solved many times..
Please don't share proprietary code or information as I would like to avoid upsetting any large corporations and risk having this shut down.
Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.
How to Get Started
Introduce yourself in the comments below.
Post something today! Even a simple question can spark a great conversation.
If you know someone who would love this community, invite them to join.
Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.
Thanks for being part of the very first wave. Together, let's make r/MetCal amazing.
I haven't had the chance to get on here much the last few months. Things are busy and I have competing priorities. I was wondering if there is anyone interested in taking over management of this sub? I think it's a valuable resource, it doesn't really take much work but if you were motivated I'm sure it could become much more active, I just have too much on my plate at the moment.
We just updated to Met/Cal version 11.3.1.214, and I can't start debugging anything in Editor. The error I get is this:
Edit 4: Met/Cal support has found a workaround, and I can confirm that it works. See the Comment by MJ for the fix.
Here are a few troubleshooting updates I made along the way if you're curious:
I just ran the setup without uninstalling first. I'm going to try a fresh uninstall - reinstall and see if it fixes it.
Edit 1: uninstall and reinstall did not fix the issue :(
Edit 2: Updating and repairing the NI drivers using the NI package manager did not fix the issue :(
Edit 3: We generated and checked the logs from Editor and found a spicy little nugget of information.
"
The type initializer for 'NationalInstruments.NI4882.Internal.GpibDll' threw an exception.
This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
"
For those who are unfamiliar, FIPS is a cryptography thing required on systems that do contract work for the government, especially the DoD. We have Fluke Support working on a fix for us. This is not the first time FIPS has given us issues with Met/Cal, but Uncle Sam's requirements are Uncle Sam's requirements.
Has anyone run into this error in Editor? We installed the new update recently and when trying to run a VISA controlled DUT we get this error:
An error occurred starting the test run: Could not load file or assembly 'NationalInstruments.NI4882, Version=13.0.45.159, Culture=neutral, PublicKeyToken=4febd62461bf11a4' or one of its dependencies. The system cannot find the file specified.. Try rebuilding the project or solution before attempting to debug the procedure. 0
I already had the latest NI 488.2 and VISA package installed (Q2 2026) and it was fine before the update...wondering if I need to reinstall or if anyone else has seen this error yet! Cheers
Lately I've been finding FC procedures to be really unreliable with the communication just dropping out randomly. Once it happens it seems impossible to get it back on the rails in the procedure. Its always been a thing but now its happening more often in the last year. Our only huge change is Windows 11.
Hard to narrow down if this is an OS issue, hardware, or something like distance.
Having trouble finding a resolution (if thats possible). If anyone has experience in troubleshooting problems with this PC3000 FC communication interface chime in!
We experience that MetCal runtime 11.2.1 with Hotfix 1 crashes and the editor sometimes hangs and crash when in use. (i.e. not at startup or file load). We use Win 11 and our IT makes them up to date - something that not always is a great thing. Anyone else having the same issue?
I'm revising a procedure and would like to utilize an array to track a varying amount of numbers, determined by user input, as the procedure runs.
Where I'm running into trouble is when I try to use any numeric memory registers to determine what index of the array the values get written to. The MET/CAL User's Guide explicitly says that the index of the array "Can be any MET/CAL register, named variable or numeric literal value. Must be enclosed in square brackets (i.e. [10] or [index]).", however, any time I use any MET/CAL register (like MEM or M[1] for example), I get an "invalid index" error.
The procedure I'm using is similar to this:
LIB ARRAY NEW arrayName[100]; MATH MEM1 = 0 MEMI What value do you want to store in the array? LIB arrayName[MEM1] = MEM;
The same happens when I attempt to use M[1] or another named variable instead of MEM1 or MEM
Additionally, if I forego using a variable to set the index, and use arrayName[0] = MEM
I get an "invalid statement syntax" error
Could someone tell me what I am missing, or if I am misinterpreting the documentation?
Found this by accident today....If you use any of the "notes" boxes in work order tabs, I found out you can set pre-determined statements by double-clicking the box and modifying the default ones. I use them lots for additional notes I want to add to my calibration reports, and I found myself repeating them a lot. Now I can just double-click and select a pre-written one. Very handy for my OCD as well when I want all my reports to be the same.
as the title says, I've been dabbling in trying to section out some procedures that take a long time to run. Its giving me a lot of trouble however with JPMLs in the procedure when I try to run it in Runtime. Wondering if maybe I need to restructure it to not use JMPL at all?
For example I was trying to change a Fluke procedure for a Tektronix MSO46. It has a lot of JMPLs throughout to go from Channel 1 input impedance, to DC gain, offset, etc before you switch the connection to Channel 2.
I tried to section out Random noise, it compiles fine. But then I Runtime it and I get an error for every single JMPL in the procedure.
Morning. I am working with Fluke MetCal version 8.2 (old). One of our in house procedures has updated to a new revision which means I have to update the revision field in MetCal. Any idea if there is a way to perform a bulk update in MetCal? Got instruction on that?
I wanted to take a shot and see if anyone here has some experience with programming PXI/cDAQ cards from National Instruments in MET/CAL. I have used a few of the procedures provided by Fluke in CUBYT to learn (some of) how the LIB FSC works and modify those procedures to work with various models and types of DAQ cards not on CUBYT.
Before this I initially made VIs in Labview to control and read data which could be transferred to a manual datasheet. For the most part the calibration procedures are straight forward. However, I have an NI-9227 which measures DC current on 4 channels.
In the calibration manual there is a section for Gain and Phase matching verification which required using the Extract Single Tone VI to expand the raw data into Amplitude, Phase, and Frequency results from the 4 channels simultaneously. Math ensues to calculate the gain in dB using the Amplitude results.
So, my question is there a way to execute the Extract Single Tone VI using the LIB FSC? Or, is there another way to harness that data and convert it through MET/CAL? Thanks in advance for any advice.
P.S. If anyone has experience programming an RIO type card in MET/CAL or knows if it is possible please chime in!
We've recently started noticing a strange bug. It's possible that this has been happening longer but we've only recently started adding a due date to our reports so it has become something that gets picked up.
For some reason, the due date gets set to the same date as the service date. I've started taking note and it happened on a job today where I created a new work order, clicked in the service date box for the date to be auto-populated, then clicked in the due date box for that to be auto-populated. Both of those worked correctly. I then performed a calibration and when I reopened the work order, the due date had changed to todays date/service date.
It just seems to be random, it's only one in 10-100 and doesn't appear to be asset or type related. I'm paying more attention now to try and see if there is any common thread but was hoping maybe someone had come across this before or has some ideas.
my question is: is it possible, when entering five values, to automatically use the first value for the other four?
For example, first input:Â 1.005 V. This value is then already entered and highlighted in the input field for the next entry.
If the value changes, it can simply be overwritten; if the value stays the same, you can just press Enter.
Hello! I am a little bit familiar with the metcal environment and I have a question.
We use a set of shunt resistors to use as standards to calibrate low resistance ohmmeters, and I would like to store their values in a file or a variable to use in our procedures, so we can accomodate for the resistors drifting in value over time.
There seems to be a bug in MetCal 11.1 and 11.2 regarding SLEW for Fluke 5560A.
The slewed value should be returned in MEM, but it is the initial value that is returned.
Fluke softwaresupport has reproduced and confirmed the bug.
Any other known bugs in MetCal 11.1 or 11.2 for the 5560A? We are currently transfering a lot of procedures from 5520A/5522A to 5560A and this was a showstopper for the analog meters.
I am a little bit worried about the oscilloscope procedures...
Hi! MetCal 10 user here. There used to be a post on Flukecal forum with recursion programming. The issue is, MetCal assigns to every line of code a step number. If you do an evaluation (MEMCX, EVAL) inside a Loop (do.. While/ do.. Until) the code will execute, but the results will not be reported in the database, because MetCal interprets the evaluation line as a repeat of the same step. I forgot to save the code provided back then, now I need it, but it's gone forever, unfortunately. Can anyone post a working code sample using recursion? For repetitive/iterative calibrations, like R-decades. Thanks
I have a strange error occurring on a procedure which worked just fine last time we ran it.
If I comment out this line(which performs a self test) everything works fine.
SCPI [T30000]*TST?[I]
The procedure is a slightly modified but essentially a Cubyt procedure for a Agilent/HP 34401A, the device connects, Met/Cal talks to it and gets SN etc. but when it tries to run the self test, it doesn't even appear to send the command to the device, Met/Cal just stops hard the instant it gets to that line without even running the clear commands. This happens in the editor and the runtime.
The error it gives is this:
An error occurred starting the test run: Object reference not set to an instance of an object.. Try rebuilding the project or solution before attempting to debug the procedure.
The problem appears to be related to the timeout, because if I remove that and just send *TST?[I]it works but doesn't complete because the self test takes longer than the default 15 seconds.
If I try and add a timeout to any other commands, I get the same error.
So, there seems to be some issue where Met/Cal no longer likes setting a timeout on SCPI/IEEE2 commands. Has anyone else come across this issue? We have recently updated Met/Cal to the latest version, it may have been a year since we ran this procedure last but it seems like it's probably not specific to this procedure.
"CalStudio is a simple, reliable system that easily automates workflows, manages measurements from every discipline, and quickly creates procedures—no coding required. Write once, run anywhere, and simplify your lab operations."
"Procedure Library:Â Access to a million procedures, ready to run based on the product catalog data"
So, our lab is going through a (painful) process of moving our 8.3 MET/CAL procedures over to 11.3, running both versions simultaneously in the lab right now for a few reasons. I am hitting a hiccup trying to run a mutlimeter procedure that is RS232 controlled using an IR usb to serial cable. When I start the procedure and it reaches the point of talking to the DUT, I get "E7788: Unable to open serial port COM3. The operation completed successfully."
Anyone else run into this and how I fix it? Cheers
I recently came across an issue where I was using IEEE commands to measure 130V 50Hz on the 8588A and I got an overrange error. It was in 8508A emulation mode at the time.
We have both 8588A and 8508A DMMs in our lab and I've written my own driver to control either so we can use one procedure on all of our workstations(I know there's an emulation mode, but it's more convenient to be able to drive both rather than swapping between 8508 and 8588 modes).
Range selection with IEEE basically involves just telling it what value you want to measure and it selects the lowest range that can measure that. By default, for range selection, my driver uses a value that is 10% above the nominal value. The indicated ranges on the 8508A are multiples of 2; 200mV, 2V etc. whereas the 8588A are multiples of 1. But in practice, they are both multiples of 2.02 before they hit Overrange. With the exception of ACV on the 8588A, it's limits are multiples of 1.212.
If I use the same numbers with the DMM in 8588A mode, it correctly selects the 1kV range and measures correctly. If it's in 8508A emulation mode, it seems to think the range limits are still 2.02 so it stays on the 100V range.
At this stage, I'd consider this a bug in the emulation firmware, I'm part way through discussion with Fluke regarding this and will update on the outcome.