Troubleshooting AG_SEND/AG_RECV Delays in S7-300/S7-400 Online Monitoring

Engineers using STEP 7 V5.4 to commission an ISO-on-TCP link between an S7-300 and an S7-400 frequently report a symptom that looks like a network fault but is actually a deterministic side effect of online monitoring: a one-second incrementing watchdog on the partner PLC appears to advance only every several seconds in the variable table, and continues to advance for a long time after the partner stops sending. When the engineer terminates the online session, the watchdog snaps to the expected value. This article isolates the root cause (CP receive buffer queueing under online load), documents the affected blocks and firmware ranges, and gives a sequenced set of corrective actions plus a verification procedure.

1. Problem Description

The reference installation is configured as follows:

Observed symptoms

1. When the engineer opens a Variable Table in Monitor mode, the watchdog value visible on the S7-400 increments in steps of 1, but the apparent step interval is many seconds — often 10 s to several minutes, depending on the number of monitored variables and the OB1 cycle time.
2. The value is never wrong by a non-integer amount and never jumps. It is a deterministic, monotonic lag.
3. If the S7-300 stops sending (AG_SEND no longer called, or EN cleared), the S7-400 value continues to increase for a long time and only gradually catches up.
4. Closing the online session causes the watchdog to immediately snap to the value the partner would have shown, confirming that no data was lost — only queued.

The pattern is not a defective cable, a faulty CP, or a wrong connection configuration. The hardware path is correct; the issue is the rate at which the receiver CP can deliver buffered frames to the CPU while the CPU is simultaneously servicing the online monitor.

2. Why Online Monitoring Slows the Visible Update

STEP 7 V5.4 online monitoring is implemented as a parallel read service against the CPU. While a VAT is in monitor mode, the programming device (PG) issues OPTI_PE/OPTI_PI / OPTI_RD-style read requests at the configured poll rate (default ~1 s for VAT, 500 ms for the Monitor/Modify dialog). Each request:

1. Interrupts the current OB1 scan at the next communication load window.
2. Consumes a slice of the CPU's communication budget.
3. Is dispatched into the Ethernet CP through the internal backplane bus.

The S7 CPU firmware partitions its scan into the process image update, the user program, and the communication share. The communication share is bounded; if the share is exhausted, the rest of the scan finishes before the OS services the next communication request. This is a deterministic design choice; it guarantees that cyclic OB1 time never starves the process, at the cost of bounding throughput on the communications bus.

When AG_RECV is called every OB1 cycle and the PG is also polling the VAT, two consumers fight for the same communication share. The frames that the S7-400 CP has already received from the S7-300 are correctly stored in the CP's internal receive buffer, but the CPU does not free the buffer until the next AG_RECV call is dispatched with available communication share. The result is a growing queue in the CP and a visible lag in the variable table.

3. Affected Products and Firmware

Any S7-300/S7-400 combination that uses the SIMATIC NET CP library blocks AG_SEND (FC 5) and AG_RECV (FC 6) over ISO-on-TCP can exhibit the symptom. The S7-200 series uses different blocks (ETHx_CTRL, ETHx_SEND, ETHx_RECV) and is not in scope.

4. Root Cause Analysis

The root cause is the combination of three independent design parameters. If any one of them is changed, the symptom magnitude changes accordingly.

4.1 CPU Communication Load Setting

The communication load is the share of the CPU scan reserved for communication services. The valid range is hardware-dependent:

The communication load is configured in HW Config → Properties of the CPU → Cycle/Clock Memory tab → Communication Load. The S7 firmware checks every millisecond whether the communication budget is exhausted; if it is, communication services are deferred to the next millisecond. With the default 20% load and a 100 ms OB1, only 20 ms of each cycle is available for all communication, including:

• AG_RECV completion of one buffered frame
• PG polling of the VAT
• Any active HMI connection (e.g. WinCC, TIA Portal HMI tag service)
• Time-of-day synchronisation (where configured)

4.2 Call Frequency of AG_RECV

The user is invoking AG_RECV inside OB1 (or in a low-priority cyclic OB), which is the conventional pattern. However, if OB1 is 140 ms and the S7-300 is sending at 1 Hz, the CP still receives every frame in real time, but the receiver CPU only services one frame per AG_RECV call. If the S7-300 sends faster than the receiver can drain, the CP buffer grows.

