Reading Modbus TCP Connection Status in WinCC Professional

Overview

Reading the connection state of a Modbus TCP link in WinCC Professional is a routine requirement when you need to alarm on a lost link, drive a visibility animation, or log the uptime of a polled device. WinCC Professional exposes connection diagnostics as internal HMI performance tags, which means the HMI runtime itself continuously samples the driver state and presents it as a normal tag that can be referenced from scripts, alarms, dynamization, and the tag logging archive. No external script, no OPC heartbeat counter, and no PLC round-trip is required to read a single bit of connection health for the Modicon Modbus TCP driver that ships with TIA Portal V15, V15.1, V16, and V17.

The technique described here uses the system performance tag @<ConnectionName>@ConnectionStateEx, evaluated inside the HMI runtime. Values are integers: 1 indicates the driver currently holds a healthy connection to the remote Modbus TCP server, and 0 indicates that the driver has not established, or has lost, the connection. The same mechanism is used for S7 connections and for third-party drivers that register a connection with the WinCC channel unit, which is why understanding the pattern is valuable even when Modbus TCP is later replaced by another channel.

Prerequisites

• Siemens TIA Portal V15, V15.1, V16, or V17 with WinCC Professional installed (either the WinCC Runtime Professional PC component or the WinCC Professional engineering component on the engineering station).
• A configured Modbus TCP connection in the HMI device tree. The "Modicon Modbus TCP" channel is the default driver supplied with TIA Portal and is the driver referenced throughout this article.
• Read access to the WinCC Information System that installs with the engineering environment. The connection-state performance tags are documented under "Visualizing processes > Working with tags > Performance tags" in the WinCC Information System.
• The exact connection name as it appears under HMI tags > Connections. Connection names are case-sensitive and must match the @-tag exactly.

The Modicon Modbus TCP driver implements a polled TCP connection. Unlike the Siemens S7 driver, which can be configured for unsolicited partner connections, Modbus TCP always originates from the HMI. Connection loss is therefore detected from the HMI side when the underlying TCP socket is reset or when the response timeout expires.

Understanding the Modicon Modbus TCP Driver in WinCC

The Modicon Modbus TCP driver in WinCC Professional is the Schneider Electric Modbus protocol stack adapted to the TIA Portal channel framework. It is invoked from the HMI connection editor by selecting Modicon Modbus TCP as the communication driver and entering the partner IP address, port (default 502), and unit identifier (slave address). The driver opens one TCP socket per connection and uses it for all configured tags; the socket is maintained as long as the runtime is in RUN, and a lost socket is reported through the connection state tag.

Unlike a PLC connection, which can use the S7 protocol to detect end-of-bus failure, the Modbus TCP driver relies on the absence of valid Modbus responses. The two main loss scenarios are:

• Physical loss: cable unplugged, switch powered down, IP address unreachable. The TCP stack reports connection failure on the next write or read attempt.
• Logical loss: device still reachable on TCP/IP, but the Modbus server has stopped responding. The driver's request timeout triggers the disconnect state.

Both scenarios surface in the same performance tag. The driver does not expose a separate "logical loss" indicator, so wiring a single tag is sufficient for alarm and visibility purposes.

The @ConnectionStateEx Internal Tag

WinCC Professional supports a set of system-defined performance tags that report on the state of a configured connection. The full list documented in the WinCC Information System is:

Tag	Data type	Meaning
@<Conn>@ConnectionState	Integer	Legacy state code. 0 = disconnected, 1 = connected, others = transitional. Retained for backward compatibility.
@<Conn>@ConnectionStateEx	Integer	Extended state. 1 = connection OK, 0 = no connection. Recommended for new projects.
@<Conn>@ConnectionName	String	Returns the configured connection name.
@<Conn>@ConnectionError	Integer	Last error code reported by the channel DLL.
@<Conn>@ConnectionTime	Date/Time	Timestamp of the last successful cyclic update.

The placeholder <Conn> is the connection name as configured in the TIA Portal HMI project. For a connection named ECL_SM2 the extended state tag is therefore @ECL_SM2@ConnectionStateEx. The tag behaves as a normal internal HMI tag: it is read-only, updated once per second by default, and requires no further configuration in the connection editor.

Two implementation details that field engineers routinely miss:

