English is currently available.
SCADA & HMI DISCUSSION
Our SCADA reads 20 energy meters on a single RS-485 line with Modbus RTU at 9600 baud, 40 registers from each meter. Values on the screens take 10 seconds or more to refresh, and when one meter is switched off the whole line becomes much slower still.
The driver is set to a 1 second scan rate, so I expected one-second updates. How do I work out the real update time, and what can be changed to bring it down?
The scan rate in the driver is a request, not a guarantee. On a serial multidrop line only one transaction can be on the wire at a time, so the real update time is the sum of all transactions.
Work one out: a read request is 8 bytes and the reply to a 40-register read is 5 + 2 × 40 = 85 bytes. With 11 bits per character at 9600 baud each byte takes about 1.15 ms, so the 93 bytes need about 107 ms on the wire. Add the meter's turnaround delay and the silent gaps between frames and one poll costs roughly 130 to 160 ms. Twenty meters therefore need about 3 seconds per cycle at best. A 1 second scan cannot be met at this baud rate.
Ten seconds instead of three suggests the driver is sending more than one request per meter. That happens when the tags are not in one contiguous block: a gap in the register addresses, or a mix of holding and input registers, makes the driver split the read into several frames, each with its own turnaround time. Look at the driver diagnostics or a serial sniffer and count the requests per meter.
Arrange the tags so each meter is read with one or two block reads, even if that means reading a few registers you do not need. One request can carry up to 125 registers, and 10 unused registers cost about 23 ms, far less than a second transaction.
The offline meter hurts because of the timeout. If the timeout is 1 second with 3 retries, every cycle waits up to 4 seconds for a device that will never answer before moving on.
Set the timeout from the slowest real response rather than a round number: if the longest normal reply completes within 200 ms, a 300 to 500 ms timeout is plenty. Reduce retries to one, and use the driver's option to demote a failed device, so that it is tried only every 30 or 60 seconds until it comes back.
Raising the baud rate is the biggest single gain if every meter supports it. At 19200 baud the same 93 bytes take about 53 ms, and at 38400 about 27 ms, although the meter's own turnaround time does not shrink, so the improvement is less than proportional. Check the cable length and termination before going faster.
The other option is to split the line. Two RS-485 ports with ten meters each are polled in parallel and halve the cycle. A serial-to-Ethernet gateway per group does the same job if the SCADA server has no spare serial ports.
Not every value needs the same rate. Put voltage, current and power in a fast group and energy counters, which change slowly, in a group polled once a minute; a smaller block means a shorter reply.
Then verify the result. Most drivers expose statistics tags such as the last scan time and the error count per device. Trend those, and the effect of each change is visible immediately instead of being judged by eye from the screen.
Back to SCADA & HMI community
