Configuring WinCC Modbus TCP Driver for Non-Modicon PLCs

Overview of the WinCC Modbus TCP/IP Driver

The Siemens WinCC SCADA suite ships with a native Modbus TCP/IP channel driver (Modbus TCPIP.chn) intended primarily for communication with Schneider Electric (formerly Modicon) controllers. The driver presents only three PLC class entries in its connection properties dialog:

• Modicon 984
• Modicon Compact / Quantum / Momentum
• Modicon Premium / Micro

When the target controller is not a Schneider product — for example a Hitachi R-700 series (PLU500), an HMS eWON 2005 RTU, a generic Modbus TCP slave, or a third-party PLC with a Modbus server — the question becomes which class to select, whether communication will work, and how to map tag addresses correctly. Field experience shows that any of the three Modicon classes can be used as a logical "container" for a non-Modicon device, provided the target speaks standard Modbus TCP/IP. The driver itself is intentionally limited: Siemens describes it as a driver "with only very few options for setup" that "offers very little to customize the reply" if protocol deviations occur on the slave side.

When the native driver falls short, a Modbus TCP OPC bridge (such as the Lectus Modbus OPC Server) inserted between the slave and WinCC is the standard fallback. This article documents the full configuration path, the addressing rules, the field-proven trial-and-error workflow, and the OPC alternative.

Prerequisites

Strategy for PLC Class Selection with Non-Modicon Devices

The WinCC driver dialog does not refuse non-Modicon devices, but it does not validate them either. The class selection is effectively a protocol variant selector. Use the following decision matrix when the target is not a Schneider PLC:

For any non-Schneider PLC, the practical recommendation is to select Modicon Compact, Modicon Quantum, Modicon Momentum. This is the most widely used container in field installations reading from generic Modbus TCP slaves, software simulators, and RTUs. The class name does not have to match the actual vendor — it only selects the address translation and framing rules used by the WinCC channel DLL.

Step-by-Step Configuration of the Modbus TCP/IP Channel

1. Add the Channel

1. Open WinCC Explorer.
2. Right-click Tag Management and select Add New Driver.
3. Choose Modbus TCPIP.chn from the driver list. A new channel node ModbusTCPIP appears under Tag Management.

2. Create a Connection

1. Right-click the ModbusTCPIP channel node and select New Connection.
2. Open the connection Properties dialog.
3. Set the parameters:
   • IP Address: target slave IPv4 address (e.g. 192.168.1.50).
   • Port: 502 unless the slave listens on a non-standard port.
   • PLC Class: select Modicon Compact / Quantum / Momentum for third-party slaves (see Strategy section).
   • Station Address (Unit ID): 1-255, default 0 or 1 depending on firmware revision.
   • Cycle / Update time: typical 1000 ms; tune according to scan budget.

3. Define Tags

Tags are added under the connection node. The address format is what trips up most engineers coming from a non-Modbus background. The WinCC Modbus driver uses a numeric address only — the function code prefix (4x, 3x, 0x, 1x) is implied by the data type / address block of the tag, not entered explicitly.

4. Verify with a Software Modbus Slave First

Before pointing the channel at the real PLC, install a software Modbus TCP slave on the engineering station. The slave's request log shows exactly which FC and which register the WinCC driver is trying to read. This is the fastest way to debug an address-mapping problem:

1. Start a software Modbus slave (e.g. Modbus Tools, diagslave, Modbus Slave by WinTech).
2. Configure it to listen on 0.0.0.0:502.
3. In WinCC Tag Management, set the connection IP to 127.0.0.1.
4. Enable the channel and watch the slave's request log. Each WinCC tag generates a request; confirm:
   • Function code matches the tag type (FC03 for holding, FC04 for input).
   • Register address matches the slave's expected base + offset.
   • Unit ID matches.
5. Once the round-trip works against the simulator, change the connection IP to the real PLC IP and reload the project.

Tag Addressing Worked Examples

