CP341 ASCII Protocol Configuration: S7-300 Modbus TCP Setup

System Overview and Problem Statement

The referenced application is a railway Remote Terminal Unit (RTU) built on a Siemens S7-300 station. The S7-300 contains a CPU 315-2 PN/DP, digital input module SM321 (32x), digital output module SM322 (32x), and a point-to-point communication module CP341. The CP341 is wired over RS-232 to an end device called Ebilock 850 (an interlocking controller), and to a Relay Interlocking (RI) end device through a separate interface. Upstream, an external "RTUCI task" communicates with the S7-300 over Ethernet using Modbus TCP.

The engineering questions that drive this guide are:

1. Does the CP341 "ASCII driver" convert every binary byte (for example 0x67 0x89) into its printable ASCII representation (0x36 0x37 0x38 0x39), or does it transmit the raw byte stream?
2. Can the CPU 315-2 PN/DP's built-in PN interface run Modbus TCP at the same time as the CP341 runs an ASCII protocol toward Ebilock 850?
3. Can the same CPU maintain two distinct TCP connections from RTUCI (one to the Ebilock station object, one to the RI station object) using the same IP and different ports?
4. Are standard Modbus TCP ports such as 502 and 3050 suitable for distinguishing the two connections?

The remainder of this article documents the correct answers, the underlying S7-300 / CP341 mechanisms, and the recommended STEP 7 V5.x configuration steps.

CP341 Hardware Variants and Order Numbers

The CP341 is a single-channel serial module for the S7-300 backplane. Three physical-interface variants are sold; they differ only at the sub-D connector and at the driver firmware loaded at parameterization time. The variants commonly referenced in field installations are:

Each variant is supplied with parameterization diskettes ("CP 341 Point-to-Point Communication, Parameter assignment"). The diskette must be installed once on the STEP 7 V5.x PG so that the CP341 properties dialog can be opened in HW Config. In the System Data area of HW Config, the CP341 occupies a 32-byte I/O area; the standard start address is 256 (decimal). The CP341's status and control bytes are mapped within that 32-byte window and are managed automatically by the CP341 communication FBs.

What the "ASCII Driver" Actually Does

Siemens uses the label "ASCII driver" for a free-form, character-transparent serial protocol on the CP341/CP340. It is not an ASCII-text converter. When the ASCII driver is selected with an 8-bit data frame, the CP341 transmits and receives any byte value from 0x00 through 0xFF without recoding it. The "ASCII" label refers to the framing model: characters are sent and received as a stream delimited by configurable end-of-frame conditions, in the same spirit as a generic terminal.

For a request such as 0x67 0x89, the CP341 puts exactly two bytes on the wire. The receiver observes 0x67 0x89, not the text representation "67 89" (which would be 0x36 0x37 0x20 0x38 0x39).

End-of-Frame Conditions for the ASCII Driver

Because the ASCII driver has no embedded length field, the end of a frame is detected by one or more of the following configurable conditions:

Siemens' official application note "CP340/CP341 Multi-Station polling based on ASCII driver protocol" lists a representative configuration for similar byte-oriented masters: 9600 bit/s, 8 data bits, no parity, character delay 4 ms. The same note documents the start address 256 (decimal) for the CP341 in HW Config and the use of P_RCV / P_SEND FBs with per-station instance DBs. Reference: Siemens Support Entry 88359826

Hardware Configuration in STEP 7 V5.x

1. Open the S7-300 station in SIMATIC Manager and launch HW Config.
2. Insert the CP341 at the desired slot. The S7-300 bus allows a CP341 in slots 4 through 11 of any rack (subject to power-budget rules). Confirm the start address (default 256 decimal); note the diagnostic address if interrupts are used.
3. Double-click the CP341 to open the Properties dialog. If the parameterization diskette is installed, the "Parameter Assignment" tab exposes the protocol selector.
4. Select the protocol: ASCII driver. Choose the physical interface matching the variant (RS-232, RS-422, or RS-485).
5. Set baud rate, data bits, parity, and stop bits to match the Ebilock 850. Common values: 9600 / 8 / N / 1 or 19200 / 8 / E / 1. If the protocol requires hardware handshake, enable RTS/CTS; otherwise disable to allow three-wire RS-232 (TxD, RxD, GND).
6. Set the end-of-frame condition. For Ebilock 850 use a character delay of 3-5 ms and, if the protocol uses a terminator, enter the 1- or 2-character terminator string.
7. Compile and download the hardware configuration. After download, the CP341 is in data-transfer mode; the selected protocol is stored persistently in the module's flash and is re-applied on every cold restart.

