MB_CLIENT DONE Always False: S7-1200 Modbus TCP Troubleshooting

1. Problem Overview

An S7-1200 CPU running TIA Portal is configured as a Modbus TCP client using the MB_CLIENT instruction from the "Modbus TCP" library. The instance is connected to a third-party field device, and the TCP session establishes without issue. The instance STATUS output cycles predictably through 7004 → 7005 → 7006:

• 7004 – Connection established and monitored. No job processing active.
• 7005 – Data was sent.
• 7006 – Data was received.

Despite this healthy-looking status sequence, the DONE output of the instance is observed as "always false" in the online watch table, BUSY toggles true/false with every request, and ERROR is also "always false". A second client (Modbus Poll on a PC) reaches the same field device without any problem, which proves the field device itself is functioning and reachable. The fault therefore lies inside the S7-1200 application logic and the way the application code interacts with the MB_CLIENT instance.

This article identifies the two independent root causes that produce the "DONE always false" symptom, shows the official Siemens status-code mapping that proves the job is actually completing, and gives a verified ladder/ST pattern for capturing DONE/ERROR so the symptom cannot be confused with a real communication failure.

2. MB_CLIENT STATUS Code Reference

The official TIA Portal reference for MB_CLIENT defines the STATUS output as the diagnostic word for the most recently completed (or currently running) job. The most relevant values for the scenario in this article are summarized in the table below.

The official Siemens documentation for the STATUS parameter is published in the TIA Portal help under "MB_CLIENT – Communicating via PROFINET as a Modbus TCP client" at the TIA Portal v21 Modbus TCP reference.

3. Root Cause #1 – REQ is Level-Controlled, Not Edge-Triggered

The first and most common cause of the "DONE always false" symptom is treating the REQ input as a one-shot pulse. The Siemens documentation states clearly that REQ is level-controlled:

"As long as the input REQ is set, the instruction sends communication requests. After the Modbus query has started, the instance DB is locked for other clients. Changes to the input parameters will not become effective until the server has responded or an error message has been output. If the parameter REQ is set again during an ongoing Modbus request, no additional transmission takes place afterwards."

Two implementation patterns that produce the symptom and must be avoided:

1. Clock-byte toggling of REQ. Code that writes REQ := NOT REQ on every OB1 cycle or on a fast clock bit such that the REQ pulse is shorter than the Modbus round-trip. The instance DB is locked for the duration of the transaction, but the falling edge before completion means the next rising edge is registered as a new request which immediately overlaps with the still-locked DB. The result is that the request either never completes cleanly or the DONE pulse is dropped before user logic can observe it.
2. Setting REQ false as soon as DONE is seen. This is harmless for the Modbus transaction itself, but if the code is doing something like IF DONE THEN REQ := FALSE on the same scan and then using DONE to drive a one-cycle flag, the visible "DONE always false" symptom appears. The fix is to keep REQ true continuously and use a separate edge-detected flag for "request issued" accounting.

The correct pattern is to hold REQ true continuously for the lifetime of the client session, allowing the instance to issue a new request as soon as the previous one completes. If cycle-by-cycle polling is required, the application can still monitor BUSY and ignore intermediate transitions.

4. Root Cause #2 – DONE/ERROR Pulse for One Scan Cycle

The second root cause is a behavioral nuance of the MB_CLIENT output flags. According to the reference manual:

"DONE and ERROR remain set for one cycle of the OB in which MB_CLIENT is called. If OB1 is the calling OB, DONE/ERROR are therefore visible for one OB1 cycle only."

For an S7-1200 with a typical OB1 cycle of 1–10 ms, and a Modbus request that takes 5–50 ms over a 100 Mbit/s PROFINET interface, the DONE pulse can fall entirely between two consecutive watch-table samples. The HMI tag that an operator expects to see "stick" will instead show a constant FALSE even though the instruction is completing successfully on every request.

This is the most important diagnostic insight of the article: a status sequence of 7004/7005/7006 cycling at the expected rate is proof that DONE is firing on every cycle – you simply cannot see it in a polled watch table. The fix is to latch DONE and ERROR in the user program.

5. Diagnosing the Symptom

Before changing any code, perform the following ordered checks. They are non-destructive and can be done on a live system.

1. Confirm the field device is reachable. Open TIA Portal "Online > Accessible devices" and ping the IP of the field device. Confirm the same IP is reachable from a PC running Modbus Poll. Both checks succeeding rules out cabling, switch, and IP issues.
2. Confirm the TCON_IP_v4 connection is established. In the watch table, monitor the connection DB. A value of 7004 on the STATUS word of the instance is by itself evidence that the TCP connection is up and idle.
3. Confirm the STATUS cycle rate. Add a counter tag STATUS_CHG_CNT that increments on every STATUS change. For a healthy Modbus TCP client polling once per 50 ms, you should see the counter increase at roughly 20 Hz. A counter that does not move confirms the instance is not even attempting requests.
4. Latch DONE and ERROR in the user program. Use the ST pattern in section 6 below. If LATCH_DONE rises to TRUE within a few hundred milliseconds of going online, the instruction is completing successfully and the previous "always false" reading was a measurement artifact.
5. If DONE does not latch and ERROR does not latch either, then the instance is being starved of REQ or the inputs are being overwritten. Add a watch on REQ and verify it is held TRUE continuously.

6. Latching DONE/ERROR in SCL

The minimal correct pattern in Structured Text for an S7-1200 calling MB_CLIENT from OB1 is shown below. It uses two static latches (lastD, lastE) to detect rising edges on the one-cycle outputs.

// Static latches in the instance FB or in a global DB
#lastD := #latchedDone;
#lastE := #latchedError;