Buffer sizing for the CP 343-1 / CP 443-1 family is documented in the SIMATIC NET manuals: each ISO-on-TCP connection has a configurable receive window, defaulting to 8192 bytes per connection. A 1 Hz INT payload (2 bytes) generates roughly 1.6 kB of buffered data per hour; this is trivial. The real queueing is the unserviced frames — the CP holds the frame in its internal RAM until AG_RECV is dispatched with a free communication share.

4.3 Parallel Demand from Online Monitor

Every visible variable in the VAT consumes one read service per VAT poll cycle. STEP 7 V5.4 issues these reads as individual request-response pairs to the CPU, not as a single bulk read. With a 10-variable VAT and a 1 s poll, the PG places 10 read requests per second on the same communication bus. This is the dominant extra load during online monitoring, and it is absent when the VAT is closed.

4.4 Quantitative Model

Let T_OB1 be the OB1 cycle time of the receiver CPU, ρ the configured communication load, N_AG the number of AG_RECV call completions per second, and N_PG the number of PG read requests per second. The theoretical communication time share per second is:

T_comm = ρ × 1000 ms  (per second of wall time)

Each AG_RECV completion costs approximately 1.0–1.5 ms of CPU time on an S7-400, and each PG read of a single variable costs approximately 0.5–0.8 ms. The system enters a backlog condition when:

N_AG × t_AG + N_PG × t_PG > ρ × 1000 / T_OB1 (per OB1 cycle)

For an S7-400 with T_OB1 = 100 ms, ρ = 0.20, t_AG = 1.2 ms, t_PG = 0.6 ms per variable and 10 visible variables, the budget per cycle is 20 ms. The demand is 1 × 1.2 + 10 × 0.6 = 7.2 ms per cycle — within budget, but the headroom evaporates once HMI tags or additional PG requests are added. The symptom is therefore most pronounced on installations with parallel HMI servers or large VATs.

5. Diagnostic Procedure

Before changing any code or configuration, prove that the symptom is buffering and not packet loss. Run the following checks:

1. Close all VATs and HMI sessions and leave the system running for 5 minutes. The watchdog should advance at exactly 1 Hz on the receiver.
2. Open a single VAT with the watchdog value and one or two adjacent variables. The watchdog should advance at 1 Hz.
3. Add a second VAT on the same connection, monitoring 20 unrelated variables. The watchdog should begin to lag.
4. Capture the OB1 scan time from the CPU diagnostic buffer (Path: PLC → Module Information → Diagnostic Buffer, look for Cycle time exceeded or read OB1_LAST_CYCLE via the system clock area). A scan time > the configured T_OB1 confirms the CPU is overrunning.
5. Read the CP statistics on the receiver side via the SIMATIC NET diagnostics (in STEP 7 V5.4: PLC → Ethernet → Diagnostics). Look at Number of received frames and Number of discarded frames. Discarded = 0 confirms no loss; the lag is purely a queue effect.
6. Trace with a managed switch (e.g. SCALANCE XC-208 port mirror) using Wireshark with the s7comm dissector. You will see frames arriving on the wire at 1 Hz, regardless of the VAT lag — definitive proof of the queue.

6. Solution Matrix

Four independent remedies are available. Apply them in the order listed, and re-test after each change.

6.1 Raise the Communication Load

Open HW Config → CPU properties → Cycle/Clock Memory tab → Communication Load. Increase the value from 20% to 50% (the maximum on S7-300 and classic S7-400). Verify that OB1 scan time remains well below the configured maximum; the trade-off is that the OB1 cycle time floor increases because the CPU always reserves the configured share, even when no communication is in progress.

The relationship between communication load ρ and the minimum achievable OB1 cycle time is:

T_OB1_min = T_OB1_typical / (1 − ρ)

For a typical OB1 of 50 ms and a change from 20% to 50%, the minimum scan time rises from approximately 62.5 ms to 100 ms. This is acceptable for non-deterministic process applications but must be evaluated against the worst-case response time of the controlled process.

6.2 Switch to BSEND/BRECV or PUT/GET

BSEND/BRECV (S7 communication) and PUT/GET (S7 communication, server function on the partner) use a different mechanism than AG_SEND/AG_RECV. They use the S7 communication load scheduling described earlier (10–50% on S7-300/S7-400 classic, 5–50% on S7-400-PN), which is more efficient for cyclic, small-payload data exchange and is the Siemens-recommended replacement for AG_SEND/AG_RECV on S7-300/S7-400 installations.

Migration steps:

