PyXis fault-state integration should give a PLC or SCADA operator a clear maintenance signal without hiding the measurements behind it. PyXis publishes per-axis severity and fault-analysis state alongside vibration, temperature, rotational and spectral data. The integration task is to preserve that context, decode each state against the installed firmware, and prevent an old or stale value from becoming a false machine alarm.
PyXis fault-state integration starts with the released data definition
PyXis exposes condition information through a Modbus RTU slave data model. Its read-only monitoring groups include per-axis severity and fault-analysis state, while the same interface provides X, Y and Z motion metrics, harmonic arrays, rotational context and temperature. These values are intended to work together.
A status value should not be assigned a universal meaning from its register name alone. The controlled datasheet explicitly requires the firmware-specific register map for data type, scaling, signedness, decimal position and enumerations. V2 condition definitions and some diagnostic or prognostic outputs are firmware dependent.
Before implementing alarms, read and retain the PyXis device code, hardware version, firmware version, manufacturing date and serial number. The PyXis device identity register guide explains how those fields support version control and asset traceability.
Carry the state, evidence and data quality together
A useful PLC or SCADA tag set contains more than a single alarm bit. For each monitored axis, retain the decoded severity or fault state, its raw register value, the underlying condition measurements and enough quality information to decide whether the data is current.
The supporting PyXis measurements can include:
- X, Y and Z acceleration RMS, peak, peak-to-peak and crest factor;
- velocity and displacement results for each axis;
- up to twenty harmonic frequencies and corresponding acceleration amplitudes per axis;
- internal sensor temperature and a profile-dependent motor-temperature value;
- RPM, tachometer quality, speed state and 1X order information;
- firmware-profile-dependent diagnostic and prognostic indicators.
The host does not need to display every value on the primary operator screen. It should, however, preserve the evidence required to investigate a state transition. A concise alarm card can show the asset, axis, decoded state, timestamp and the most relevant measurements, with detailed trends available for maintenance review.
Reject stale condition states before evaluating machine condition
A valid numeric response is not automatically fresh condition information. Communications loss, an interrupted polling cycle or retained PLC memory can leave the last value visible after the sensor has stopped updating.
Evaluate communications health before evaluating the condition state. The integration should distinguish at least three cases: a current PyXis state, unavailable or stale data, and a configuration or decoding mismatch. Do not silently convert unavailable data into “healthy”.
PyXis supports two-wire half-duplex RS-485, slave addresses 1–247, automatic or fixed baud selection, multiple serial formats, a configurable response delay and communications-loss supervision through the common management area. Poll timing and stale-data limits must be selected for the actual firmware profile and enabled analysis functions because update timing is profile dependent.
Decode states into named PLC and SCADA values
Use a symbolic data type or lookup table rather than scattering raw numbers through PLC logic, HMI graphics and historian calculations. Keep the raw value available for diagnostics, but map it once through a version-controlled definition that cites the applicable register-map revision.
A practical integration record should include:
- the register-map and firmware versions used for decoding;
- the data type, word order, scaling and enumeration for each mapped value;
- the polling interval and stale-data timeout;
- the machine profile, filters and warning or alarm settings;
- the baseline date, mounting method and recorded axis orientation;
- the operator message and maintenance action assigned to each supported state.
If a later firmware or register-map release changes the definition, update the decoder under change control and regression-test the HMI, historian, alarm routing and maintenance interface together.
Link the status to measurements, not to an automatic diagnosis
Per-axis severity and fault states are useful for routing attention, but they do not remove the need to examine the machine context. Mounting stiffness, sensor location, axis orientation, operating speed, load, filters, thresholds and baseline quality all affect interpretation.
Suppose a pump changes state on the radial Y axis. The alarm record should capture the Y-axis velocity or acceleration trend, relevant harmonic information, temperature and rotational context at the same time. Maintenance can then check whether the change coincides with speed, load or temperature rather than assuming a particular defect from the state alone.
The same discipline applies when no state change is reported. A stable state should not override clearly abnormal underlying measurements, a poor tachometer-quality indication or data-quality failure. PyXis makes compact edge information available; the plant still defines how that evidence becomes an inspection, work order or controlled process response.
Commission the alarm path from sensor to work order
Commissioning should prove the complete route, not merely confirm that a Modbus register can be read. Start with the installed device identity and matching documentation, then verify stable polling and axis plausibility. Establish a representative healthy baseline across the normal speed and load range before relying on condition classifications.
PyXis provides writable warning and alarm threshold groups for per-axis velocity, acceleration and displacement, plus temperature limits. The controlled datasheet notes that V2 definitions are firmware dependent. During an acceptance test, use controlled threshold changes only where the released firmware procedure permits them, confirm the expected PLC/SCADA and maintenance response, then restore and read back the commissioned values.
Record the final thresholds, filters, machine profile, baseline status and notification route. The vibration baselining and alarm-threshold guide covers the measurement-side work, while the PyXis persistent configuration guide covers controlled saving and restart verification.
Keep safety and maintenance decisions separate
PyXis condition states support monitoring and maintenance workflows. They are not, by themselves, a certified safety function. Any protective trip or safety-related interlock requires a separately designed, assessed and validated safety system.
Diagnostic and prognostic availability also depends on the ordered firmware profile. Confirm the required feature set, register availability, update behaviour and limitations before procurement or design freeze. The PyXis bandwidth guide provides additional context for the measurements behind the condition state.
Define the alarm record before writing the PLC code
PyXis fault-state integration is most maintainable when the asset record, data-quality rules and maintenance response are defined first. Review the Tachyonic product range, use the product selector, or browse the engineering resources.
For an engineering review, send the machine type, firmware and register-map revision, controller platform, required condition tags, polling interval and alarm-routing workflow. Contact Tachyonic Intelligence.
Featured image: “Industrial Worker Using Tablet in Factory” by Sergey Sergeev, sourced from Pexels under the Pexels licence. The photograph is illustrative and does not depict PyXis hardware or a Tachyonic deployment.