Send and Receive Function Blocks for the ASCII Driver

For the ASCII driver on CP341/CP340, the standard communication FBs in STEP 7 V5.x are:

Each call of P_SEND / P_RCV requires:

• An instance DB (one DB per logical link, in the user program; the CP341 does not occupy a DB itself).
• The module start address from HW Config (e.g. 256 / 0x100).
• A pointer to a source/destination buffer in the S7 data area (any DB, bit memory, or process I/O area).

Minimum FB call shape (illustrative):

// ASCII send (ST)
CALL "P_SEND" , DB_ASCII_SEND
  REQ     := TRUE            // edge-triggered
  LADDR   := 256             // CP341 start address
  DB_NO   := 100             // user DB containing payload
  DBB_NO  := 0               // start byte offset in DB 100
  LEN     := 2               // number of bytes
  DONE    := sendDone
  ERROR   := sendErr
  STATUS  := sendStatus;

// ASCII receive (ST)
CALL "P_RCV" , DB_ASCII_RCV
  EN_R    := TRUE            // cyclic enable
  LADDR   := 256
  DB_NO   := 110
  DBB_NO  := 0
  NDR     := rcvNew
  ERROR   := rcvErr
  STATUS  := rcvStatus
  LEN     := rcvLen;

For the binary payload 0x67 0x89, declare DB100 with two bytes, initialize them with B#16#67 and B#16#89, and call P_SEND with LEN := 2. The wire output is two raw bytes; no expansion to "6789" occurs.

Concurrent Modbus TCP on the CPU 315-2 PN/DP

The CPU 315-2 PN/DP integrates a PROFINET interface that supports open TCP/IP communication. With a Modbus TCP library loaded, the same interface can act as a Modbus TCP server (slave) toward the RTUCI task while the CP341 runs an ASCII protocol to Ebilock 850. The two protocol stacks are independent and time-multiplexed by the CPU's operating system; they do not contend for any shared resource because the PN interface and the CP341 are physically separate modules.

Siemens provides the library "Modbus TCP for S7-300/400" with order number 2XV9 450-1MB02. The library contains FBs for Modbus TCP client and server roles, plus a sample project. The library is delivered as a STEP 7 V5.x archive and installs into the S7 program as a master copy library.

Typical integration pattern:

1. Install the library, then copy the FB blocks and the UDTs to the S7 program.
2. Open NetPro and create a "TCP connection" to the RTUCI task IP address. Note the local and remote port numbers, and the automatically assigned connection ID (e.g. 1 for the Ebilock connection, 2 for the RI connection).
3. For each TCP connection, instantiate one copy of the Modbus TCP client or server FB into its own instance DB. The library uses separate instance DBs to keep the connection state independent.
4. Map the relevant Modbus registers to the user data that is also exchanged with the Ebilock 850 station object through the CP341 ASCII channel.

Multiple TCP Connections on the Same CPU IP Address

The S7-300 PN stack supports multiple concurrent TCP connections to the same peer IP address, distinguished by the port tuple. A TCP socket is uniquely identified by the 5-tuple {protocol, src IP, src port, dst IP, dst port}. If the RTUCI task opens one socket to the S7 CPU on port 502 and a second socket to the same IP on port 3050, the operating system dispatches the data to two independent connection structures in the S7.

To realize this in the S7 program, the user must instantiate the Modbus TCP FB twice and assign each instance its own connection ID and instance DB. The library "Modbus/TCP for S7-300/400" (2XV9 450-1MB02) is designed for exactly this use case; the documentation explicitly supports the use of different port numbers and connection IDs for parallel communications.

Port Number Selection: 502 and 3050

