PyXis device identity registers give an automation or maintenance system a controlled way to identify the sensor it is reading. The current PyXis 222x Series datasheet lists device code, hardware revision, firmware revision, manufacturing date and serial number as identity information available for automated asset records.
That may look less important than vibration amplitude or alarm state, but identity data is what connects every measurement to the correct device, firmware profile and register-map revision. Without that link, a sensor replacement or firmware change can leave a PLC, SCADA or CMMS reading valid-looking values with the wrong engineering interpretation.
What the PyXis device identity registers provide
PyXis is a smart 3-axis vibration and temperature sensor that publishes processed condition data over two-wire, half-duplex RS-485 using a Modbus RTU slave model. In addition to motion, temperature, harmonic, severity and diagnostic data, its identity group supports:
- Device code: identifies the product or device family expected by the host.
- Hardware revision: records the physical design revision installed on the asset.
- Firmware revision: identifies the embedded software profile that controls supported data and behaviour.
- Manufacturing date: supports age, batch and lifecycle records.
- Serial number: provides the unique link between the physical sensor and the plant asset record.
The controlled datasheet classifies this information as read-only identity and inventory data. Use the released Modbus register map that matches the installed firmware for exact register addresses, encoding and scaling; do not infer those details from an article or from a register name alone.
Why identity matters before reading vibration values
A controller can receive a syntactically valid Modbus response even when its software model does not match the connected device. The risk is not necessarily a communication failure. It is a silent configuration-management failure: the host reads an address, receives data and assumes the field means what an older or different register map said it meant.
Preventing register-map mismatch
At startup, the host should read and compare the device identity against an approved compatibility record. If the device code, hardware revision or firmware revision is outside the validated combination, the application should flag the channel for engineering review before treating advanced diagnostic or prognostic fields as authoritative.
This is especially important because PyXis includes firmware-dependent functions. The current product documentation explicitly requires the applicable firmware and register-map revision to be verified before system integration.
Controlling sensor replacement
When a sensor is replaced, the Modbus address can remain the same while the serial number, manufacturing date or firmware revision changes. A system that records only the slave ID may treat the replacement as the original device and continue the same trend without an audit marker.
Recording the identity block makes the replacement visible. The maintenance record can then preserve the removal date, new serial number, firmware profile, mounting method, axis orientation and baseline status.
Protecting condition-history quality
Vibration trends depend on more than the sensor model. Mounting stiffness, location, axis orientation, machine speed, operating load, filters, thresholds and baseline quality all affect interpretation. Device identity is the anchor that lets those configuration details remain attached to the correct physical sensor.
A practical asset-traceability data model
A useful implementation separates the plant asset from the sensing device. The machine record identifies the motor, pump, fan, compressor, gearbox or conveyor. A linked sensor record identifies the PyXis unit currently installed on that machine.
Minimum sensor record
- Plant asset ID and monitoring-point ID
- PyXis device code
- Hardware and firmware revisions
- Manufacturing date and serial number
- Modbus slave ID and commissioned serial format
- Installation date, mounting method and axis orientation
- Register-map document revision
- Machine profile, filter and threshold revision
- Baseline date and approval status
Store the values in the system that owns lifecycle history—often a CMMS, asset database or historian—not only inside temporary PLC tags. The PLC or gateway can read identity at startup and periodically report exceptions, while the asset system retains the long-term audit trail.
Commissioning sequence for PyXis identity verification
- Confirm the physical installation. Match the sensor label, purchase record and monitoring-point drawing.
- Establish Modbus communications. Verify unique slave address, A/B polarity, trunk topology, termination, biasing and the intended serial format.
- Read the identity group. Capture device code, hardware revision, firmware revision, manufacturing date and serial number using the released register map.
- Compare against the approved compatibility list. Confirm that the host mapping and enabled features match the detected device and firmware.
- Write the asset record. Link the identity to the machine, mounting location, axis orientation and commissioning documentation.
- Baseline after identity acceptance. Capture representative healthy operation only after installation and configuration are verified.
- Detect later change. Re-read identity after maintenance, replacement, firmware service or unexplained data behaviour.
PLC, SCADA and CMMS integration pattern
In the PLC or gateway, expose a simple identity status alongside condition values. Useful states include “identity accepted,” “identity changed,” “firmware not approved” and “register map review required.” These are engineering workflow states, not PyXis fault codes, and should be implemented by the host application.
SCADA can display the installed serial number and firmware revision on the equipment faceplate. A historian can store identity-change events. A CMMS can use the serial number to associate calibration, replacement and investigation records with the correct unit.
The objective is not to poll static identity data at the same rate as vibration metrics. It is to verify identity at controlled events—startup, commissioning, reconnection, maintenance and detected replacement—then preserve the result with the asset history.
Common mistakes to avoid
- Using only the Modbus address as identity: slave IDs are network addresses and can be reassigned.
- Assuming all firmware exposes identical fields: diagnostic and prognostic availability can depend on the released profile.
- Continuing a trend without a replacement marker: a new serial number may require a new baseline or an engineering comparison.
- Copying register definitions from another revision: use the matching released register map and firmware note.
- Ignoring mechanical context: identity alone does not make measurements comparable if mounting location or axis orientation changed.
- Treating identity checks as a safety function: PyXis is not a safety device unless the complete safety function is separately assessed and validated.
Who should use PyXis device identity registers?
- Machine builders: to control sensor and software compatibility across serial production.
- System integrators: to validate register mapping during PLC, gateway and SCADA commissioning.
- Maintenance teams: to document replacements and protect condition-history continuity.
- Reliability engineers: to trace baselines and diagnostic changes to the installed hardware and firmware.
- Purchasing and quality teams: to connect received units, revisions and serial numbers to approved specifications.
Review the PyXis product page, compare options with the product selector, explore condition-monitoring solutions and obtain controlled documents from the technical resource library.
Planning a PyXis integration? Send the machine type, sensor count, controller platform, intended register-map revision and asset-record requirements for an engineering review.
Technical basis: PyXis 222x Series Smart 3-Axis Vibration Sensor datasheet TTN-DS-2026-002, Rev 08, issued 22 July 2026. Confirm the current hardware, firmware and Modbus register-map revision before design freeze or commissioning.
