Anomaly detection is a useful tool to determine if your machine is experiencing unusual behavior. The algorithm looks at each part being created and generates a profile of what's going on in the machine while the part is being machined. It will send an alert whenever a new part being created is very different from all the other parts.
Anomaly detection can detect when a new part deviates from the norm. The “norm” is established by looking at the activity of your machine for the last 20 parts. It looks like speeds, feeds, and loads, and sets a baseline based on these metrics.
Anomaly detection does not predict 100% of tool failures or otherwise consequential issues with your machine. This is because tool failures sometimes do not have preceding indicators. For example, a chip re-cut, which is when a chip accidentally gets thrown back into the machine, will have minimal, if any signal beforehand to indicate that it will happen.
Similarly, not every anomaly will indicate that something bad is about to happen. This is because machines can do strange things that do not necessarily cause anything of interest. This may be because the anomaly occurs due to something like an e-stop being hit or a door being opened in the middle of the part cycle, or the abnormal behavior is within the stress tolerance of the machine, as in the case of a load spike that doesn't bring down the machine.
- Anomaly detection will work if your machine fulfills the following conditions:
- The machine has 3 or more numeric variables. You can check this on your machine diagnostics page, but generally all non-I/O integrations will fulfill this condition.
- The machine has part cycles that are greater than 30 seconds long and less than 1 hour long.
- The machine must count parts consistently. For example, if the part counter increments by 2, then 3, then 2, the machine cannot qualify for anomaly detection. An occasional inconsistent count is acceptable and can be worked around, but generally, 80%+ of part count increments must be the same for the algorithm to work.
Activating anomaly detection
Anomaly detection can be activated and deactivated on the workflows page. Here is our step by step walkthrough.
Some examples of interest are below.
- A user received an anomaly text at 2:25 AM. There was a catastrophic tool failure shortly after at 2:28 AM.
- A user received a text directly before a "coolant out" alarm. They were alerted to change the coolant instead of having them walk around and see the machine wasn't running.
- A user received a text at the same time as a severe alarm which took the machine down. The user gets hundreds of alarms every day but this one was severe enough to merit an anomaly text, alerting the customer of a potentially more serious issue.
- A manager received an anomaly text when the operator was trying to run the machine with the door open. The manager was made aware of potential safety issues on the factory floor.
More examples and technical details are in the link below. This page is updated periodically as more data is gathered.
For full technical details, here is a link to the journal publication: https://www.phmpapers.org/index.php/phmconf/article/view/806