Sort data by what it is for before you tune anything.
Handling data — start here
Sort data by what it is for before you tune anything. Telemetry and control have different timing needs — classify them, respect the controller's scan budget, and give each its own path so the fast path never inherits the slow one's load.
Sort by purpose first
Telemetry is continuous and latency-tolerant; control is small and time-critical. Don't poll it all at the fast rate.
Sort data by what it is for
Source
PLC
signals
reads
Node-RED (edge device)
Node-RED
edge device
classify
Three populations
Telemetry
continuous, latency-tolerant
Control
small, time-critical
Config
written rarely
Before tuning anything, sort the data by what it is for. Telemetry is continuous and latency-tolerant. Control data is small and time-critical. Config is written rarely.
Use it when
The common mistake is treating every point as one population and polling all of it at the fastest rate. That is what creates load a controller cannot sustain.
How to handle it
Ask whether a delay changes a control decision or only a timestamp, whether it is read or write, and what cadence the data actually needs versus how fast it is polled today.
Good for
Deciding which few points genuinely need the fast path, usually far fewer than ride it.
Mind the scan budget
Comms is only one slice of a PLC's per-scan budget; fast-polling everything starves the data that needs the rate.
Every poll spends the controller scan budget
PLC · one scan budget
control logic
I/O
comms
polls
Node-RED (edge device)
Node-RED
poll only what needs the rate
A PLC has a finite budget per scan, and communications is only one slice of it. Every poll, read, and connection costs the controller.
Use it when
Polling a large set of points fast spends the budget on data that did not need the rate, leaving less headroom for the data that does.
How to handle it
Know which direction a connection is established and that each protocol is its own driver. Common protocols (MQTT, OPC UA, WebSocket, Modbus TCP) are not deterministic; data handling, not the runtime, decides the timing you hit.
Watch out
Test one signal end to end, isolated from the rest, so you measure the transport itself and not your application logic.
Split read from event-driven
Buffer telemetry and batch it to a time-series DB; keep the control path lean and on its own.
Telemetry to history, control stays fast
Source
PLC
buffered
pull at its real cadence
Node-RED (edge device)
buffer + batch
telemetry
live, minimal set
control
two paths
Targets
Broker (MQTT)
live, minimal set
SQL database
history, batched (time-series)
Separate read traffic from event-driven traffic, then handle each on its own path. This split is the foundational step; everything else follows from it.
Use it when
Telemetry and control have different timing needs. Sharing one path and one protocol makes the fast path inherit the load of the slow one.
How to handle it
Buffer telemetry in the PLC and pull it at its real cadence, timestamped at acquisition. Batch it into a time-series database. Keep the control path to the minimum tag set on a dedicated, faster route.
Good for
Batched inserts into a time-series DB land at a fraction of the overhead of individual writes.
FlowFuse Application Guide