1. In NetPro on the S7-300 side, insert an S7 connection rather than a TCP/ISO-on-TCP connection. Set the partner to the S7-400.
2. On the S7-400 side, accept the partner connection; no application-side configuration is required because PUT/GET runs as a server.
3. Replace AG_SEND calls with BSEND (FB 12) calls and AG_RECV with BRECV (FB 13) calls. Reference the SIMATIC NET programming manual for the IDB structure (the LEN, R_ID, and SD_1..SD_4 inputs are now mandatory).
4. If a unidirectional, server-side initiated write is sufficient, use PUT (FB 15) and GET (FB 14) on the client side. PUT/GET does not require any code on the server CPU.

Sample BSEND IDB configuration (representative excerpt):

DATA_BLOCK DB_Comm
  STRUCT
    REQ       : BOOL;   // rising edge triggers a send
    R         : BOOL;   // abort current job
    ID        : WORD;   // W#16#1 – connection ID from NetPro
    R_ID      : DWORD;  // any unique value, must match BRECV on partner
    DONE      : BOOL;   // job completed without error
    ERROR     : BOOL;   // job completed with error
    STATUS    : WORD;   // status code from BSEND
    SD_1      : WORD;   // first 2 bytes of user data
    SD_2      : WORD;   // bytes 3..4 of user data
    SD_3      : WORD;   // bytes 5..6 of user data
    SD_4      : WORD;   // bytes 7..8 of user data
    LEN       : WORD;   // number of valid bytes in SD_1..SD_4
  END_STRUCT
END_DATA_BLOCK

6.3 Use a Time-Triggered Send Pattern (no replacement of blocks)

If AG_SEND/AG_RECV must be retained, restructure the user program as follows:

1. Place the call sequence in OB1 as: AG_RECV first, then process logic, then AG_SEND last. This ensures that one receive is serviced per cycle before any new send occupies the communication share.
2. Trigger the AG_SEND from a 1 s timer (e.g. clock memory bit M10.7 from the CPU clock memory byte, or a TP/SE timer in OB35) and not from OB1 edges. This decouples the transmission rate from the OB1 cycle time.
3. Hold the previous send's DONE flag as a guard, and only re-trigger AG_SEND after DONE has been received. If DONE does not appear within 10 s, the previous send is considered failed and the next is initiated with a fresh IDB instance.

This pattern is the one used in the Siemens SIMATIC NET application examples for S7-300 ISO-on-TCP communication. The reference example is in the S7-1200 PTP programming manual collection which describes the same global-DB-backed communication buffer pattern: Programming the STEP 7 program – SIMATIC S7-1200 Manual Collection.

6.4 Separate the Online Monitor from the Production Link

Open the VAT through a different physical interface than the AG_SEND/AG_RECV traffic. Two options are supported on most S7-300 and S7-400 CPUs:

• Use the MPI/DP interface for online monitoring (set the PG/PC interface to MPI or PROFIBUS). MPI/DP has its own communication budget and does not contend with the Ethernet CP.
• Use the second Ethernet interface of a CPU 41x-PN or a CP 443-1 Adv (a separate IP subnet) for the engineering channel, leaving the primary Ethernet interface dedicated to AG_SEND/AG_RECV.

This is the cleanest solution for installations where the communication budget cannot be increased and the block code cannot be migrated.

7. Programming Pattern: Corrected AG_SEND / AG_RECV Cycle

The following structural pattern is recommended for installations that must keep AG_SEND/AG_RECV. It implements the four improvements described in §6 in a single FB.

FUNCTION_BLOCK FB_Comm_Cycle
VAR
    tSend : TON;                   // 1 s send timer
    tWatch : TON;                  // 10 s send timeout
    bSendBusy : BOOL;
    bSendDone : BOOL;
    bSendError : BOOL;
    wSendStatus : WORD;
