Hexcon Datage Statistical Analysis: Real-Time Monitoring and Rapid Problem ID

• 1
  Key takeaways
• 2
  What hexcon datage statistical analysis actually does
• 3
  How readings travel from gauge to control chart
• 4
  Why the gauge decides whether SPC works
• 5
  Real-time monitoring: what changes on the floor
• 6
  When real-time SPC does not pay off
• 7
  When real-time SPC fits, and when it does not

Most machine shops already generate more measurement data than they can read. A CMM running PC-DMIS writes a report per part. A vision system writes another. Calipers and micrometers write nothing at all unless someone types the numbers in. The bottleneck is not collecting data, it is joining it up and reading it before the next batch starts.

Hexcon Datage sits between the measurement devices and the decision. It pulls readings from PC-DMIS CMM, PC vision and portable PC-DMIS, plus manual instruments, into one dataset keyed by part number, feature and timestamp. Once the readings share a common structure, statistical analysis can run on them continuously instead of in a quarterly review.

The value is not the dashboard. The value is the lag time between a process drifting and someone knowing about it. If that lag is three days, you have already shipped the bad parts. If it is three minutes, you can adjust the offset or stop the machine.

This page explains the mechanism, the boundary conditions, and the cases where real-time SPC does not pay for itself. Nothing here requires a specific software vendor. The logic holds for any system that joins metrology data to a control chart.

The first stage is acquisition. A touch trigger probe on a CMM reports a point coordinate. A vision system reports an edge position in pixels, converted to millimetres. A hand micrometer reports a diameter. These arrive in different formats, at different rates, and with different levels of trustworthiness.

The second stage is normalization. Each reading needs a feature ID, a nominal value, an upper and lower tolerance limit, and a unit. Without a nominal and tolerance, a reading is just a number. The tolerance band is what turns a number into a pass or fail, and later into a deviation trend.

The third stage is statistical reduction. The software computes subgroup means and ranges, then plots them against control limits derived from the process itself, not from the drawing tolerance. This distinction matters. A process can be in control and still produce out-of-tolerance parts if the control limits sit wider than the tolerance band.

The fourth stage is presentation. The output is a chart the operator can read at the machine, plus an alert when a rule fires. A typical rule set is Western Electric or Nelson: one point beyond three sigma, two of three beyond two sigma, or a run of seven on one side of the mean.

• 1
  Feature ID ties every reading to a drawing calloutWithout it, data from different machines cannot be compared.
• 2
  Control limits come from the process, not the printThey show what the process is doing, not what it should do.
• 3
  Alerts must reach the operator, not the inboxA chart nobody reads changes nothing.

Statistical process control assumes the measurement system is stable and capable. If the gauge itself drifts, the chart shows process variation that is not real. Worse, it may hide real variation behind gauge noise. This is why a gauge repeatability and reproducibility study comes before any chart is trusted.

The common acceptance criterion is that gauge R&R should be under 10 percent of the tolerance band for critical features, and under 30 percent for non-critical ones. Above 30 percent, the measurement system is contributing more variation than the process, and charting becomes guesswork.

For tight work, this is not academic. A feature held to ±0.005 mm has a total tolerance band of 0.01 mm. A gauge that repeats to ±0.002 mm already consumes 40 percent of that band. No amount of statistical software fixes an incapable gauge.

This is also why mixing measurement systems in one chart is dangerous. A CMM reading and a caliper reading of the same diameter will not agree to the last micron. If both feed the same control chart, the chart shows a step change every time the measurement method changes, and the operator chases a problem that does not exist.

Real-time monitoring means the data reaches a decision point while the part is still in the machine or on the bench. In practice, this shows up as a screen near the machine, an andon light, or a message to the operator's terminal. The mechanism is simple: a rule fires, a signal appears, someone acts.

The engineering value is in the reaction, not the display. If an offset drift is caught after five parts instead of fifty, the scrap is five parts instead of fifty. For a part with significant material and machining time, that difference alone can justify the system.

But real-time also raises the bar on false alarms. A system that fires ten alerts a shift gets ignored by the second day. Rule thresholds must be tuned to the actual process capability, and the alert rate kept low enough that each one means something.

There is also a human factor. Operators need to know what action each alert calls for. An alert without a defined response is noise. The best implementations pair each rule with a one-line instruction: adjust offset by X, check tool wear, or quarantine the last N parts.

One-off prototypes and low-volume jobs gain little. If a part is made once, there is no process distribution to control. The measurement data is still useful for verifying the part, but control charts add no value.

Parts with a single dominant failure mode that is not dimensional also gain little. If the risk is a surface finish defect or a porosity issue, dimensional SPC will not catch it. The right tool is a different inspection method, not a tighter control chart.

Very loose tolerances are another boundary. If a feature is held to ±0.5 mm and the process naturally runs within ±0.05 mm, the chart will sit flat and tell you nothing. The process is already capable by a wide margin, and monitoring effort is better spent elsewhere.

Finally, a shop without stable fixturing or a repeatable setup will see chart noise from setup variation, not process drift. The fix is fixturing and setup discipline, not more statistics. Data analysis amplifies a stable process. It does not create one.

• 1
  One-off parts: verify, do not chartThere is no distribution to control.
• 2
  Non-dimensional risks: use the right inspection methodSPC only sees what is measured.
• 3
  Unstable setups: fix the fixture firstChart noise from setup is not process drift.