CP340 Serial Communication with S7-300: Complete Setup Guide

Overview

The Siemens CP 340 communication processor turns an S7-300 CPU into a serial master or slave over RS 232C, 20 mA (TTY), or RS 422/485. The module sits in the central rack next to the CPU and exposes a logical base address to the STEP 7 program. Three integrated drivers — ASCII, 3964(R), and RK512 — let one module cover point-to-point printers, barcode scanners, scales, drives, weigh indicators, and similar field devices. The CP 340 is the entry-level PtP module for S7-300; the CP 341, CP 440, and CP 441 expand capability (loadable drivers, quantity structures, RK512 on industrial protocols), but the CP 340 is the right choice when ASCII telegrams with a few tens of bytes per cycle are sufficient and the budget is constrained.

This article walks through commissioning a CP 340 next to an S7-315-2DP or S7-314C-2DP, starting with hardware configuration in HW Config, the ASCII driver parameter set, the P_SEND and P_RCV function block calls, the data-block layout, and a field-proven troubleshooting matrix that covers the most common commissioning issues — including the classic "DBB32 keeps changing on every keystroke" behavior, the need for telegram framing, and the Modbus-versus-ASCII error-checking question raised when the first signs of bit corruption appear in a live machine.

CP 340 Hardware Variants and Order Numbers

The CP 340 is sold as three sub-models, each with a different physical interface. The STEP 7 hardware catalog entry differs accordingly, so the order number must be matched before HW Config will accept the slot.

All three variants use the same STEP 7 FB interface (P_SEND, P_RCV, P_PRINT) and the same HW Config parameter dialog. The only difference is the front-panel connector and the electrical driver. The RS 422/485 variant is software-selectable between 4-wire full-duplex and 2-wire half-duplex; in 2-wire mode the transmitter is automatically disabled during reception, so collisions are avoided when the bus discipline is polled-response.

Current-draw and slot constraints: the CP 340 draws 5 V / 360 mA from the backplane and occupies one slot. There are no buffer restrictions on the rack position, but the logical base address must be set inside the I/O address range (default 256..287 for slot 4, adjustable). Keep at least one slot between the CP 340 and any high-speed digital input module to avoid timing jitter on short telegrams.

Prerequisites

1. STEP 7 V5.5 SP4 (or higher) installed on the engineering PC. TIA Portal does not configure the CP 340 — use the classic STEP 7 HW Config for the S7-300 family. The CP 340 manual is available on Siemens Industry Online Support.
2. CPU 31x in the central rack (S7-312C through S7-319-3 PN/DP). The CP 340 is a PtP module, not a PROFIBUS slave, and does not require a DP master on the same station.
3. RS 232C null-modem cable (DB9 female-to-female, pins 2↔3 crossed, 4↔5↔6 bridged, 7↔8 bridged) for a PC-to-CP 340 loopback. For RS 485, a 2-wire twisted pair with 120 Ω termination at each end.
4. A spare instance DB for the P_SEND and P_RCV blocks (one DB per FB call) plus a working DB holding the actual telegram data.
5. A terminal program on the PC (Hyperterminal, PuTTY, or Docklight) for round-trip testing before the field device is connected.

Step 1: Hardware Configuration in HW Config

