Configuring Siemens CP-340/341 ASCII Protocol Communication

1. Overview

The Siemens CP 340 and CP 341 communication processors are point-to-point (PtP) modules used in S7-300 stations to exchange serial data with field devices such as barcode scanners, weigh scales, RFID readers, printers, and radio data terminals. Both modules support the ASCII driver, a transparent character-oriented transmission scheme suitable for any partner device that streams printable characters terminated by a user-defined end delimiter.

Unlike 3964(R), the ASCII driver does not implement any handshake or block-checking protocol of its own. It is therefore ideal for simple unidirectional or half-duplex links where the partner device is the bus master and the CP module responds on request. This article walks through the entire configuration chain — from selecting the correct hardware variant to commissioning a working ASCII link in STEP 7 — and finishes with a troubleshooting matrix and a multi-station polling note referenced from Siemens' official knowledge base.

2. CP 340 vs. CP 341 — Hardware Selection

Before configuration, identify which module is installed. Both share the same physical footprint and STEP 7 integration, but they differ in protocol flexibility:

The two physical interfaces matter for wiring:

• RS-232C (AH variant): point-to-point only, full-duplex, max. 19.2 kbit/s (CP 340) or 115.2 kbit/s (CP 341). Handshake lines RTS/CTS, DTR/DSR, DCD available.
• RS-422/485 (BH variant): two-wire or four-wire, half- or full-duplex. RS-485 supports multi-drop networks when used with multi-station polling (see CP340/CP341 multi-station polling based on ASCII driver protocol).

3. Prerequisites

1. STEP 7 V5.x (SP2 or later recommended) — the CP 340/341 is configured via HW Config and parameterised with the supplied CP PtP library. TIA Portal supports both modules through HSPs but the workflow is essentially identical.
2. CP PtP parameter assignment tool — installed as part of STEP 7 (or the TIA Portal "PtP" option package). The tool generates the parameter data block and exports the FBs P_SEND, P_RCV, P_PRINT, and (CP 341) P_INIT.
3. Partner device protocol description — baud rate, parity, data bits, stop bits, end-of-frame delimiter, and any flow-control expectations. Without this, ASCII frames cannot be parsed correctly.
4. Wiring hardware — shielded serial cable, correct pinout for the CP variant, and a termination resistor (220 Ω) if the bus is RS-485.
5. Firmware order numbers for the loadable drivers if using a CP 341 with the Modbus RTU driver; for the ASCII driver alone, no licence is required.

4. Understanding the ASCII Driver

The ASCII driver is intentionally minimal. It performs four functions:

1. Framing — every byte received or transmitted is treated as a printable 7- or 8-bit character. No STX/ETX, length field, or CRC is inserted by the CP.
2. End-of-frame detection — a user-defined one- or two-character sequence marks the end of a message. Default is CR (0D); typical with PCs and barcode scanners is CR+LF (0D0A). The CP strips the end code on reception (option) and appends it on transmission.
3. Buffering — the CP contains an internal ring buffer (up to 1024 bytes depending on firmware). The user program reads or fills this buffer through the FBs.
4. Flow control (optional) — XON/XOFF (11/13) or hardware handshake using RTS/CTS. Either is selectable in HW Config.

Because the driver is unframed, the application program is fully responsible for parsing message structure (address, command, data, checksum) if any is required. For RFID/RDT, scale, or scanner applications this is rarely an issue: the partner device produces a self-delimited ASCII string per transaction.

5. Hardware Configuration in STEP 7

1. Open the S7-300 station in HW Config and slot the CP 340/341 into a free slot (typical slot 4 for the first CP). The module is found under SIMATIC 300 > CP-300 > PtP.
2. Double-click the module to open Properties — CP 340/341.
3. In the Addresses tab, note the I/O address range. The default diagnostic address is FFFF (no diagnostics); recommended is to assign a real address such as 272 and enable Diagnostics interrupt.
4. Switch to the Basic Parameters tab and select ASCII driver as the protocol. (Selecting 3964 or 3964R disables ASCII — only one protocol is active per CP.)
5. Open the Protocol Parameters sub-dialog. The fields are described in the next section.
6. Save and compile the station. STEP 7 will then prompt you to call the CP PtP parameter assignment tool — do this immediately.