IF #MODBUS_TCP_CLIENT[i].DONE AND NOT #lastD THEN
    #latchedDone := TRUE;
    #modbusOK   := #modbusOK + 1;     // diagnostic counter
END_IF;

IF #MODBUS_TCP_CLIENT[i].ERROR AND NOT #lastE THEN
    #latchedError := TRUE;
    #lastStatus   := #MODBUS_TCP_CLIENT[i].STATUS; // capture 8382/8383/...
END_IF;

// Edge-triggered clear (operator reset or HMI button)
IF #resetLatches THEN
    #latchedDone  := FALSE;
    #latchedError := FALSE;
END_IF;

Three engineering rules built into this pattern:

1. REQ is held TRUE for the whole session; the i-th instance is never clocked.
2. DONE and ERROR are latched on the rising edge. The latch survives until reset, which is what the watch table needs to actually see them.
3. The STATUS word is captured the same scan as the ERROR rising edge, so exception codes such as 8382 (illegal data address) are preserved for diagnostics even though STATUS itself is transient.

7. Latching DONE/ERROR in Ladder (LAD/FBD)

For a ladder implementation, use two SR flip-flops triggered on the rising edge of DONE and ERROR respectively. The set coil is driven by a P-contact (positive edge) on the instance output, and the reset coil is driven by an operator command.

MB_CLIENT.STATUS → LAST_ERR_STATUS

This ladder pattern is functionally equivalent to the ST snippet above and is the preferred form on S7-1200 CPUs that are programmed exclusively in LAD/FBD.

8. Common Companion Errors

When the latching pattern above is in place and LATCH_DONE still never rises, the failure has moved out of the "measurement" category and into a real application-layer fault. The most common offenders, in order of frequency, are:

9. Step-by-Step Verification Procedure

Use the following ordered procedure on a live machine to convert the symptom into a measurable, signed-off result.

1. Open the project in TIA Portal and go online with the S7-1200.
2. Open the watch table and add REQ, DONE, ERROR, BUSY, STATUS, and the two latch tags LATCH_DONE and LATCH_ERROR from section 6 or 7.
3. Force REQ = TRUE for the affected instance. Confirm it stays TRUE (does not oscillate).
4. Start the watch table at a 100 ms update interval. Watch STATUS for 5 seconds and confirm it cycles through 7004 / 7005 / 7006.
5. Observe LATCH_DONE. Within 200 ms it should transition from FALSE to TRUE. LATCH_ERROR should remain FALSE.
6. If LATCH_ERROR goes TRUE, read LAST_ERR_STATUS and map it through the table in section 2. Most commonly this will be 8382 for a read of a non-existent register, or 80C8 for a server that does not respond to the chosen function code.
7. Apply the fix in section 8 that matches the captured status code, online in the running CPU. Re-latch and confirm LATCH_DONE rises and stays risen with LATCH_ERROR staying FALSE.
8. Reset the latches via the operator button, and document the running STATUS in the HMI faceplate so the next shift can see "last successful poll at HH:MM:SS".

10. Commissioning Notes and Edge Cases

Several edge cases appear regularly in field commissioning and are worth calling out explicitly.

• Multiple instances, single partner. An S7-1200 can run up to 16 MB_CLIENT instances concurrently. Each instance has its own TCON_IP_v4 structure. If two instances point at the same partner IP, both will appear to establish a TCP connection but the partner's session table will fill. Symptoms on the second instance are similar to the one in this article – the partner simply drops the second connection. The official fix is to use a single MB_CLIENT and multiplex the function codes, or to open a second session only if the partner explicitly supports it.
• Library version mismatch. The S7-1200 Modbus TCP library was substantially rewritten at V4.0. Earlier library versions (V3.x and below) used a different instruction name and had a different STATUS word layout. Mixing an old instance DB with a new instruction produces a status of 7003 with DONE never rising. The official Siemens upgrade path is documented in the TIA Portal online help under the same "Modbus TCP for the library versions V4.0 and later" topic.
• Watch table update interval. TIA Portal's default watch-table update interval is 500 ms. A Modbus request that completes in 30 ms is therefore invisible 16× out of 17 samples. Set the watch-table update interval to its minimum (100 ms) for any test that depends on observing DONE in real time.
• Online vs. physical I/O behavior. When the CPU is stopped, MB_CLIENT closes its TCP connection. STATUS will return to 7000 and DONE will not fire. This is correct behavior; it is not a fault.
• HMI tag polling. HMI tags derived directly from DONE will appear to flicker. Always bind HMI tags to the latched version. The HMI's polling interval (typically 250–1000 ms) makes the flicker look like a permanent FALSE.

11. Field-Proven Patterns

The following two patterns have proven robust across multiple site deployments of S7-1200 Modbus TCP clients and are recommended as the baseline for new projects.

11.1 Single client, polled

// OB1 SCL
IF "FIRST_SCAN" THEN
    "MB_CLIENT_1".REQ := TRUE;          // held true for entire session
    "MB_CLIENT_1".DISCONNECT := FALSE;
END_IF;

// Latch outputs in a separate FC, e.g. FC100 "MB_DIAG_LATCH"
"MB_DIAG_LATCH"(client := "MB_CLIENT_1");

11.2 Multiple instances, single FB

// FB1000 "MB_CLIENT_HANDLER"
// Input: instance index, target IP, MB_MODE, MB_DATA_ADDR, MB_DATA_LEN
// Static: latches per index
// Behavior: holds REQ true, latches DONE/ERROR, exposes a method
//           to clear latches and read the captured STATUS

Centralizing the latching logic into a single FB means every instance of MB_CLIENT in the project uses the same diagnostic pattern, and the HMI only needs to bind to one tag per instance.

12. Frequently Asked Questions