Capturing torque data from a PLC over RS485 without losing readings
Getting a number out of a torque controller is easy. Getting every number, tied to the right unit, with a timestamp you can defend, is the actual job.
The reading is not the hard part
Most torque controllers will happily give you a value over RS232, RS485 or Ethernet. Some push a line of ASCII after every fastener, some expose a register you poll, some write to a folder. Any of those can be read in an afternoon.
What takes the other three weeks is everything around it: which unit the reading belongs to, what happens when the reading arrives twice, what happens when it does not arrive at all, and what you do with a reading whose timestamp disagrees with the station's.
Poll or be pushed
| Shape | Good | Bad |
|---|---|---|
| Push — controller sends a line after each fastener | You get every rundown, including the ones the operator repeated | You must buffer; a station busy elsewhere can miss a line |
| Poll — read a result register on a cycle | Simple, stateless, survives restarts | Two rundowns inside one poll interval and you lose one |
| File drop — controller writes a result file | Durable, survives a station reboot | Partial files; you must wait for an atomic rename, never read on create |
If you can choose, choose push with a durable local buffer. The failure mode you cannot recover from is a rundown that happened and was never recorded, because the operator has already moved the part.
Polling faster is not the fix
The instinct on a missed rundown is to shorten the poll interval. On a four-fastener operation with a fast gun, the interval you would need is smaller than the controller's own update rate, and you will start reading the same value twice instead. Sequence numbers, not speed, are what distinguish two identical rundowns.
Binding a reading to a unit
A torque value with no unit attached is telemetry, not traceability. Three bindings, in descending order of reliability:
- 01The station knows which unit is in the fixture because it was scanned at the start of the operation, and readings arriving during that operation belong to it. This is the only one that is reliable, and it is why the identity gate exists.
- 02The controller is told the unit identity and echoes it back with the reading. Good when supported, uncommon below the enterprise tier.
- 03Correlate by timestamp alone. Do not do this. Two stations, one clock drift and your record is confidently wrong.
RS485 specifics that bite
- Termination and biasing. An unterminated multidrop segment works fine on a bench and fails intermittently on a shop floor with a VFD running. Intermittent is worse than broken, because you will not notice the missing readings.
- Half duplex means you must not transmit while a response is inbound. A driver that fires a poll on a timer regardless of state will collide with itself under load.
- Address collisions on a multidrop segment produce plausible readings from the wrong instrument. Enumerate and record device addresses as configuration, and record which device produced each reading.
- Cable routing beside a servo drive will give you framing errors in bursts. Log framing errors as a counter you can see, or you will be debugging the software for a week.
Store the raw bytes
Whatever the controller sends, store it verbatim beside the parsed value. It costs a text column and it settles arguments.
point final_torque
value 12.1 Nm limits 10.0 - 14.0, nominal 12.0
verdict PASS
source DEVICE device TW-01
raw TQ,12.10,NM,OK\r\n
recorded_at 2026-08-18T06:23:41+05:30 (device clock)
received_at 2026-08-18T06:23:41+05:30 (server clock)Two years later, when a customer's engineer says the value looks rounded, the raw line is the answer. A parser that normalises before storing has thrown away the only evidence that mattered.
Two clocks, always
Record the device's timestamp and the server's, and keep both. When they disagree beyond a threshold, flag the row rather than dropping it — you never discard production data over a clock problem, you mark it so it can be seen later.
A panel PC with a dead RTC battery is common and quietly corrosive: it boots to an epoch date, every reading that shift is stamped wrong, and nobody notices until an audit. A flag on the row is what makes that visible.
What to do when the instrument is unplugged mid-shift
It will happen. The correct behaviour is not to crash the station and not to block forever. Reconnect with a backoff, give every read a deadline, and let the operator continue with manual entry against the same limits — a manual reading with a manual source flag is far better than a hole in the record.
That last point is worth stating plainly: a traceability system that stops the line when an instrument fails will be switched off within a month.
Written by Dinesh Kumar G, ElectronIx, Coimbatore. If something here is wrong or incomplete for your process, tell us — we would rather fix it.