6. Parameter Assignment for the ASCII Driver

Open the CP PtP parameter assignment tool. It generates a DB (e.g. DB100 "CP340_DB") containing the runtime parameters. Edit the following values:

7. Communication Function Blocks (P_SEND / P_RCV)

After saving the parameter DB, the CP PtP tool links the standard PtP library into your S7 program. The relevant blocks for ASCII transmission are:

All blocks use a background DB (the instance DB) that the CP PtP tool pre-wires to the CP's logical address. The block interfaces are standardised across CP 340 and CP 341.

8. Data Block Design

User data is held in a normal global DB, structured as a STRING or an ARRAY of BYTE. The STRING form is preferred for ASCII data because STEP 7 automatically manages the length byte:

DATA_BLOCK "DB_ASCII_MSG"
  STRUCT
    sOut : STRING[80];   // "STATUS:READY\r\n"
    sIn  : STRING[80];   // populated by P_RCV
    iLen : INT;          // actual received length
  END_STRUCT
END_DATA_BLOCK

When passing sOut to P_SEND, supply the address as P#DB_ASCII_MSG.sOut with length DB_ASCII_MSG.sOut.LEN. Avoid passing the maximum declared length (80) — that fills the bus with trailing 00 bytes. Always send only the populated portion.

9. Sample ST / LAD Code

ST — send a command on a positive edge of a push-button:

IF "START_SEND" THEN
  "DB_ASCII_MSG".sOut := 'ACK';
  "DB_ASCII_MSG".sOut.LEN := 3;     // important: update length
  "P_SEND_DB"(REQ   := TRUE,
              LADDR := 272,
              DB_NO := 100,         // parameter DB
              DBNO  := W#16#0,      // not used in ASCII
              LEN   := "DB_ASCII_MSG".sOut.LEN,
              BUFFER:= P#"DB_ASCII_MSG".sOut,
              DONE  := "sDONE",
              ERROR := "sERR",
              STATUS:= "sSTAT");
  "START_SEND" := FALSE;
END_IF;

LAD equivalent (cyclic call in OB1):

1. Place a normally-open contact labelled Send_Trigger.
2. On the rung, drop the P_SEND instance. Wire REQ to the contact, LADDR to the CP address, BUFFER and LEN to the data block, and wire the status outputs to flag words.
3. Use the DONE output to reset the trigger and the ERROR output to drive a fault indicator.
4. Drop a separate P_RCV call in OB1 with a fixed EN_R := TRUE. The FB will set DONE := TRUE and write the received length to LEN once a complete frame arrives.

10. Multi-Station Polling (CP 341 / RS-485)

When several ASCII devices share an RS-485 bus, the CP can be configured to poll each station in turn. Siemens' official application example walks through parameter assignment for the multi-station polling scheme:

"This document gives a specific example to introduce polling communication between multiple Siemens serial communication modules (CP340/CP341)."
CP340/CP341 multi-station polling based on ASCII driver protocol

For an RDT (radio data terminal) used as a single peer, multi-station polling is unnecessary and adds complexity. Use it only when the partner device expects a polled address byte and reply window.

11. Commissioning and Verification

1. Loop-back test: before connecting the partner, place a wire jumper between TX and RX on the CP side (pins 2–3 on a DB-9 for RS-232C; A ↔ A', B ↔ B' loop on RS-485). Run a P_SEND with a known string and confirm P_RCV returns the same string. This isolates the CP from the partner.
2. Diagnostic buffer check: open PLC > Diagnostic Buffer on the online station. Any CP startup or frame error will be recorded with a hex OB82 / OB1 entry (e.g. Communication error to module).
3. Frame monitor: enable the CP's trace in the parameter tool. The trace logs the last 256 bytes transmitted and received with timestamps.
4. Partner test: connect the field device and trigger a scan. Verify in the trace that the request matches the documented format and that the reply terminates with the configured delimiter.
5. Status word: if P_SEND.STATUS returns 0x0001 the request is in progress; 0x0000 DONE; 0x80xx parameter or sequence error. Cross-reference the CP 340 manual Appendix A for the full STATUS list.

12. Troubleshooting Matrix