Measurement your team can trust, automated end to end
Test and measurement systems combine sensors, DAQ hardware, and software into rigs that characterize products and processes with numbers you can defend. They remove measurement doubt — the situation where a test says the part passed, but nobody is quite sure the fixture, the sensor drift, or the operator's technique did not decide the result.
Willowark builds from the measurement backward. First we establish what accuracy the decision actually requires and budget the error: sensor tolerance, conditioning, ADC resolution, fixture repeatability, and environment all get a line item. Then hardware is selected to meet the budget with margin, because a system with unknown error bars is not measuring — it is generating numbers.
R&D & PrototypingHow the work gets done
The same way every time: scope, build, hand over.
The stack typically includes transducers matched to the physics — load cells, pressure transducers, thermocouples and RTDs, accelerometers, current probes — with signal conditioning that respects each one: excitation, cold-junction compensation, anti-alias filtering, isolation where ground loops threaten. DAQ hardware ranges from NI and compact industrial modules to embedded acquisition where cost or channel count demands it. The software layer sequences tests, enforces fixtures and settings so operators cannot improvise, and stores raw data alongside computed results, because the raw record is what saves you when a result is questioned two years later.
In operation, the system produces the same answer for the same article regardless of who runs it — demonstrated, not assumed, through gauge repeatability studies where the application warrants them. Calibration is scheduled and traceable, drift is monitored, and reports come out formatted for the audience: engineering wants the curves, quality wants the Cpk, the customer wants the certificate.
Scoping begins with the decision the measurement feeds. A pass/fail screen with a wide margin needs far less than a characterization that will set a datasheet limit, and the difference shows up in every line of the hardware budget. We write down the required accuracy, the measurement range, the throughput, and the environment the rig will live in, then design the simplest system that meets them with margin. Validation is planned at the same time: what reference article or known standard will prove the rig reads true, how repeatability will be demonstrated, and what a recheck looks like after a sensor is replaced.
Occasionally the first thing a new rig reveals is that the previous test was wrong, or that the product's real distribution is wider than anyone believed. That is uncomfortable, and it is also the point — a measurement system exists to replace belief with evidence. All hardware documentation, wiring diagrams, fixture CAD, software source, and calibration records are delivered in editable form and are yours. If the rig later needs to be duplicated for a second line, another site, or a contract manufacturer, the package is written so the copy reads the same as the original, with the validation procedure to prove it.
Scope it in writing
What we agree before work starts
- Measurement uncertainty budget tied to the decisions the data feeds
- Instrumented test rig: sensors, conditioning, DAQ, and fixturing
Build with checkpoints
Working results, not slide decks
- Test sequencing and analysis software with raw-data retention
- Calibration plan with traceable references
Hand over something you own
Documentation, source, and training
- Repeatability validation and system documentation
- Complete documentation package: wiring, fixture CAD, software source, and calibration records
Sound familiar?
Where test & measurement systems earns its keep.
A pump manufacturer that needs pressure-flow curves on every unit, not just the engineering samples
A test currently run with a hand-held meter and a clipboard, producing data nobody fully trusts
A warranty dispute that showed the company its test records could not survive scrutiny
A new product that needs thermal and electrical characterization across its full operating envelope
Ask about Test & Measurement Systems
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
X-ray thickness gauge
Components:
- X-ray source (+ detector): Source and detector pair measuring attenuation through the material.
- Acquisition (signal chain): Signal conditioning and acquisition.
- Gauge software (thickness model): Calibrated model converting attenuation to thickness.
- Line control (feedback): The line's controller, closing the loop on thickness.
Connections:
- X-ray source to Acquisition
- Acquisition to Gauge software (calibrated)
- Gauge software to Line control (thickness)
An industrial measurement company · Industrial measurement
X-ray thickness gauge
A complete X-ray based thickness gauge: equipment assessment, hardware selection, electrical and hardware engineering, API integration, all software, and commissioning — delivered as a working instrument.
Read the case study →Common questions
Asked before every test & measurement systems project.
Our current test gives different results depending on who runs it. Can that be fixed?
Almost always — operator-dependence usually traces to fixturing, timing, or judgment calls the procedure leaves open. We engineer those out: fixtures that locate the part the same way every time, software-enforced sequences, and automated pass/fail criteria. A repeatability study before and after quantifies the improvement.
Do you only work with high-end DAQ hardware like NI?
No — the uncertainty budget picks the hardware. Some measurements genuinely need precision DAQ and careful conditioning; plenty are well served by industrial modules or embedded acquisition at a fraction of the cost. We spend the money where the error budget says it matters and are happy to show the math.
Can the system integrate with our quality management system?
Yes. Results can post automatically to your QMS, MES, or database, keyed by serial number or lot, with the raw data archived and linked. That turns test records from files on a bench PC into queryable history — which is usually where the long-term value of the system lives.
How much accuracy do we actually need?
Usually less than the instinct to buy the best sensor suggests, and occasionally more. The honest way to answer is to look at the decision the measurement feeds — a spec limit, a sort threshold, a datasheet claim — and work out how much error the decision can tolerate without changing. That number becomes the uncertainty budget, and the hardware follows from it. We are happy to walk through the arithmetic, because it is usually the most cost-relevant conversation in the project.
Can the rig keep up with our production rate?
That is a requirement we take at the start, alongside accuracy, because the two trade against each other. Longer settling times and averaging improve precision; throughput pushes the other way. Where a line rate is fixed, we design the fixture and sequence around it — parallel stations, pre-staging, or measuring only what the decision needs — and say plainly if the accuracy required cannot be reached in the cycle time available, so the choice is yours rather than a surprise.
Where this sits
Test & Measurement Systems, inside a r&d & prototyping system.
The lit component is the part of the system this service delivers; the rest is what it has to work with.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Requirements become a bench prototype with real sensors and firmware; a test rig produces data; a pilot unit runs in the field; and the design is handed to production with everything documented.
Components:
- Requirements: What it must measure, survive and cost.
- Bench prototype (MCU + sensors): Dev board, real sensors, real signal chain.
- Firmware: Acquisition, processing, comms, update path.
- Test rig (data): Instrumented tests against known references.
- Pilot unit (in the field): A handful of units where the product will live.
- Production (handoff): Drawings, BOM, test procedure, firmware — yours.
Connections:
- Requirements to Bench prototype over handoff
- Bench prototype to Firmware
- Firmware to Test rig over serial
- Test rig to Pilot unit over handoff
- Pilot unit to Production over handoff
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.