1. Connection names are case-sensitive. @ECL_SM2@ConnectionStateEx is a different tag from @ecl_sm2@ConnectionStateEx; the runtime will silently report quality "bad configuration" for the wrong-case variant.
2. The tag is not auto-generated. WinCC Professional does not pre-populate the performance tag in the HMI tag table. You must add it manually as an internal tag with the exact @-prefixed name; the runtime only begins to evaluate the @-tag once the HMI tag that uses it is loaded.

Step-by-Step: Creating the Connection State Tag

1. In the TIA Portal project tree, expand your HMI device and open HMI tags.
2. Double-click Default tag table (or a project-specific table) to open the tag editor.
3. Click an empty row and enter a Name for the connection state tag. The display name is free-form (e.g., ModbusConnState) and is what scripts and dynamization will reference.
4. Set Connection to <Internal tag>. The performance tag is not associated with a physical connection in the tag table; the @ prefix in the tag name is what the runtime interprets.
5. Set Data type to Int or Word. A signed 16-bit integer is the canonical choice and matches the values documented in the Information System.
6. Set Length to 1 element.
7. Set Acquisition mode to Cyclic in operation with a 1 s cycle. The performance tag updates at the channel heartbeat, so 1 s is the lowest meaningful sample rate.
8. In the Address column, enter the @-prefixed name in the Name field, e.g., @ECL_SM2@ConnectionStateEx. The Address field itself stays empty; the @-tag is the address.
9. Compile and download the HMI runtime. The tag will start reporting 1 once the driver opens the socket and 0 if the socket cannot be opened or is reset.

For a connection whose configured name contains spaces, TIA Portal strips spaces during validation. Use underscores in the connection name to avoid ambiguity in scripts and alarm triggers.

Mapping Connection State to Alarms and Visibility

Visibility animation

Bind the Visibility property of a "Connection lost" icon to the state tag with the expression {ModbusConnState} = 0. The icon shows when the connection is down and hides when it returns. This is the most common pattern because it requires no scripting.

Bit-message alarm

Open HMI alarms > Discrete alarms and add an alarm with the trigger tag set to ModbusConnState. Configure the alarm to fire on the rising edge of 0 (state change from OK to not OK) and to clear on the falling edge. Add a debounce of 5 s to suppress flapping when the partner device reboots.

Tag logging

Add ModbusConnState to a logging tag group with a 1 s cycle. Use the tag in a trend view to see connection uptime across shifts. Combine with a calculated tag that reports total downtime per shift.

VBScript heartbeat for a higher-level SCADA

If the WinCC station forwards a heartbeat to a corporate MES via OPC UA, expose ModbusConnState as a public OPC UA node. A MES consumer that polls once per minute will see 0 within 90 s of a real outage - faster than the MES can detect by polling the data tags themselves, because the connection state is sampled even when no data tags are configured.

Alternative: PLC-Side Status with MB_CLIENT

Some projects route Modbus TCP through an S7-1200 or S7-1500 PLC rather than directly from the HMI. In that topology the connection state is reported by the MB_CLIENT instruction in the PLC, not by the HMI driver. The instruction block exposes:

• DONE - one-shot pulse on successful completion of a request.
• BUSY - request in progress.
• ERROR - request failed.
• STATUS - detailed error code (function code, exception code, or Modbus exception code returned by the partner).

To convert the request-level signals into a connection-level boolean, add a small state machine in the PLC that sets a memory bit high on the first ERROR within a window and clears it on the next DONE. A typical implementation is:

// Rising-edge detector on MB_CLIENT.ERROR
IF "mb_client".ERROR AND NOT "error_latch_edge" THEN
    "error_count" := "error_count" + 1;
END_IF;
"error_latch_edge" := "mb_client".ERROR;

// Connection OK when the last N seconds contained at least one DONE
IF "mb_client".DONE THEN
    "time_since_last_done" := T#0s;
END_IF;
IF "time_since_last_done" < T#10s THEN
    "modbus_conn_ok" := TRUE;
ELSE
    "modbus_conn_ok" := FALSE;
END_IF;
"time_since_last_done" := "time_since_last_done" + CYCLE_TIME;

Expose modbus_conn_ok as a single PLC tag and read it in the HMI via the S7 connection. The downside is that the HMI is now coupled to a healthy S7 link in addition to the Modbus device; the upside is that the HMI continues to show accurate Modbus status even if the Modbus device is reachable but refuses requests.

