Decide the path before you buy anything
TPMS PLC integration is not one job. It is two, and the choice depends on one question: what does the PLC already have?
If the controller has a CAN interface, tire data can arrive as CAN frames or J1939 parameters, and the receiver is simply another node. If the PLC has no CAN port and the machine is mostly digital and analogue I/O, serial is the practical route: Modbus RTU over RS485, which almost every PLC or HMI in industrial machinery supports without new hardware.
Both paths use the same sensor and the same radio link. What changes is the last metre of wiring, the polling pattern in the PLC program, and the document you need from the supplier. The CAN side is described on the CAN bus TPMS integration page; this article is about the serial route and about making either one behave on a real machine.
What the receiver offers on the serial side
Our receivers support RS485 and RS232 output with Modbus RTU, alongside CAN, J1939, PROFINET and UART. Practical details that decide whether an integration is a half-day job or a two-week one:
- The receiver is powered from the machine at DC 10-30 V, so it does not need a separate supply on a 24 V vehicle.
- Serial parameters, including address and speed, are configurable.
- Tire data is exposed as a register block rather than as a stream, which is what a PLC wants: poll, read, use.
- The same device can be a repeater or a receiver depending on configuration, so a long machine does not need a different part number for every role.
Ask for the register map before you write a single line of ladder logic. If the supplier has no register map, stop and get one.
What the register map should contain
A register map is the serial equivalent of a DBC file. It should tell you, per wheel position, where pressure and temperature live, how they are scaled, and how the receiver reports its own health.
The minimum that makes a usable map:
- Pressure per wheel, scaled to kPa, with the raw range stated
- Temperature per wheel, scaled to degrees Celsius
- Status per wheel as a value table: normal, low pressure, rapid leak, sensor missing, battery low
- An online or validity bit per wheel, so your program can distinguish "0 kPa because the tire is flat" from "0 because the sensor stopped talking"
- A device heartbeat or frame counter, so a frozen connection looks different from a quiet one
- Supported function codes and the largest contiguous block the receiver will return in one read
Word order matters as much as bit order does on CAN. Modbus registers are big-endian by definition, but 32-bit values span two registers, and vendors differ on which comes first. Take the supplier's example values and verify one by hand before you trust the scaling.
Watch the register addressing convention too. Some tools number the first holding register as 40001, others as 0. Being off by one is the most common "the data is shifted" bug in Modbus work.
Wiring RS485 on an industrial machine
RS485 is forgiving about distance and unforgiving about details. On mining, port and construction equipment, the electrical environment is hostile, so a few rules are worth following exactly.
- Daisy chain, never star. Stub lengths of a few tens of centimetres are tolerable; a star with metre-long branches is not.
- 120 ohm termination at both physical ends of the bus, and only at the ends.
- Twisted pair for A and B, and a third conductor for signal common. Ground potential differences between a cab and a chassis rear are real.
- Route away from motor and drive cables. Parallel runs next to a variable-frequency drive are the fastest way to corrupt frames.
- Shield grounded at one end. Grounding both ends makes the shield a current path.
- Lower the speed as the cable gets longer. A long chassis at high speed is where intermittent timeouts come from.
The receiver and repeaters are rated IP68, so mounting them where the machine actually is, rather than where the cable is convenient, is a valid choice.
Polling in the PLC program
The TPMS data cycle is 500 ms by default, and that sets your polling rhythm. Reading a register block every 500 ms is right; reading it every 50 ms adds bus traffic without adding information, because the receiver has nothing new to send in between.
Three habits keep the program predictable:
1. Read one contiguous block per cycle rather than many small reads. Fewer transactions, less chance of a partial failure.
2. Keep a timestamp per read. If the read fails repeatedly, or the heartbeat stops incrementing, raise a communication fault distinct from a tire fault. Operators need to know whether the tire is bad or the wiring is.
3. Apply timeouts and retries on the master side. Modbus RTU has no session, so a device that goes quiet is invisible unless you look for it.
Alarm evaluation belongs in the PLC, not in the driver. The receiver reports conditions; the machine decides what to do about them.
Scaling and alarms that behave
Pressure accuracy is ±7 kPa and temperature accuracy is ±3 degrees Celsius. Those numbers are good, but they are not zero, so build the thresholds with margin. A low-pressure warning set at exactly the tyre's target pressure will chatter.
Four rules that hold up in service:
- Use the receiver's rapid-leak flag rather than computing a rate of change from polled data in ladder logic. The firmware sees every frame; your PLC sees a sampled subset.
- Add hysteresis to any threshold you implement yourself, so a wheel sitting on the limit does not toggle an alarm every cycle.
- Separate the alarms. Low pressure, rapid leak, sensor missing and sensor battery low need different responses and different operator messages.
- Log which wheel position triggered it. A fault without a position sends a technician to the wrong axle.
Where integrations usually go wrong
The failures are boringly consistent: word order is swapped, the first register is off by one, termination resistors are missing, or the online bit is ignored so every missing sensor reads as a flat tire at zero pressure. Occasionally the project reads more registers than allowed in one transaction and gets a truncated reply, which looks like corrupt data.
All four are visible in a twenty-minute bench test. Power the receiver, connect a sensor simulator or a few real sensors, dump the register block, and compare against the documentation before the hardware goes near the machine.
What we hand over
GZVIA builds the sensor, receiver, repeater, display and cloud platform in house, so the register map and the firmware come from the same team. Together with the Modbus documentation we supply the alarm semantics, the connector pinout and a configuration tool for wheel count, sensor IDs and thresholds. Our receivers accept up to 256 wheel positions individually, and we have delivered a 160-wheel beam carrier as two receivers, twelve repeaters and 160 sensors, with the largest single machine we have instrumented carrying 224 wheels across 28 axles.
The TR100 receiver page lists the protocol and electrical detail. Send us your PLC model, the port you plan to use and the wheel count, and we will reply with the wiring, the register map and a configuration suggestion. Ask about your PLC.