Mtconnect

Tool-change auto-detection, and the case for asking the controller instead of guessing from the signal

The last unbuilt feature from the issue 06 vendor comparison. A signature detector on the spindle stream can learn what a tool change looks like, but the controller already knows. This issue builds the controller-fed path with MTConnect and keeps the matched-filter detector as the fallback for machines that will not talk.

Issue 06 priced a vendor condition-monitoring quote line by line against the open stack and left four features to build. Issues 06 and 07 built three of them: the single-asset Isolation Forest, the cross-asset common-mode gate, and the threshold alerting. The fourth was tool-change auto-detection, the feature that stops the model from paging on the large vibration and current transient a planned tool change produces, which issue 06 logged as a false positive that turned out to be a real but miscategorized event. Issue 08 builds it. The signal-only approach treats the tool-change transient as a known signature and matches it with a matched filter, the optimal detector for a known template in noise. It works, and it has the failure mode every blind detector has: it fires on anything that resembles the template and stays silent on the tool change that does not. The controller-fed approach skips the inference entirely. The CNC already knows it is changing a tool, and MTConnect exposes that as a structured data item the edge can read and publish alongside the sensor stream. The model gates its own scoring on the controller's ground truth. Both are built. The controller-fed path is the recommendation, the matched filter is the fallback for machines with no open data interface, and the honest failure mode of gating any planned event is named: a real fault that begins inside the gate window is suppressed until the window closes.