Open the SIMATIC 300 station in HW Config. Drag the CP 340 from the hardware catalog (path: SIMATIC 300 > CP-300 > PtP) into the slot next to the CPU. Double-click the module to open the properties dialog. On the Addresses tab, set the logical base address — the same address that the LADDR input of P_SEND and P_RCV will reference (W#16#100 is a common choice for slot 4, but STEP 7 auto-assigns 256 by default).

On the PtP Parameters tab, choose the driver:

• ASCII — for printable-character protocols, polled weigh indicators, scanners, simple instruments, modems in AT command mode.
• 3964(R) — for Siemens-native handshake to S5/S7 peers and drives that implement 3964R.
• RK512 — for layer-7 RK512 block transfer.

Click Properties next to the driver selection to open the interface definition. Save and compile the station, then download the hardware configuration to the CPU. The CP 340 only becomes active after the parameterized data record has been received from the CPU on startup; if a CP 340 is hot-swapped or its parameters are changed online, a STOP-RUN transition on the CPU (or a CP 340 power-cycle) is required to load the new parameters.

Step 2: ASCII Protocol Parameterization

The ASCII driver parameter screen is the same dialog whether the physical layer is RS 232, TTY, or RS 485. The dialog is divided into four sub-tabs: Interface, Character Delay / XON-XOFF, Data Flow Control, and Telegram / Receive Buffer. The first two tabs are mandatory; the others are application-specific.

Step 3: Creating the Send/Receive Data Blocks

Two DBs are required for the simplest configuration: one instance DB for each FB, and one working DB for the actual telegram payload. The P_SEND instance DB is created by STEP 7 when the FB is inserted; the same applies to P_RCV. The working DB can be a standard DB or a DB-of-CHAR-array, which is the strongly recommended pattern.

Recommended DB layout for receive:

DATA_BLOCK DB10
TITLE = Receive buffer for CP 340
VERSION : 0.1
  STRUCT
      RxBuf : ARRAY[1..256] OF CHAR;   // up to 256 characters
      RxLen : INT;                       // actual byte count, set by P_RCV
  END_STRUCT;
END_DATA_BLOCK

Declaring the receive area as ARRAY OF CHAR lets you view the buffer with a VAT in character format, which makes it trivial to verify that "STXPACR"-style telegrams are being framed correctly. Using BYTE arrays forces the engineer to mentally convert 0x50 0x41 0x0D into the letter string "PA<CR>" — a significant source of commissioning errors.

For the send side, an identically structured DB of CHAR values is recommended. The telegram to the weigh indicator in the source thread (<STX>PA<CR>, or for address 1 the byte sequence 02 50 41 0D) can be preloaded as default values so the program does not have to assemble the string at runtime.

Step 4: P_SEND Programming Example

The P_SEND FB (FB 2 in the standard CP 340 library) is the only sanctioned way to push a telegram out of the CP 340. Calling the underlying SFCs directly is unsupported and the module will not respond. The call signature for STEP 7 V5.5 is:

CALL "P_SEND" , "DB_P_SEND"
     REQ    :=#Send_Trigger      // BOOL, edge-triggered start pulse
     R      :=#Send_Abort         // BOOL, abort a pending transmission
     LADDR  :=#CP340_Addr         // WORD, logical base address from HW Config
     DB_NO  :=#Datablock          // INT,  number of the working DB
     DBB_NO :=#Send_Byte_Offset   // INT,  byte offset of the data in that DB
     LEN    :=#Send_n_Bytes       // INT,  number of bytes to send
     DONE   :=#Send_Done          // BOOL, request completed without error
     ERROR  :=#Send_Error         // BOOL, request completed with error
     STATUS :=#Send_Status;       // WORD, detailed result (see status table)

Operational rules:

• REQ must be a positive edge. A level-held REQ re-triggers the FB on every scan and overruns the FIFO — symptom is intermittent lost characters on the wire.
• LEN counts bytes, not characters. For "STX PA CR" set LEN = 4.
• DB_NO and DBB_NO are both required; CP 340 cannot read from a bit-mapped area, only from a byte-aligned DB starting at any offset.
• DONE and ERROR are mutually exclusive within one scan. If both come back false and STATUS is non-zero, the FB is still busy.

Step 5: P_RCV Programming Example

The P_RCV FB (FB 3) is the symmetric counterpart for incoming data. Set EN_R to TRUE for continuous reception, R to FALSE under normal conditions (a TRUE on R flushes the FIFO — use only on commissioning or protocol reset).

CALL FB 3 , DB23                  // P_RCV instance
     EN_R  :=M1.0                  // continuous receive enable
     R     :=M1.1                  // one-shot reset, normally FALSE
     LADDR :=MW21                  // CP 340 logical base address
     DB_NO :=MW60                  // receive working DB number
     DBB_NO:=MW62                  // receive byte offset in that DB
     NDR   :=M29.0                 // new data received this scan
     ERROR :=M29.1                 // receive error this scan
     LEN   :=MW64                  // actual bytes copied into the DB
     STATUS:=MW30;                 // detailed result code

EN_R = TRUE is the normal pattern for polled ASCII traffic. Setting EN_R = FALSE closes the receive window; setting R = TRUE clears any partially received telegram. LEN is the number of valid bytes the CPU should interpret, not the buffer size. Always re-initialize the receive buffer in the working DB on a R pulse; the CP 340 does not guarantee zero-padding of the trailing bytes.

Critical implementation note from field experience. The '#Send.Abort' and '#receive.Abort' inputs must both be cleared. A stranded abort bit prevents the FB from accepting a new REQ and the symptom is "first send works, subsequent sends hang with STATUS = 16#1E0F". Tie both abort bits to a single reset coil that is pulsed at startup and on any fatal error.

Step 6: Commissioning with Hyperterminal

1. Connect the CP 340 to the PC COM port with a null-modem cable. Power up the S7-300 station and ensure the CP 340 SF LED is off (solid green RDY indicates parameterized and ready).
2. On the PC, open Hyperterminal (or PuTTY serial) at the same baud rate, data bits, stop bits, and parity configured in HW Config. Disable any local echo on the PC side so the transmitted characters are not mixed with the local echo.
3. Trigger a P_SEND in the CPU (set REQ for one scan via a force table or a watch table). The expected ASCII string should appear on the Hyperterminal window. If the characters appear doubled (for example GERRYGERRYGERRY as reported in the source thread), the local echo on the PC is on, or the CP 340 is in a half-duplex mode where its own transmitter is being looped back. Disable the local echo on the terminal program first.
4. Type characters in Hyperterminal. The receive buffer in the CPU should populate. Monitor DB10.DBB32 (or the first byte of the RxBuf array) in a VAT in Character format. The displayed character should match the key pressed. If DBB32 changes on every keystroke as in the source case, the telegram is not being framed — proceed to the next section.
5. Once the round-trip works, replace the Hyperterminal with the real field device (laser length meter, weigh indicator, drive) and repeat the verification. Do not skip the Hyperterminal step; it isolates the PC, the cable, and the CP 340 as the three possible fault sources before adding the field device into the loop.

Telegram Framing Rules

The CP 340 ASCII driver closes a received telegram and posts NDR to the CPU on one of three events:

1. An end-of-text character (1 or 2) configured in the driver parameters is received. Up to two characters can be defined; both are stripped from the data buffer.
2. The configured end-of-receive timeout expires after the last character. The timeout is specified in milliseconds and is typically set to 4 character times. For 9600 8N1, one character time is ~1.04 ms, so a 4 ms timeout is the default.
3. The configured receive buffer is full. In this case, the telegram is posted immediately and any further incoming characters are buffered for the next P_RCV call (subject to FIFO overflow at 1024 bytes).

For polled ASCII indicators (the source thread case, <STX>PA<CR> for poll, response ending in <CR>), framing on CR is correct. For continuous-output instruments (laser length meter in the source thread), the meter has no terminator and the telegram is essentially the entire stream. In that case, the only working strategy is the end-of-receive timeout. If the timeout is set too short, characters are split across multiple P_RCV calls and the telegram must be reassembled in the CPU. If the timeout is set too long, the meter data appears delayed by one telegram length at the application layer.

Error Checking: ASCII vs. Modbus

Plain ASCII has no integrity check. A 4-character string PA<CR> corrupted by a single EMI-induced bit flip becomes any other 4-character string with the same probability — and the CPU will accept it. For non-critical displays this is acceptable; for any value that drives a downstream action (a shutdown on a temperature reading, a brake release on a weigh value, a setpoint change to a drive), plain ASCII is unsafe.

For a 5-indicator RS 485 bus where one wrong bit can command a frequency drive to ramp to 1000 °C, switch to Modbus ASCII or Modbus RTU. Modbus ASCII keeps the printable framing (so it is easy to debug in a terminal) and adds an LRC byte that catches every single-bit error. Modbus RTU is binary and more efficient but requires the loadable Modbus driver on a CP 341 or a custom CRC implementation in the CPU; the CP 340 can in principle do Modbus RTU but the strict 3.5-character inter-frame gap is hard to honor on a general-purpose ASCII driver.

Troubleshooting Matrix

Status Code Reference (Selected)

The full status code list is in the CP 340 manual available on Siemens Industry Online Support.

Verification

After commissioning, validate the link end-to-end with the following checklist:

1. CP 340 RDY LED solid green, SF LED off.
2. Send a known ASCII string from P_SEND and verify the byte count in LEN matches the expected telegram length. Hyperterminal should display the same string.
3. Trigger a P_RCV from the field device and verify NDR is set, LEN reflects the actual received length, and the RxBuf array contains the expected characters in CHAR view.
4. Toggle the abort bit and verify the next REQ on P_SEND is accepted (DONE within one scan, STATUS = 16#0000).
5. Power-cycle the S7-300 station and confirm the CP 340 re-parameterizes automatically (RDY LED green within 5 s of CPU RUN).
6. For RS 485 multi-drop: verify 120 Ω termination at both physical ends, shield grounded at one end only, and no more than 32 nodes on a single segment (CP 340 RS 485 driver limit).