If your calibration laboratory has relied on Fluke MET/CAL® for any length of time, you already know the routine. An upgrade comes along, promises a shiny new interface and minor speed improvements, and you spend a few weeks or months testing and installing the update.
But MET/CAL® 11 is different. This isn’t just a routine version bump. Fluke has fundamentally changed how power sensors are managed. And because of that architectural shift, every single MET/CAL procedure in your library that uses a power sensor will have to be rewritten. Take a moment to let that sink in. Every RF generator calibration, every spectrum analyzer procedure, and every other procedure that uses a power sensor will need to be rewritten.
Suddenly, your “upgrade” path has turned into a massive, multi-month software development project.
But before you assign your best metrologists to write thousands of lines of legacy code all over again, you need to ask a critical business question:
Is it cheaper to pay the MET/CAL® 11 “rewrite tax,” or is it finally time to migrate to Metrology.NET®?
The Core Problem: Hard-Coded Chains
The fundamental flaw of the traditional MET/CAL® model is that your Reference Standards are deeply tied to the UUT (Unit Under Test) Procedure. When you write a MET/CAL® procedure, you aren’t just telling the system how to test the UUT; you are coding how to control the specific reference standards used during that test. If you want to change the standards used, that is a whole new rewrite.
This architectural design creates a massive bottleneck. You are forced to maintain a colossal library of individual procedures that only work with very specific hardware setups. When the software vendor changes the rules under the hood—as they have with MET/CAL® 11—your legacy code becomes a liability.
The Metrology.NET® Solution: Separation of Concerns
At Metrology.NET®, we looked at this problem years ago and engineered a completely different approach. We don’t code the Reference Standards into the UUT Procedure.
Instead, we use a model-driven, hardware-abstracted architecture. In Metrology.NET®, a procedure is strictly focused on the UUT itself. It defines what needs to be measured (e.g., “Measure.Power.RF.Sinewave Frequency= 10 GHz Power= -10 dBm”).
The metrology engine handles the rest. It looks at what equipment the technician wants to use and runs the code with that equipment, “if the equipment is able to do that test!”
Because of this:
- One procedure supports every power sensor from any manufacturer. It just needs a driver.
- Whether you are using a legacy Hewlett-Packard sensor, a modern Keysight USB sensor, a Rohde & Schwarz sensor, or any other power measurement equipment, the UUT procedure remains 100% untouched.
- If a power sensor goes out for calibration or breaks down, you don’t rewrite a line of code. You simply plug in a different sensor, and the system adapts instantly.
Doing the Math: The ROI of Migrating vs. Rewriting
Let’s look at this purely as a business decision.
Imagine your lab has 150 MET/CAL® procedures that utilize a power sensor in some capacity. If you upgrade to MET/CAL® 11, you have to rewrite them.
Option A: The MET/CAL® 11 Rewrite
- Average time to rewrite, debug, and verify one procedure: 8 hours (for simple to moderately complex RF procedures).
- Total labor hours required: $150 \text{ procedures} \times 8 \text{ hours} = 1,200 \text{ hours}$.
- Estimated cost of engineering labor: At an internal cost of $100/hour, that is $120,000 in engineering time.
- The Catch: At the end of this massive expenditure, you still have the exact same legacy, locked-in MET/CAL® system you had before. If they change the hardware rules again in MET/CAL® 12, you will pay the tax all over again.
Option B: The Metrology.NET® Migration
- The Process: Instead of rewriting 150 legacy procedures, you transition to Metrology.NET’s model-driven platform.
- The Code savings: Because Metrology.NET® decouples UUTs from standards, you don’t need 150 different procedures. You might only need a fraction of that number because a single Metrology.NET® procedure dynamically handles any hardware configuration you throw at it.
- The Result: You spend your budget once on modernizing your lab infrastructure, and you never have to rewrite a procedure due to a hardware swap or software update again.
For many calibration laboratories, the labor cost of rewriting legacy MET/CAL® code to support MET/CAL® 11 is actually higher than the total cost of migrating to Metrology.NET®. This is why our Metrology.NET® Pricing is 50% less than the same work done in MET/CAL.
Stop Paying the Rewrite Tax
Software upgrades should make your life easier, not saddle your engineering team with months of tedious, repetitive rewrites.
If MET/CAL® 11 is forcing you to rebuild your power sensor workflows from scratch, don’t build them back in a legacy, hard-coded environment. Build them for the future with Metrology.NET®.
By separating your UUT procedures from your reference standards, Metrology.NET® gives your lab the freedom to run any power sensor, from any manufacturer, on any bench—with zero code rewrites.
Your Lab, Your Choice.
Contact Cal Lab Solutions today to see how we can help you escape the endless rewrite cycle and transition your lab to a truly open, model-driven ecosystem.