Configuring ModSim Modbus TCP Simulation with S7-1200 MB_CLIENT

1. Overview

Modbus TCP simulation in the S7-1200 ecosystem is the standard pre-commissioning step for validating a Modbus client application before connecting to a real field device. A typical engineering workflow uses a Windows-based Modbus server simulator such as ModSim from Win-Tech Software or Modbus Slave from ModbusTools to emulate a remote device, while the S7-1214C DC/DC/DC runs the MB_CLIENT instruction under TIA Portal to read holding registers, read discrete inputs, and write coils.

This reference covers the exact configuration required to:

• Stand up a ModSim TCP server with 6 coils, 1 discrete input, and 7 floating-point holding registers.
• Configure the S7-1200 MB_CLIENT instruction in TIA Portal V17 or later.
• Resolve the two most common field issues:
  1. Optimized vs. non-optimized data block access for coils and discrete inputs.
  2. Byte-order (endianness) differences between Modbus register payloads and bit-packed S7 tags.
• Run more than one MB_CLIENT connection to the same server IP using different local/remote ports.

2. Prerequisites

3. ModSim TCP Server Configuration

ModSim exposes up to 100 simulated slave devices and supports Modbus RTU, ASCII, and TCP. For the S7-1200 use case we run ModSim in Modbus/TCP server mode, listening on port 502.

1. Install and start ModSim.
2. Select Connection → Connect → Modbus/TCP/IP Server.
3. Set the local TCP port to 502 (default Modbus TCP port).
4. Set the Device ID (Unit Identifier / Slave Address) to 1 unless the application requires a different slave number.
5. Configure the data blocks to match the application:

4. S7-1200 MB_CLIENT Instruction

The MB_CLIENT instruction handles a single TCP connection to a Modbus server. Place one instance per Modbus server (or per port on a shared server). The instruction sits in Program blocks > System blocks > Program resources.

4.1 Instance DB and Static Parameters

Drop MB_CLIENT into a cyclic OB (typically OB1). TIA Portal creates an instance data block automatically. The relevant input parameters are:

4.2 Status / Error Codes

The output DONE, BUSY, and ERROR bits indicate the job state. The STATUS word is filled with a hex value on completion. Common values to watch for in a ModSim test environment:

5. Optimized vs. Non-Optimized Data Block

This is the single most common source of confusion in the S7-1200 Modbus TCP workflow. The behavior observed in the field — coils and discrete inputs only accessible with an optimized DB — is the documented contract of the MB_CLIENT instruction.

5.1 Why Coils and Discrete Inputs Require an Optimized DB

The TIA Portal documentation for MB_CLIENT states explicitly:

"For the MB_DATA_PTR parameter, the data block used must be a global data block with optimized access. The number of bits addressed must be divisible by 8."

Two reasons drive this:

1. Bit-packing into bytes. A coil request for <8 bits would need to be combined with neighbouring bits to align on a byte boundary. With a non-optimized DB the offset of any tag is the absolute byte address the engineer specified, which can place a 6-bit coil field in the middle of a byte. The instruction packs the request into a 16-bit Modbus word internally, so it writes back only the relevant 8 bits; the residual bits in the destination byte are read as zero and then the instruction is forced to perform a read-modify-write on the DB — which is not supported against non-optimized symbolic tags in older firmware.
2. Symbolic consistency check. With optimized access, the compiler knows the symbolic width of every tag and the run-time system can perform the bit-to-byte mapping deterministically. With standard (non-optimized) access, the bit field is interpreted as an absolute address, and the library returns 0x8382 for bit-pointer jobs.

5.2 Recommended DB Layout

Create a single global DB named Modbus_Data with Optimized block access enabled (Properties > Attributes > Optimized block access = checked). The internal layout that consistently works for the application in question:

DATA_BLOCK "Modbus_Data"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
  STRUCT
    // Coils (FC 01 / 05 / 15), 6 bits packed in the first byte
    Coils : BYTE;          // bits 0..5 = coil 0..5
    Reserved1 : BYTE;      // pad to 16-bit alignment
    // Discrete inputs (FC 02), 1 bit
    DiscreteInputs : BYTE; // bit 0 = DI 0
    Reserved2 : BYTE;      // pad to 16-bit alignment
    // Holding registers (FC 03 / 06 / 16), 7 floats = 14 words
    HR_Word_0  : WORD;     // Float 0 low word
    HR_Word_1  : WORD;     // Float 0 high word
    HR_Word_2  : WORD;     // Float 1 low word
    HR_Word_3  : WORD;     // Float 1 high word
    ...
    HR_Word_13 : WORD;     // Float 6 high word
  END_STRUCT;
END_DATA_BLOCK

Three separate MB_CLIENT calls reference three different offsets in the same DB:

• MB_DATA_PTR := "Modbus_Data".Coils, MB_DATA_LEN := 8 (padded to byte boundary)
• MB_DATA_PTR := "Modbus_Data".DiscreteInputs, MB_DATA_LEN := 8
• MB_DATA_PTR := "Modbus_Data".HR_Word_0, MB_DATA_LEN := 14

6. Modbus Data Types, Endianness, and Byte Swapping

The second field issue is the apparent byte-order difference between holding-register floats and the bit-packed coil/DI area. The explanation is that the two requests use different Modbus function codes and have different contract semantics.

6.1 Function-Code Map

6.2 Why the Float "Looks Big-Endian" and Coils "Look Little-Endian"

Both observations are correct and the two are not contradictory — they describe different data granularities:

1. Holding registers (FC 03). The Modbus specification requires a 16-bit register, and the wire format places the high byte first (big-endian at the byte level). For a 32-bit IEEE-754 float occupying two consecutive registers, the standard network byte order is: high-word high-byte, high-word low-byte, low-word high-byte, low-word low-byte. When this stream is loaded into a Siemens REAL tag by MB_CLIENT, the library concatenates the two 16-bit words and presents the value to the S7-1200 in the format the CPU expects.
2. Coils / discrete inputs (FC 01, FC 02). The unit on the wire is a bit. Modbus packs up to 8 bits per byte in the response payload, and within each byte the LSB of the byte carries coil 0 (or DI 0), the next bit carries coil 1, and so on. There is no "endianness" in the float sense; this is a bit-position convention. When the S7-1200 unpacks the response into the optimized DB, the bit at Coils.%X0 is the first bit of the first byte — which is what the application sees as "little-endian at the bit level".

6.3 Practical Example

For the value 23.5 (IEEE-754 single = 0x41BC0000) at HR address 0/1:

For coil 0 = TRUE, coil 1 = FALSE, coil 2 = TRUE, coil 3..5 = FALSE at coil address 0:

The CPU tag "Modbus_Data".Coils.%X0 reads TRUE, %X1 reads FALSE, %X2 reads TRUE, matching the wire format.

6.4 If You Need Different Bit Order

ModSim exposes a Sim swap dialog (under the Sim menu) that lets the test engineer mirror coil bytes or register words for regression testing when a real field device has a non-standard layout. This does not change Modbus semantics; it changes only how ModSim displays and stores the values locally. On the S7-1200 side, if a target bit must be inverted, do it in user logic rather than in the wire mapping:

// Mirror coils 0..5 from LSB to MSB for a legacy field device
FOR i := 0 TO 5 DO
  "ProcessData".CoilOut[i] := "Modbus_Data".Coils.%X(5 - i);
END_FOR;

7. Multiple MB_CLIENT Connections to One Server

The MB_CLIENT help text states: "For each 'MB_CLIENT' connection, a unique server IP address must be specified." This wording is misleading. The actual contract is that each instance must open a unique TCP connection, identified by the 5-tuple of (server IP, server port, client IP, client port, protocol). Modbus TCP servers typically accept many TCP connections per IP, distinguished by the remote port of the client (which is assigned dynamically by the S7-1200 Ethernet stack).

7.1 Three Connections to One ModSim Server

To run three MB_CLIENT instances against the same ModSim IP (192.168.0.10) on different Modbus function sets, simply place three MB_CLIENT blocks with three separate instance DBs. Each gets a different IP_PORT if ModSim is configured for multiple listening ports (ModSim allows up to four TCP server instances per window through the Connection → Connect menu):

All three can be issued from the same ModSim window on the same port 502 because the S7-1200 opens three distinct TCP sockets (different local ports). ModSim sees them as three independent masters and dispatches PDUs to the corresponding data block based on function code.

7.2 Alternative: Multiple Ports on One Server

Some PC applications (ModSim, Modbus Slave, ModRSsim2) can bind to several ports. The configuration file for ModRSsim2, for example, lets you expose the same data on port 502 and 1502. Splitting work across ports makes Wireshark traces easier to read when multiple masters talk to one server.

8. Step-by-Step Commissioning Procedure

1. Verify CPU firmware. In TIA Portal, Online → Accessible devices, read the order number and firmware. Confirm V4.0 or higher.
2. Bring ModSim online. Start ModSim, configure three blocks (6 coils, 1 DI, 7 floats) and Connection → Connect → Modbus/TCP/IP Server. Confirm "Listening on 0.0.0.0:502" in the status bar.
3. Compile and download the TIA project. Include the Modbus TCP library if not part of the standard distribution.
4. Watch the status word. First job returns 0x7001 (in progress), then 0x0000 on success. If the status is 0x80C8, the TCP connection failed — check the PC firewall and IP reachability with ping 192.168.0.10 from the CPU's Web server or an HMI diagnostic page.
5. Force a coil in ModSim (coil 0 = TRUE) and verify the S7-1200 tag Modbus_Data.Coils.%X0 updates on the next read cycle.
6. Write a float to HR 0 in the S7-1200 (e.g. Modbus_Data.HR_Word_0 := 16#41BC and HR_Word_1 := 16#0000 for 23.5) and confirm the value appears in ModSim's holding register display.
7. Watch the byte order in ModSim: with the value 23.5, ModSim should display 0x41BC, 0x0000 as two consecutive 16-bit registers.
8. Cycle the connection by toggling DISCONNECT = 1, then = 0. The status should return to 0x0000 within a few scans.

9. Verification Checklist

10. Troubleshooting Matrix

11. Field-Proven Caveats

• ModSim32 vs ModSim. Win-Tech's ModSim is the free MDI application. ModSim32 is a more recent build with extended support for multi-port TCP/IP servers and binary register views. For complex test benches prefer ModSim32.
• Watchdog on long polls. If the S7-1200 is busy or the project is large, the MB_CLIENT may time out (default ~5 s). Increase the TIME_OUT parameter and shorten the cycle to keep below the timeout.
• Port 502 requires admin on Windows. Only the first application to bind port 502 succeeds; subsequent applications must use a different port. If the S7-1200 shows 0x80C4, the local port for that instance is already in use.
• Endianness of "REAL" tags. The S7-1200 stores REAL in standard IEEE-754 single-precision, big-endian at the byte level. The Modbus wire format is also big-endian per register. The combined layout is big-endian at the byte level but big-endian at the word level too, which is why many engineers observe "big-endian on the wire". The library handles the mapping automatically; do not insert manual SWAP operations on the S7 side.
• ModSim documentation link. For additional point types and connection modes refer to the Win-Tech ModSim product page and the Advantech IAG FAQ on ModSim usage for the canonical Configuration → Connect → Modbus/TCP sequence.

12. FAQ