If a tag request is rejected with an "Illegal Data Address" exception (Modbus exception code 02), the offset is wrong. If the channel logs a connection error or timeout, the IP, port, or unit ID is wrong.

Verification and Diagnostics

After the channel is enabled, validate communication using the following checks:

1. WinCC Channel Diagnosis: open the channel's diagnostic dialog and confirm "Connection Established" and "OK" status for each tag. Any tag with a quality of bad or uncertain indicates either a wrong address or a non-responsive slave.
2. Tag Simulator: in the tag properties, enable the simulator and force a known value. Verify the read-back is correct end-to-end.
3. Channel trace: enable Modbus TCP channel logging (via ModbusTCPIP.log in the WinCC diagnostics directory) to capture raw request/response frames.
4. Wireshark capture: capture TCP/502 traffic from the WinCC station; confirm MBAP header, function code, and exception codes. This is the definitive way to spot a slave that is silently dropping requests or returning a corrupted payload.

OPC Bridge Alternative for Stubborn Slaves

The native WinCC Modbus driver is intentionally thin. When the target slave:

• Uses a non-standard function code not supported by the driver,
• Requires a custom Unit ID behavior,
• Uses signed/unsigned byte-swapping that the driver cannot reorder,
• Sits behind a gateway that needs a specific handshake,

the field-proven alternative is to insert a Modbus TCP OPC server between the slave and WinCC. WinCC ships with an OPC DA client channel; the OPC server handles the Modbus-side quirks and exposes standard DA items that WinCC consumes without modification.

Workflow:

1. Install a third-party Modbus OPC server (commercial options include Kepware, Matrikon, Softing; low-cost options include the Lectus Modbus OPC Server, which is widely used in this role for non-Modicon slaves).
2. Configure the OPC server with the slave's IP, port, and unit ID. Map each register to a DA item, applying any byte/word swapping rules.
3. In WinCC, add the OPC channel driver (OPC.chn).
4. Browse the OPC server's namespace from inside WinCC and bind tags to the DA items.
5. Verify the same way as the native driver (diagnostic dialog, tag simulator, channel trace).

This indirection solves a class of problems that the native Modbus TCP driver cannot, because the OPC server can be configured with much more granular control over polling, exception handling, and data type conversion. It also makes future migrations easier: swapping out the physical PLC does not require touching the WinCC side, only the OPC server's device configuration.

Field-Validated Reference Examples

Troubleshooting Matrix

Performance and Scan Budget Considerations

Each WinCC Modbus tag configured with a fast update time generates an individual request (or a grouped request if tags are in the same address range and the driver groups them). For a non-Modicon PLC, treat the channel as a "best-effort" master and apply these rules:

• Group tags into logical scan groups with matched update times (e.g. fast 250 ms for alarms, slow 2000 ms for measurements).
• Avoid mixing FC01/FC02/FC03/FC04 in a single tight group — most third-party slaves handle mixed FC traffic more slowly than segregated polling.
• If the slave supports a larger PDU, request blocks of registers rather than single registers to reduce request overhead.
• Use a dedicated NIC on the WinCC station for SCADA traffic if the station is also a workstation.

Limitations of the Native Driver and When to Migrate to OPC

Siemens documentation and field experience converge on a clear set of limits. Migrate from the native WinCC Modbus TCP driver to an OPC bridge when any of the following apply:

• The slave requires a non-standard function code (e.g. FC23 for read/write multiple registers with custom semantics).
• The slave uses a proprietary byte or word order that the driver's "Word Swap" / "Byte Swap" settings cannot accommodate.
• You need redundancy (active/passive or active/active Modbus masters) — the native driver is single-master.
• You need a Modbus serial or Modbus RTU over TCP encapsulation that the native driver does not expose.
• You want to expose the same Modbus data to multiple SCADA clients (WinCC, Historian, MES) without duplicating the driver configuration.

For everything else — a non-Modicon PLC that speaks standard Modbus TCP/FC03 and FC16 — the native driver is sufficient and is the recommended first attempt. Most non-Schneider PLCs in this category connect successfully on the first try once the addressing rule is applied.