> For the complete documentation index, see [llms.txt](https://docs.twtg.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.twtg.io/docs/how-to/vibration-sensor-vb/communication-protocol-v4/how-to-use-the-automatic-fault-detection.md).

# How to use the automatic fault detection

The NEON Vibration Sensor, using communication protocol v4 and onwards, includes as one of its features the Machine Fault Indicator, which allows automatic detection of common faults and bearing faults. The `machine_fault_indicator` schedule can be used to request the analysis of a specific fault type. Currently, we can distinguish between two fault types, both of which have their own categories.

Please note that it is an indication of a fault triggered by the detection of signs that are often associated with a certain category of machine faults. The user has the option to request a spectrum on fault if they require more proof. It is advised to look at the relevant spectrum when such a notification is received.

### Common Faults Detection

The Machine Fault Indicator can detect common faults like unbalance, misalignment, or mechanical looseness by analyzing the velocity FFT spectrum measured by the NEON Vibration Sensor.&#x20;

Scheduling a machine fault indicator with *fault\_type*=common\_fault will lead to analysis of 3 fault categories (nx, 2x, 1x). The category names are based on what harmonics of the rotating speed (x) are dominant in the spectrum.

* Nx are faults such as looseness, where many harmonics of the rotating speed are present.
* 2x are faults such as misalignment, where 2 harmonics of the rotating speed are present.
* 1x are faults such as imbalance and critical speed, based on the harmonic of the rotating speed.
* None when there was no indication of any of the faults listed above.

The message will always contain the set of 10 harmonics of the rotating speed that it found.

The NEON Vibration Sensor can be configured to detect common faults automatically by sending the following structure to the device.&#x20;

```json
{
  "configuration_update_request": {
    "version": 0,
    "tag": "0x6A426A27", //Configuration Identifier
    "payload": {
      "type": "schedule",
      "version": 0,
      "command": "set",
      "timing": "360", //How often to measure the machine for common faults
      "triggered_on_button_press": false,
      "send": true,
      "settings": {
        "type": "vb_machine_fault_indicator",
        "version": 0,
        "axis": "all", //Which axes to monitor
        "range": "gscale_16",
        "sample_speed_divider": 1,
        "f_min": 5,
        "f_max": 6300,
        "fault_type": "common_fault", //Selection for the Machine Fault Indicator
        "send_condition": {
          "value_type": "always",
          "threshold": 0
        }
      }
    }
  }
}
```

The general recommendation is to set up the Machine Fault Indicator every 6, 12, or 24 hours for all axes with the vibration parameters (range, sample speed divider, fmin, fmax) required for the machine being monitored.&#x20;

For more details about how to configure a device, please see [Configure a Device](/docs/configuration/configure-a-device.md).

### Bearing Faults Detection

The Machine Fault Indicator can detect bearing faults by analyzing the envelope spectrum measured by the NEON Vibration Sensor.&#x20;

Scheduling a machine fault indicator with *fault\_type*=bearing\_fault will lead to the analysis of bearing faults. If no indication of a fault was found, it will return "None". Bearing faults are analyzed in the envelope spectrum, which is calculated using a bandpass filter and the Hilbert transform. The message will always contain the set of 10 harmonics with the highest overall amplitude (which cannot be those of the rotating speed.

The NEON Vibration Sensor can be configured to detect bearing faults automatically by sending the following structure to the device.&#x20;

```json
{
  "configuration_update_request": {
    "version": 0,
    "tag": "0x6A426B3F", //Configuration Identifier
    "payload": {
      "type": "schedule",
      "version": 0,
      "command": "set",
      "timing": "360", //How often to measure the machine for bearing faults
      "triggered_on_button_press": false,
      "send": true,
      "settings": {
        "type": "vb_machine_fault_indicator",
        "version": 0,
        "axis": "all",
        "range": "gscale_16",
        "sample_speed_divider": 1,
        "f_min": 5,
        "f_max": 6300,
        "fault_type": "bearing_fault", //Selection for the Machine Fault Indicator
        "send_condition": {
          "value_type": "always",
          "threshold": 0
        }
      }
    }
  }
}
```

The general recommendation is to set up the Machine Fault Indicator every 6, 12, or 24 hours for all axes with the vibration parameters (range, sample speed divider, fmin, fmax) required for the machine being monitored.&#x20;

For more details about how to configure a device, please see [Configure a Device](/docs/configuration/configure-a-device.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.twtg.io/docs/how-to/vibration-sensor-vb/communication-protocol-v4/how-to-use-the-automatic-fault-detection.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
