> 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. 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. ```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. 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. 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. ```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. 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.twtg.io/docs/how-to/vibration-sensor-vb/communication-protocol-v4/how-to-use-the-automatic-fault-detection.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.