CMM Inspection Data: From DMIS Files to SPC Charts

Why CMM output is hard to use directly

The measurement is the easy part. The CMM already did the hard work — it touched the part, computed the features, and compared each one to the print. The trouble is what it does next: it writes a report designed to be read by a person and printed on paper, not consumed by a database. Open a stack of those reports and the pattern breaks down fast.

The report layout is not fixed. It follows the inspection routine, so a program that measures twelve features looks nothing like one that measures ninety, and a revised program quietly rearranges the whole file. Features print in the order the routine ran them, not in any order your database would choose. Header blocks carry the part number, operator, machine, and datum alignment; then come the feature rows; then a summary footer. None of it lines up column-for-column between two different programs.

Then there is format. PC-DMIS, Calypso, and raw DMIS each describe the same true position callout differently — different labels for nominal and actual, different ways of writing a diameter versus a position versus a profile, different tokens for units and for pass or fail. A shop with three CMMs from two vendors is really juggling three dialects that all claim to be measuring the same part.

And the reports are not clean. Mixed into the good readings you find probe errors, points where the probe never made contact, features flagged but not measured, and numeric fields that come through as blanks or NaN when a calculation could not complete. A person reading the report skips past those on instinct. A naive parser reads them as real numbers and poisons your dataset. This is the same class of problem as any CNC and CMM data mapping job — the machine is precise, the export is not structured for reuse.

Mapping it to a consistent per-feature schema

The goal is to stop thinking in reports and start thinking in features. One CMM report is not one record — it is one part, made up of many feature measurements. The useful unit is the feature row, and every feature row, no matter which machine or program produced it, should land in the same shape.

A workable per-feature schema is small and boring on purpose: part identifier, feature name or characteristic, nominal, actual, deviation, tolerance (upper and lower), and result. That is enough to chart anything. The part identifier ties every feature back to the physical part and the lot. The feature name has to be normalized — "DIAM_1", "Dia 1", and "D1" from three programs are the same characteristic and need to map to one canonical name, or every downstream chart splits into three. Nominal, actual, deviation, and the tolerance band are the numbers SPC actually consumes. Result is the pass or fail, but it should be derived and checked against the tolerance band rather than blindly trusted from the report.

The map is the piece that does this translation, and each CMM format needs its own. It knows where PC-DMIS writes the actual value versus where Calypso writes it, which header line carries the part number, and which rows are noise. Once that map exists for a given export, every future report from that machine flows through it the same way, in a fraction of a second, without anyone opening the file. This is manufacturing data mapping applied to metrology: the map is the asset, and the ugly report becomes structured feature data.

Handling rejects: quarantine with reasons

Not every feature row is a real measurement, and the system has to make that call explicitly. A probe error, a no-touch point, a feature that was skipped, a numeric field that comes through as NaN, an actual that lands wildly outside any plausible range — each of these is a row that should not enter the clean dataset as if it were a valid reading.

The rule that keeps this honest is that nothing gets silently dropped. When a feature row fails validation, it does not vanish and it does not get quietly averaged away — it goes to a quarantine, tagged with the reason (probe error, out of tolerance, missing actual, unparseable field) and the raw line it came from. Out-of-tolerance readings are a special case: they are not bad data, they are real fails, and they belong in the dataset flagged as fails, not discarded. What gets quarantined is data you cannot trust as a measurement at all.

This matters more in inspection than almost anywhere, because a quality dataset that silently loses its probe-error rows looks complete while it is lying to you. A quarantine with reasons flips that around: every rejected row is visible, counted, and explained. When a routine changes and the export shifts, you get a pile of quarantined rows with a clear cause instead of silent data loss — which points straight at the map that needs updating.

From clean data to SPC, Cpk, and scrap tracking

Once every feature row lands in the same schema, with rejects quarantined and fails flagged, the analytics everyone actually wanted become straightforward queries instead of spreadsheet marathons.

Statistical process control needs a stream of actual values for one characteristic over time, and that is exactly what a normalized feature name gives you — pull every "DIAM_1" reading in run order and the control chart draws itself, updating as new reports flow in. Cpk needs the same stream plus the tolerance band, both of which are now columns in the schema, so process capability becomes a calculation rather than a manual data-gathering exercise. You cannot compute an honest Cpk if a fraction of your readings never made it into the dataset, which is why the quarantine step comes first — capability numbers are only as trustworthy as the completeness of the data underneath them.

Scrap tracking falls out of the result and deviation fields. Filter to the fails, group by feature, and you can see which characteristic is driving rejects, on which machine, on which shift. That is the point where dimensional inspection stops being a paper record and starts feeding the same kind of yield and scrap analytics you would build on any tool data. It all rides on top of the unglamorous mapping and validation work, and a solid data infrastructure underneath keeps the feature history queryable as it grows into millions of rows.

First-article inspection as a downstream use

There is a second payoff hiding in the per-feature schema, and it shows up at first-article inspection. An FAI — an AS9102 form in aerospace, or an equivalent PPAP-style package elsewhere — is fundamentally a table: every characteristic on the print, its nominal, its tolerance, the measured actual, and pass or fail. That is the schema you already built, arranged for a specific report.

When the CMM output is already mapped to clean feature records, generating the first-article package stops being a retyping exercise. Instead of an engineer transcribing a CMM printout into an AS9102 form by hand — the step where transposed digits and skipped characteristics creep in — the actuals populate straight from the same validated data your SPC charts use. The FAI and the ongoing capability study are drawing from one source of truth, which is exactly what an auditor wants to see. It is the clearest example of a broader rule: do the mapping once, cleanly, and every downstream use — SPC, Cpk, scrap analysis, first-article reporting — gets easier at the same time.

How to start: send us one CMM report

You do not need to touch the CMM or its software to begin. You need one export — a DMIS listing, a PC-DMIS printout, a Calypso report, a TXT or CSV dump. That single file shows us the layout, the format's dialect, the feature rows that matter, and the probe errors and no-touch points hiding among them.

From a real sample we can show you exactly what the mapped per-feature output looks like, what the quarantine catches, and how the same data feeds an SPC chart and a Cpk number. No changes to the machine you already own — just a translation layer between the report it prints and the dimensional data you can build on. Start with one report from the CMM everyone relies on. That is all it takes to see the rest.