The MB_CLIENT STATUS word is a useful diagnostic. Typical categories of values are:

STATUS range	Meaning
0x0000	No error.
0x80C0 - 0x80CF	TCP-level errors (timeout, refused, unreachable). See TIA Portal Help for the exact mapping.
0x80D0 - 0x80DF	Modbus protocol errors (exception, invalid response length, unsupported function code).
Non-zero other	Refer to the MB_CLIENT instruction documentation for the precise meaning.

See the TIA Portal Help on the MB_CLIENT instruction for the full status table; the ranges above are the ones field engineers see in practice. The reference manual is part of the TIA Portal installation and is available from the TIA Portal communication function manual.

Performance Tags and Connection Diagnostics

WinCC Professional maintains additional performance tags outside the connection namespace. These are useful for diagnosing whether a lost Modbus connection is part of a wider HMI problem:

Tag	Reports
@ConnectionState (no prefix)	Aggregate state of all configured connections. 0 = at least one connection down.
@CPUUsage	HMI runtime CPU load in percent.
@RAMUsage	HMI runtime memory footprint in MB.
@ServerState	Overall HMI server state (1 = running).

If @ConnectionState is 0 but @CPUUsage is below 50 %, the HMI itself is healthy and the loss is at the network or device. If @CPUUsage is pegged at 100 %, the runtime is starved and connection failures are secondary. This split diagnostic is one of the strongest arguments for using the @-tag mechanism over a user-scripted heartbeat.

HMS Networks Modbus TCP/IP Master Driver for WinCC

When the Modicon Modbus TCP driver does not fit the device - for example, a non-standard function code, a non-Modicon device that ships with its own Modbus profile, or a project that requires the Anybus X-gateway - HMS Networks offers a third-party Modbus TCP/IP Master driver that registers as a WinCC channel. The driver is installed as a Windows service and exposes the same connection state semantics, but the tag names follow the HMS naming convention rather than the @-prefix performance tag pattern.

Configuration steps for the HMS driver (summarized from the HMS Networks application note for WinCC over Modbus TCP/IP):

1. Install the HMS Modbus TCP/IP Master driver on the WinCC station.
2. Run the HMS configuration tool and add a Modbus TCP/IP channel. Enter the partner IP, port, and unit identifier.
3. Map each Modbus register/holding register to an HMS address. The driver uses the standard Modbus address notation (4x for holding registers, 3x for input registers, etc.).
4. In WinCC Professional, add the HMS driver as a new connection type. The connection name you assign in this step becomes the prefix for the HMS performance tags.
5. Create the HMI tags that point to the HMS addresses. The connection state is reported as a separate HMS tag, not as a performance tag.

For projects that already use the HMS driver, the official application note from HMS Networks documents the supported function codes, the read/write cycles, and the alarm wiring pattern. The note is the canonical reference for the driver and is the first place to look when a Modbus device requires function codes beyond the standard 1-6 and 15-16 set.

Verification Procedure

After deploying the HMI project, validate the wiring with the following steps:

