Values update very slowly after adding 400 tags: how should I design frames?

[ProcessPilot]

At the beginning our project had about 50 tags on one PLC and values updated almost instantly. We've now added around 400 more tags on the same PLC (motor statuses, analog values, counters). Since then, some values take several seconds to update and occasionally a whole group shows old values for a while.
When I added the tags, I created a new frame for almost every group of 5–10 tags, so now there are about 60 frames on that channel. Request Time is 100 ms on the channel. Is this the wrong approach? What is the recommended way to set up frames?

[Technical Support]

Your diagnosis is close: the number of frames is very likely the problem. Each frame is a separate request to the PLC, so 60 frames means 60 request/response cycles before the first frame is read again. With a 100 ms Request Time, the PLC and network can't keep up, and updates fall behind.
How to design frames
A frame reads a block of consecutive registers: Start Address plus Quantity, with a given Function Type and Data Type. The goal is a few large frames rather than many small ones.

1. Group by address, not by meaning. Ask the PLC programmer to place the SCADA-related data in continuous address blocks: for example statuses in one block, analog values in another, counters in a third.
2. Use larger Quantity values. One frame covering a block of 100 registers is far more efficient than ten frames of 10. Stay within the limits of your PLC for a single request.
3. Separate by data type and function. Keep coils/discrete inputs and holding/input registers in separate frames, and don't mix incompatible data types in one frame.
4. Separate fast and slow data. Values that rarely change (setpoints, run hours) don't need the same Request Time as alarms and statuses. Consider putting them on their own channel with a longer Request Time.

Request Time
100 ms is aggressive for this many tags. Start around a few hundred milliseconds, check that all values update reliably, then shorten carefully if needed. Operators rarely need faster than one second for monitoring.
Before and after
Keep a copy of the current frames with Import/Export Frames and Tags before restructuring, so you can go back if needed.
Documentation: https://greensoft.ai/documentation/o...ion-protocols/