Siemens CP340 P_SEND Troubleshooting: CPU317 RS422 No Output

1. Problem Description

A Siemens S7-300 CPU 317-2 PN/DP is wired to a CP 340 communications processor in RS422 mode (X27 interface, MLFB 6ES7340-1BH02-0AE0 or compatible). The user program calls P_SEND (FB 2 from the Standard Library > Communication Blocks > CP PtP) to transmit 40 bytes from DB10 starting at byte offset 0. The CP 340's Tx LED blinks approximately every second, but the receiver end (PC running Hyperterminal through an RS422-to-RS232 converter) shows no characters at all. STATUS returned to the call is non-error, DONE toggles, and no SF/UF is reported on the CPU. This combination - blinking TX indicator with zero remote reception - is one of the most common CP 340 commissioning failures in the field.

The remainder of this document walks through every plausible root cause for that symptom stack, then provides a deterministic diagnostic procedure and a verification checklist that resolves it in under an hour on a typical commissioning bench.

2. CP 340 Module Variants and MLFB Identification

Before any troubleshooting, confirm the exact CP 340 order number (MLFB). The CP 340 ships in three interface variants and three hardware revisions; mixing them up is the first source of configuration errors. The full hardware manual is available from Siemens Industry Online Support - CP 340 PtP Manual.

The product record for the RS232 variant is published under Siemens Support entry 6ES7340-1AH02-0AE0; the same product family tree contains the RS422 (1BH02) and TTY (1CH02) variants and their respective approval documents. Confirm the MLFB printed on the front panel matches the catalog number in HW Config; an -0AE0 versus -0BA0 revision mismatch changes the firmware and the default baud-rate table.

3. P_SEND Block Parameters and Logical Address

P_SEND is FB 2 in the CP PtP library. Its I/O interface is documented in the CP 340 manual and in the FBD/ST interface description that ships with the library. The block is non-blocking: a single call schedules a send job, and the block can be re-called with the same instance while a previous job is still active. The instance DB is multi-instance capable.

The original code in the field report uses LADDR := 256. In an S7-300, 256 decimal (= 0x100 hex) is a valid logical address slot for a CP 340 if and only if that value was assigned in HW Config > CP 340 Properties > Addresses. The default STEP 7 placement uses sequential free addresses, so 256 may or may not be correct for a given rack. Always cross-check by opening HW Config > CP 340 > Properties > Addresses and reading the input-start address. The address is set in the hardware configuration of Siemens STEP 7 (TIA Portal or classic SIMATIC Manager) and downloaded with the hardware configuration.

4. Root Cause Analysis - Why P_SEND Sends Nothing

The Tx LED pulse combined with zero remote reception has six statistically dominant causes in fielded installations. They should be eliminated in the order shown, top to bottom, because the top items cost seconds to verify and the bottom items can cost hours.

Cause #1 (the RS422-to-RS232 converter) is the resolution found in the source report after the trigger and DB layout hypotheses were ruled out. The remaining sections give each cause a full diagnostic recipe.

5. Trigger Logic Pitfall - The #breq Anti-Pattern

The original call uses a TEMP variable #breq to drive REQ:

AN    #breq        // read inverted value of #breq
NOT                // invert the RLO
NOT                // invert again - net effect: assign TRUE to #breq
=     #breq        // writes TRUE back to #breq
CALL  "P_SEND", "DB_P_SEND"
REQ   :=#breq

This construct is self-destructive. The two NOT instructions cancel each other and the result of AN #breq is assigned back into #breq. After the first scan, #breq is TRUE; on the next scan, AN #breq evaluates to FALSE, then the two NOTs invert to TRUE again - so REQ is held permanently high, which P_SEND does not interpret as a trigger event. P_SEND latches a job on the rising edge of REQ. A level-held REQ after the first cycle produces no further jobs and may leave the original job in an undefined state.

If #breq is a TEMP (declared in the FB's TEMP area), its value is undefined at first scan because the block's instance DB has not been initialised. AN #breq reads random bits; the behaviour changes with every download. This is the second independent defect in the same block.

// Clock generator (use a free flag bit, e.g. M100.0)
AN    M100.0       // closed contact when M100.0 is 0
L     S5T#2S       // 2-second time value
SD    T100         // start retentive on-delay timer
A     T100         // pick up the timer's running bit
=     M100.0       // toggle the flag, producing 0.5 Hz oscillation

// P_SEND call
CALL  "P_SEND", "DB_P_SEND"
REQ   :=M100.0      // rising edge every 2 s
R     :=FALSE       // never reset
LADDR :=256
DB_NO :=10
DBB_NO:=0
LEN    :=40
DONE   :=M101.0
ERROR  :=M101.1
STATUS :=MW102

6. RS422-to-RS232 Converter Verification

CP 340 RS422 mode uses the X27 15-pin Sub-D connector. The electrical interface is differential, full-duplex, with separate transmit and receive pairs. A passive DB9 cable cannot bridge it to a PC's RS232 port - an active converter is mandatory, and the converter must support the configured baud rate, parity, and flow control.

The differential pair convention is T(A)/T(B) is the CP 340's transmitted pair and R(A)/R(B) is the CP 340's received pair. The pinout depends on the converter's standard; many industrial converters follow the Siemens convention where A is positive and B is negative on each pair. Cross-cabling pin 4 to pin 11 and pin 5 to pin 13 on the converter side defeats the purpose and is a common bench-mistake.

Use an oscilloscope or a logic analyser on the X27 pins 4/5 during a transmission. If 3964R is configured and the protocol state machine is healthy, you will see:

1. The CP 340 drives the line low on T(A) for the STX character (0x02).
2. The receiver acknowledges by driving T(A) low again (DLE 0x10).
3. The CP 340 transmits the user data bytes.
4. The CP 340 transmits ETX (0x03) followed by the BCC byte.
5. The receiver drives T(A) low again as final acknowledgement (DLE).

If the X27 pair is silent, the issue is the CP 340 itself or its configuration. If the X27 pair is active but nothing appears at the PC end, the converter or the PC cable is the problem. The fielded solution that closed the original ticket was to replace the RS422-to-RS232 converter. Converters are a frequent single point of failure: cheap units have insufficient drive strength for industrial cable lengths, lose biasing resistors over time, and have no diagnostic LEDs to indicate health.

7. Protocol Selection - 3964R vs ASCII

The CP 340 supports several protocols selectable in HW Config under CP 340 Properties > Protocol. The choice between them changes the framing and the behaviour of P_SEND.

The original ticket specifies the 3964R protocol. In 3964R, the receiver must also speak 3964R for the handshake to complete. A passive ASCII listener (such as Hyperterminal in raw 8-bit mode) will not respond with the required DLE acknowledgement, so the CP 340 will eventually time out and abort. STATUS in that case is typically 0912h (timeout waiting for DLE) after the configured character delay (default 220 ms in the protocol parameters).

For initial bench verification, switch the CP 340 to ASCII driver at 9600 baud, 8 data bits, no parity, 1 stop bit (8/N/1). P_SEND will then place raw bytes on the wire and Hyperterminal will display them. This isolates whether the lower physical layer is functional without bringing the 3964R state machine into the picture. Once ASCII works, switch back to 3964R and pair the receiver with a counterpart that also runs 3964R (another CP 340, a CP 341, a Siemens drive, or a third-party protocol converter).

8. DB Layout and Data Type Mismatches

The original code declares DB10 as a DWORD and starts sending at DBB_NO := 0. Because the source DB is a DWORD, LEN := 40 will read 40 bytes starting at byte 0, including any padding bytes or any pre-existing data above the first four bytes. This is fine from P_SEND's perspective provided that:

1. The data area is initialised with valid bytes.
2. No STRING data type occupies the first two bytes, because STRING reserves byte 0 for the maximum length and byte 1 for the current length. Sending a string with DBB_NO := 0 sends the two length bytes first, which is rarely what the user intends.

Verify the contents of DB10 online by opening it in STEP 7 with Monitor / Modify. The bytes at offset 0..39 should match the characters you expect to see on Hyperterminal. If DB10 contains all zeros, the receiver will see 40 NUL characters, which Hyperterminal may render as blanks or as nothing at all.

9. STATUS Word Decoding

The STATUS output of P_SEND follows the CP PtP library conventions. Knowing how to interpret it shortens diagnosis considerably. The most common values observed during bench commissioning:

The CP 340 manual appendices list every documented STATUS value with the corresponding remedy. The full list is in the CP 340 PtP Manual. Capture STATUS into a flag word (e.g. MW102 in the example above) and watch it in VAT during commissioning - this single change usually localises the fault.

10. Diagnostic and Verification Procedure

Follow the sequence below end-to-end. Each step has a deterministic pass/fail criterion so you can stop at the first failure.

1. Confirm MLFB and revision. Read the front-panel MLFB of the CP 340. Match against the HW Config catalog entry. Mismatched -0AE0 / -0BA0 revisions behave differently in firmware.
2. Check SF LED. If SF is on, open PLC > Module Information on the CP 340 and read the diagnostic buffer. Resolve configuration mismatch before proceeding.
3. Replace the trigger with the one-shot pattern from Section 5. Remove #breq and all NOTs. Use M100.0 toggled by T100 at S5T#2S. Download the block.
4. Switch to ASCII protocol at 9600/8/N/1 in HW Config. Save and recompile, then download the hardware configuration to the CPU.
5. Confirm LADDR in HW Config. Open CP 340 Properties > Addresses. Note the input start address. Set LADDR in P_SEND to the same value (256 in the example).
6. Verify DB10 contents online. Open DB10 in Monitor. Confirm bytes 0..39 contain the expected characters (e.g. ASCII HELLO WORLD followed by padding).
7. Force REQ and watch STATUS. In VAT, set M100.0 to FALSE, then TRUE. Observe M101.0 (DONE) and MW102 (STATUS). A healthy system pulses DONE every 2 seconds with STATUS = 0001h on completion.
8. Scope the X27 pins. Probe pins 4 and 5 (T(A)/T(B)) and pins 11 and 13 (R(A)/R(B)) with a differential probe. Verify the transmit pair toggles during the active window. If it does not, the CP 340 is not transmitting - re-check LADDR and protocol parameters.
9. Verify the converter. Replace the RS422-to-RS232 converter with a known-good unit (Phoenix Contact PSI-MODEM-CONV, MOXA TCC-80, or similar industrial converter with documented RS422 support). Verify converter power and configuration switches (if any) match the baud rate.
10. Switch back to 3964R. Once ASCII passes end-to-end, change the CP 340 protocol back to 3964R. Pair the receiver with a 3964R-capable partner (another CP 340 or a CP 341 in a second rack) and verify handshaking completes.
11. Capture and archive. Save the final ST program, HW Config, and the DB10 initial values in the project archive. Record the converter part number and serial in the cabinet documentation.

11. Verification Checklist

Before closing the ticket, walk this list top-to-bottom. Each item is binary; the system is not ready to ship until all boxes are ticked.