When to dress a grinding wheel is usually decided by habit, by a periodic stylus measurement or by a burnt part. The process signal knows earlier. This article describes the model we developed on real data from the lab's tool grinder, how it is split between the AI box and the central server, and what its acceptance run looks like.
The index
The model combines acoustic emission and spindle current into one indicator of wheel condition, computed only while the wheel is actually cutting. It was developed and validated on recorded passes from the lab's tool grinder, not on synthetic data.
Two-level gating
The model was validated on in-cut data only, so it must only ever see in-cut data. Two levels of gating guarantee that: the machine's own trigger marks the pass, and inside the pass a second gate marks the physical cut. Both are evaluated at the edge, so the model sees exactly one in-cut window per pass and nothing else.
Split by design
| Half | Runs where | What |
|---|---|---|
| Sharpness index | The AI box, as an ordinary ML blueprint | Gating, features and the model; the score is published as a signal |
| Decision supervisor | Central server | Turns the history of scores into advice on when to dress |
The platform's model operator is stateless by contract; the decision logic is not. Splitting the model keeps each half where it belongs: the stateless index runs next to the raw stream, the stateful supervisor runs centrally and exposes its advice and the score history as chartable, recordable signals — the future source of a controller write-back, which is designed as a guarded seam and deliberately disabled today.
Parity, not vibes
The offline pipeline and the platform pipeline must produce the same feature vectors from the same window. The artifact ships with a golden sample from a real window, and upload-time validation runs the model against it before the artifact can be bound.
