PyXis Modbus RTU commissioning is a combined wiring and protocol task. A sound RS-485 trunk can still appear dead when two sensors share a slave address or the master uses the wrong parity. Equally, correct protocol settings will not compensate for reversed A/B conductors, duplicate bias networks or termination placed on a spur.
PyXis operates as a Modbus RTU slave on a two-wire, half-duplex RS-485 link. The controlled PyXis 222x Series datasheet defines the commissioning choices available to the integrator: slave addresses 1–247, automatic baud detection or fixed rates of 9600, 19200, 38400 and 115200 bit/s, serial formats 8E1, 8O1, 8N1 and 8N2, a configurable response delay from 0 to 50 ms, and communications-watchdog supervision. The sequence below turns those settings into a repeatable handover process.
PyXis Modbus RTU commissioning starts at the trunk
Treat the network as an RS-485 transmission line before opening the PLC program. Build one daisy-chain trunk, keep device stubs short and place termination only at the two physical ends of the trunk. Use one documented bias arrangement for the segment. Star wiring, long branches and several competing bias networks make fault finding much harder because reflections and idle-line voltage can vary with cable length, node count and which devices are powered.
Check the following with the segment de-energised where appropriate:
- A and B conductor continuity from the master to the last node;
- consistent polarity at every PyXis connection;
- termination at the two physical ends, not at every sensor;
- one intentional bias network rather than several undocumented ones;
- shield and reference-conductor treatment against the site wiring plan;
- supply voltage at the sensor end of the cable, including expected voltage drop.
If the installation includes multiple device types, keep the same physical-layer discipline across the whole segment. The RS-485 Modbus network engineering guide covers the general bus rules; the settings here are specific to commissioning the PyXis Smart 3-Axis Vibration Sensor.
Assign slave addresses before enabling the full poll list
Every PyXis on one Modbus segment needs a unique address between 1 and 247. Duplicate addresses are particularly deceptive: the master may record intermittent CRC errors, malformed frames or inconsistent timeouts rather than a simple “duplicate address” message.
Commission one new node at a time when practical. Record the physical asset, cable position, intended slave address, sensor serial number and controller tag in the same worksheet. Read back the device identity information before adding the node to the production poll list. The PyXis management area provides device code, hardware and firmware revision, manufacture date and serial number, which can be tied to the plant asset record.
For example, a four-sensor segment might use addresses 11 through 14. The numbers are not special; the important point is that each address is unique, documented and associated with the correct machine location. The integrator should confirm the identity of address 11 before connecting or enabling address 12, rather than discovering a duplicated setting after all four sensors are online.
Choose one baud rate and serial format for the segment
PyXis supports automatic baud detection as well as fixed rates of 9600, 19200, 38400 and 115200 bit/s. Supported serial formats are 8E1, 8O1, 8N1 and 8N2. All devices and the master must use a compatible combination.
Automatic detection can simplify initial access, but a fixed, documented setting is often easier to reproduce during service work. The commissioning record should state the selected baud rate and serial format, not merely “Modbus connected”. A replacement gateway or PLC port can then be configured from the record without trial-and-error scanning.
Use a conservative starting point when cable length, branch geometry or electrical noise is uncertain. Raise the data rate only after the physical layer and error counters are stable. Baud rate should be selected for the complete segment rather than for one device in isolation.
Serial-format mismatches often look like wiring faults
A master configured for 8N1 will not communicate reliably with a sensor configured for 8E1, even when the address and baud rate match. The symptom can be a continuous timeout, framing errors or discarded replies. Check the complete format—data bits, parity and stop bits—before disturbing wiring that has already passed continuity and polarity checks.
Use response delay to match the master, not to mask a weak bus
PyXis provides a configurable response delay from 0 to 50 ms. This allows an integrator to accommodate a master, converter or gateway that needs a defined turnaround interval between its request and the slave reply.
Response delay is not a substitute for correct termination, biasing or poll timing. Adding delay may reduce collisions caused by a slow direction-controlled converter, but it will not repair a reflected waveform or a duplicated slave address. Set the smallest delay that the verified master path requires, then include that value in the commissioning record.
When several nodes share a segment, calculate the scan around the actual request and response cycle. The controller must allow for frame transmission, configured response delay, reply length, inter-frame spacing and any retry policy. Avoid overlapping transactions. Modbus RTU uses one request-response exchange at a time on the half-duplex bus.
Configure the communications watchdog deliberately
The PyXis common management area includes configurable communications-watchdog supervision. Use it as part of the system’s data-quality strategy: the controller should be able to distinguish a current measurement from a value retained after communications were lost.
The watchdog configuration and its reported state must be decoded against the register map and release information that match the installed firmware. Do not infer bit meanings, timeout units or enumerations from a register name. During acceptance testing, interrupt polling in a controlled condition, observe the documented indication, restore communications and confirm the recovery path in the PLC, SCADA or historian.
The controller should also timestamp the last valid update and expose a separate communications-quality tag. That prevents an old vibration or temperature value from appearing healthy simply because it remains numerically within an alarm band.
Save, restart and prove the configuration
PyXis provides controlled commands for persistent save, reboot and factory reset. Treat them as commissioning operations rather than routine cyclic writes. After setting the address, baud mode, serial format, response delay and watchdog, use the firmware-matched procedure to save the intended configuration. Restart the device under controlled conditions and read the settings back.
This step catches an otherwise common handover failure: a network works during setup, but one or more values were never committed and revert after the next power interruption. The production poll should not begin automatically until the controller has confirmed the expected identity and communication settings following restart.
A practical fault-finding order
When a PyXis node does not respond, work from the physical layer toward the application rather than changing several parameters at once:
- Confirm supply at the device and inspect connector seating.
- Check A/B polarity, trunk continuity, end termination, bias arrangement and shield/reference practice.
- Isolate duplicate slave addresses by commissioning one node at a time.
- Match the master and sensor baud rate and full serial format.
- Review response delay, master turnaround time, timeout and retry settings.
- Observe CRC, framing and timeout counters where the master or gateway provides them.
- Read device identity and confirm the register map matches the installed firmware.
- Save the configuration, restart and repeat the read-back test.
Changing address, parity, termination and timeout simultaneously may make the network respond, but it leaves no evidence of the original fault. A single-change test record is more useful for both site acceptance and later maintenance.
Commissioning evidence worth retaining
A concise handover record should include the segment drawing, master interface, cable route and approximate length, termination and bias locations, every slave address, baud rate, serial format, response delay, watchdog setting, firmware/register-map revision and the identity values read from each sensor. Add a short test result for normal polling, a controlled communications interruption and recovery after restart.
These records make later expansion safer. They also help the controls engineer decide whether a new sensor can join the existing segment or whether the application needs another RS-485 port or gateway. The Tachyonic product selector, industrial monitoring solutions and technical resources provide additional planning context.
Review the segment before site work
If you are preparing a PyXis network, send Tachyonic Intelligence the controller or gateway model, node count, cable length and topology, proposed slave addresses, baud and serial format, termination and bias arrangement, and intended poll timing. We can review the commissioning plan before the settings are applied on site.
Request a PyXis Modbus RTU commissioning review.
Technical basis: PyXis 222x Series datasheet TTN-DS-2026-002, Rev 08, issued 22 July 2026. Photo by Warren Yip on Pexels, used under the Pexels licence.
