Start with the honest sentence
Our receiver does not have a PROFINET port. A receiver is built with one interface, chosen at the
factory — CAN, RS232, RS485 or Modbus RTU — and none of those is PROFINET.
If your controller is a Siemens PLC on a PROFINET network, the route is:
`sensors → receiver (RS232) → RS232-to-PROFINET gateway → your PLC`
That is not a workaround to be embarrassed about. It is a normal architecture for a sensor that has a
serial output, and it keeps the tyre hardware standard instead of creating a special variant. What
matters is that both sides know it is a gateway, so nobody plans for a native PROFINET node.
Why this path is usually the right one
Three reasons, in order of importance:
1. The alternative is a new interface variant of the receiver. That is a development project for a
small volume. The gateway is a part you can buy today.
2. The gateway isolates the two worlds. If the PROFINET side is re-configured, replaced or moved to
another machine, the tyre hardware is untouched — and vice versa.
3. You keep the tyre data on the machine network. The PLC reads it as I/O, the machine's own logic
decides what to do (derate, alarm, log), and the vehicle's functions stay in your controller.
What the gateway has to do (check these before you buy)
Most RS232-to-PROFINET gateways are similar; these are the differences that matter.
| Item | Why it matters |
|---|---|
| Serial side: TTL or RS232 | The receiver's serial level is 3.3 V TTL by default, RS232 on request — order the level on the receiver, not at the gateway. |
| Baud rate support | Our receiver's baud rate is confirmed per project, not published. Give the gateway's supported range early so both ends are ordered coherently. |
| Frame handling | The gateway must pass the receiver's frame through (or map it). Decide whether the PLC parses the frame itself or the gateway presents registers. |
| Data direction | Some gateways are strictly I/O (PLC reads); some support writes. The tyre data is read-only for the PLC, so read is enough. |
| Cycle time | The receiver publishes on a 500 ms cycle. A gateway refreshing much faster than that buys you nothing, and one refreshing at 2 s loses data. Match it to 500 ms. |
| Diagnostics | You want a way to see "gateway up but no frames from the receiver" as a distinct state. Otherwise a serial problem looks like a network problem. |
Two integration styles, pick one
Style A — the PLC reads a block of registers from the gateway. The gateway presents the serial data
as I/O. The PLC treats it like any other PROFINET device. Simplest, and what most machine builders
want.
Style B — the gateway just passes the serial frame, the PLC parses it. More control, more PLC code.
Only worth it if the PLC already has a parser for a similar device, or if the gateway's register layout
does not match how you want wheel positions arranged.
For a first project, A. You can always move to B later without changing the tyre hardware.
What to decide before you order anything
1. Receiver level — TTL or RS232 (order it on the receiver, remember).
2. Baud rate — ask the gateway's supported range, then agree the receiver's configuration.
3. Who parses the frame — gateway registers, or the PLC.
4. Wheel position mapping — how a register index maps to "left front, inner rear, third axle". Do
this in your PLC's naming, not in ours.
5. Alarm logic — threshold, how many consecutive bad reads before an alarm, and what to do when a
position simply stops reporting. That last state is the one people forget.
The three things that go wrong
| Symptom | Usual cause | Fix |
|---|---|---|
| Gateway online, PLC sees zeros | Baud rate or level mismatch between receiver and gateway | Confirm both ends on the same configuration sheet before ordering |
| Values plausible but wrong | Frame layout assumed instead of read from the document | Use the frame description supplied with the unit |
| A position goes missing and nobody notices | No `last seen` logic in the PLC | Timestamp each position; alarm on staleness, not only on low pressure |
Where this fits commercially
This is a small but high-value configuration: the customer is usually a **machine builder or a plant
integrator** who already has a PROFINET network and wants the tyre data on it. The gateway is a
separate item in the quote, and it belongs in the bill of materials next to the receiver — not
hidden inside a sensor price.
If you are planning this, tell us the PLC family and whether the network is new or existing. We will
confirm the receiver configuration in writing, and we will name the gateway as a separate line so the
bill of materials is honest from the start.
See the receiver configurations on the product pages, the interface options on
the TR100 page, or go straight to the
PLC integration page for the non-PROFINET case. To confirm a configuration for
your PLC, send us the details.