1. Open the WinCC Runtime with the project loaded. Confirm the connection state tag reads 1 within 2-3 s of start-up.
2. In the WinCC tag simulator, force a value into a Modbus tag. Confirm the HMI displays the new value within the configured acquisition cycle (default 1 s).
3. Disconnect the network cable from the partner device. Within the driver timeout window (typically 5-10 s, depending on the configured request timeout and the partner's TCP keep-alive) the connection state tag must transition to 0.
4. Reconnect the cable. The tag must transition back to 1 within the same window.
5. Trigger a partner device power cycle. The tag must report 0 during the reboot window and 1 after the device is fully back. This is the field test for "logical loss" - the IP is still reachable, the Modbus server is not.
6. From the WinCC alarm view, confirm the discrete alarm fires and clears on the correct edges, and that the debounce window suppresses flapping during partner reboot.

If the tag stays at 0 even though the partner is reachable and responding, check the connection name in the tag editor for typos and case mismatches. If the tag oscillates between 0 and 1 every second, the network is dropping packets and the driver is reporting each timeout - in this case the partner device is the bottleneck (insufficient socket backlog, slow Modbus server, or under-powered CPU on the partner).

Troubleshooting Matrix

Symptom	Likely cause	Action
Tag value always 0	Wrong connection name in @-tag, or connection not downloaded to runtime.	Verify the connection name in the HMI Connections editor. Recompile and re-download the HMI.
Tag value always 0 even after a successful read	Tag created as a connection-bound tag, not an internal tag.	Change the Connection column to "Internal tag" and confirm the @-prefixed name is in the Name field, not the Address field.
Tag value oscillates 0/1 every second	Partner device drops Modbus responses under load.	Increase the Modbus request timeout in the channel parameters. Confirm partner device has sufficient CPU and socket backlog.
Tag value stuck at 1 even when device is off	Driver's TCP keep-alive is disabled or set very long, and the OS does not yet know the socket is dead.	Check the channel parameters for keep-alive interval. Default is OS-dependent; consider reducing to 30 s.
Tag quality "bad configuration" in tag simulator	Connection name contains a character that the @-tag parser rejects (hyphen, slash, space).	Rename the connection to use only letters, digits, and underscores. Recompile.
Alarm fires continuously without debounce	Debounce not configured, or configured too short.	Add a 5 s debounce on the discrete alarm trigger.
Tag value is correct in runtime but not in tag simulator	Tag simulator runs against a local stub, not the live runtime.	Use the online tag table inside the live runtime for verification, not the engineering tag simulator.
HMI loses connection during partner reboot, but PLC does not	Driver request timeout is shorter than the partner's boot time.	Increase the Modbus request timeout to 10-15 s for devices with long boot times.
Connection state reads 0 on a redundant WinCC Server pair's standby	Standby server does not run the channel; state is 0 until failover.	Verify the standby server is the intended behavior. Read state through the active server's OPC UA interface, not directly from the standby.
Tag value is 0 only on a specific HMI client	Connection is disabled on that client in the HMI client configuration.	Open the client's connection list and enable the Modbus connection.

Field-Commissioning Notes

Three points that consistently come up during commissioning:

1. Connection name stability. If a connection is renamed late in the project, every @-tag that references the old name stops working. The TIA Portal compiler does not warn about @-tag references because the @-prefix puts them outside the normal cross-reference scan. Use a naming convention that survives refactors (for example, MODBUS_<device>_<area>) and document the prefix list in the project's tag-naming standard.
2. Multiple HMI clients. In a multi-client WinCC Professional project, the performance tag is evaluated per client. If a client has the connection disabled, the @-tag returns 0 even though the server is healthy. Validate the connection enable list on each client before declaring the wiring broken.
3. HMI panel vs PC runtime. The @-tag mechanism works on Comfort Panels and Unified Comfort Panels as well as on PC-based WinCC Runtime Professional. On panels, the @-tag is sampled locally; on a PC station with redundant server pairs, the @-tag is sampled on the active server. This is important when configuring a redundant WinCC Server pair - the connection state on the standby server is 0 until failover, which is correct behavior but must be understood before reading the value through a client.
4. Tag simulator does not exercise the channel. Forcing a value into the connection state tag from the tag simulator overwrites the runtime's view of the tag, but does not exercise the underlying channel. The simulator is useful for testing scripts and dynamization; the real channel behavior must be verified in the live runtime against the live partner device.
5. Firewall and Windows Defender rules. A newly installed WinCC Runtime on a Windows Server 2019 or 2022 host can have its outbound TCP/502 blocked by Windows Defender Firewall if the rule is created on first run. The connection state tag will read 0 even though the project is correctly compiled. Open the Windows Defender Firewall with Advanced Security console and confirm an outbound rule exists for the WinCC Runtime process on TCP/502 to the partner IP.

Summary

The @<ConnectionName>@ConnectionStateEx performance tag is the documented WinCC mechanism for reading Modbus TCP connection health. It is set up as an internal HMI tag, sampled once per second, and returns 1 when the driver holds a healthy TCP socket to the Modbus server and 0 otherwise. Wiring it to a discrete alarm, a visibility animation, or a tag log gives an end-to-end monitoring solution that does not depend on the PLC, the data tags, or any custom script. For projects that route Modbus through an S7 PLC, the equivalent mechanism is the MB_CLIENT instruction's ERROR and DONE signals aggregated into a connection-level boolean. For projects that use the HMS Networks third-party driver, the connection state is exposed as an HMS-named tag rather than a performance tag, and the HMS application note is the canonical reference for the driver.