Port 502 is the IANA-assigned Modbus TCP port. Using port 502 for the connection to the Ebilock station object is the standard choice and is recognized by every Modbus diagnostic tool, including the Modbus Poll client, the Modbus Scanner utility, and Wireshark's Modbus dissector (registered on TCP/502). Port 3050 is in the user/private range; it is not a standard Modbus TCP port but is acceptable for a non-standard secondary service, provided both endpoints agree on the port.

Recommended mapping for this RTU:

The RTUCI task must open two sockets: one to 192.168.10.20:502 and one to 192.168.10.20:3050. Inside the S7 program the two Modbus TCP server FBs listen on their assigned local ports and write to independent data blocks. Application code can route requests to the Ebilock 850 ASCII channel (CP341) by reading/writing DB200, and to the RI channel by reading/writing DB201. There is no cross-talk because each FB instance owns its connection state.

Data Flow and Protocol Boundaries

The end-to-end data path for a typical Ebilock 850 request becomes:

1. RTUCI task writes a Modbus TCP request to S7 CPU on port 502.
2. The Modbus TCP server FB (instance DB200) decodes the PDU and exposes the function code and register payload in the user DB.
3. S7 user code maps the requested Modbus register(s) into a CP341 ASCII frame. The user code is responsible for the Ebilock 850 application protocol (any register-to-byte conversion, any byte-level CRC, any sequence numbering).
4. P_SEND hands the frame to the CP341. The CP341 transmits the raw bytes to Ebilock 850 over RS-232.
5. Ebilock 850 returns a response frame. P_RCV collects it, and the S7 user code parses the bytes back into Modbus register values.
6. The Modbus TCP server FB replies to the RTUCI task with the corresponding Modbus PDU.

The RI station object follows the same path on connection 2 / port 3050 / instance DB201, with the RI's own serial protocol over a separate CP341 or a second point-to-point module.

Configuration Checklist

Verification and Diagnostics

1. Wire capture. Use a serial tap (e.g. an RS-232 line monitor or a logic analyzer on a break-out) to confirm that the bytes transmitted by the CP341 match the bytes written by P_SEND. For 0x67 0x89 the scope must show exactly two bytes, not five.
2. CP341 diagnostics. Open the CP341 online in HW Config or use the "CP341 - Diagnostics" tool from the parameterization diskette. Check the diagnostic buffer for framing errors, overrun, or parity errors.
3. Modbus TCP round-trip. From the RTUCI host, run a Modbus client against port 502 (Ebilock) and port 3050 (RI) and read a known register that mirrors a status flag. Verify that the value matches the value written to the Ebilock 850 input registers.
4. Wireshark verification. Capture traffic on the PROFINET segment and apply the Modbus dissector (it auto-detects port 502). For port 3050, add a decode-as rule mapping TCP/3050 to the Modbus dissector. Each connection must show independent TCP streams with independent transaction IDs.
5. Connection budget. In NetPro, confirm that the two Modbus connections are listed in the connection table and that the connection state of each toggles to "established" once the RTUCI task opens the socket.

Troubleshooting Matrix

Notes on Parallel Protocol Stacks

The CP341 and the integrated PN interface are independent. The ASCII driver on CP341 is a character-transparent, half-duplex, byte-oriented protocol with no dependence on the Ethernet side. The Modbus TCP library on the PN interface uses the standard open IE communication FBs (BSEND/BRECV, SEND/RECV, or USEND/URCV underneath, depending on the library version) to manage TCP socket state. There is no shared state between the two stacks, so failures on one do not propagate to the other.

If the S7-300 needs to serve a third protocol on Ethernet, a CP343-1 Lean or CP343-1 Advanced can be added to extend the connection budget beyond the 16-connection limit of the integrated PN. The Modbus TCP library supports the CP343-1 as well as the integrated PN interface, so porting to an external CP requires only a NetPro change, not a code change.

Standards and References

• Siemens Support Entry 88359826 — CP340/CP341 Multi-Station Polling Based on ASCII Driver Protocol
• Modbus TCP library 2XV9 450-1MB02 — Modbus/TCP for S7-300/400 (Siemens product page, included with the library CD)
• IANA Service Name and Transport Protocol Port Number Registry — port 502 reserved for Modbus