END_VAR
BEGIN
    // 1) Receive first – drain the CP buffer as early as possible
    AG_RECV(
        ID        := 1,
        LADDR     := W#16#0100,     // I/O address of the CP from HW Config
        RECV_DB   := 100,            // DB that holds the watchdog and other data
        NDR       := bNDR_recv,
        ERROR     := bErr_recv,
        STATUS    := wStat_recv,
        LEN       := wLen_recv);

    // 2) Application logic here – operates on the data in DB100

    // 3) Trigger send once per second, but only when not busy
    tSend(IN := NOT bSendBusy, PT := T#1S);
    tWatch(IN := bSendBusy, PT := T#10S);

    IF tWatch.Q THEN
        // previous send has been pending for >10 s – abort and re-arm
        AG_SEND(
            ID        := 1,
            LADDR     := W#16#0100,
            SEND_DB   := 100,
            REQ       := FALSE,
            DONE      := bSendDone,
            ERROR     := bSendError,
            STATUS    := wSendStatus);
        bSendBusy := FALSE;
    END_IF;

    IF tSend.Q AND NOT bSendBusy THEN
        bSendBusy := TRUE;
        AG_SEND(
            ID        := 1,
            LADDR     := W#16#0100,
            SEND_DB   := 100,
            REQ       := TRUE,
            DONE      := bSendDone,
            ERROR     := bSendError,
            STATUS    := wSendStatus);
    END_IF;

    // Latch the DONE / ERROR edge and clear REQ in the next cycle
    IF bSendDone OR bSendError THEN
        AG_SEND(
            ID        := 1,
            LADDR     := W#16#0100,
            SEND_DB   := 100,
            REQ       := FALSE,
            DONE      := bSendDone,
            ERROR     := bSendError,
            STATUS    := wSendStatus);
        bSendBusy := FALSE;
        tSend(IN := FALSE, PT := T#1S);
    END_IF;
END_FUNCTION_BLOCK

The pattern is critical at two points:

• REQ := FALSE must be issued after DONE/ERROR to release the block; if REQ stays TRUE, the block will fire a second job as soon as the first completes, doubling the load on the communication share.
• The 10 s timeout (variable tWatch) protects against a deadlock where the partner CP has stopped acknowledging (e.g. cable fault, partner CPU in STOP). Without it, the FB will stay in bSendBusy := TRUE forever and the watchdog will appear to freeze on the receiver side.

8. AG_SEND / AG_RECV Status Codes

The status words of AG_SEND and AG_RECV (output STATUS) use the following error classes. Inspect these in the VAT as the first diagnostic step.

For the symptom described in this article, the STATUS word on both sides will read 0000 (DONE) at each successful transfer — the job itself is succeeding; it is the dispatch of the next job that is being delayed. STATUS is therefore a poor diagnostic on its own; the Wireshark trace described in §5 is the more reliable evidence.

9. Verification Procedure

After applying any of the four remedies, perform the following to confirm the issue is resolved:

1. Open the VAT containing the watchdog and the diagnostic STATUS word from AG_RECV. Confirm STATUS = 16#0000 continuously.
2. Add 20 additional unrelated variables to the VAT. The watchdog must continue to increment at 1 Hz within ±10%.
3. Start a WinCC flexible / WinCC RT instance that polls 200 tags over the same connection. The watchdog must continue to increment at 1 Hz within ±10%.
4. Disconnect the partner S7-300 from the network. Within 10 s (the tWatch timeout from §7), the receiver must report a fault; no further watchdog updates should occur.
5. Reconnect the partner. The receiver must resume watchdog updates at 1 Hz within 2 s.
6. Read the CPU diagnostic buffer on the S7-400: Diagnostic Buffer → Communication. No Communication error events with ID 0x0E31 / 0x0E32 / 0x0E33 should be logged. These IDs map to connection abort events and would indicate packet loss rather than queueing.

10. Related Configuration Caveats

• Connection type in NetPro: For ISO-on-TCP, the S7-300 connection must be of type TCP native / ISO-on-TCP with active role on the S7-300 side and passive on the S7-400 side. Reversing the role causes 80A0 at startup.
• CP slot/I/O address: The LADDR parameter in AG_SEND/AG_RECV is the diagnostic address of the CP, not the slot number. In HW Config, right-click the CP → Properties → Addresses and read the Input addresses start. Use this value as LADDR in hex (e.g. 256 dec → W#16#0100).
• DB length on the partner: The send and receive DBs on both sides must be at least the maximum LEN of any job, or 80B1 is reported on the very first send.
• PG/PC interface selection: In STEP 7 V5.4, Options → Set PG/PC Interface must select the network card bound to the same subnet as the CP. Selecting the wrong adapter causes the online monitor to time out at the IP level and may appear to be a buffering issue because STATUS will not change.
• Time synchronisation: If the S7-300 is the time master and broadcasts time-of-day to the S7-400, the broadcast itself consumes communication share. Set the time synchronisation interval to 10 s or longer unless 1 s is required by the process.

11. Quick-Reference Fault Matrix

12. Frequently Asked Questions