Resolving P_SND_RK Status 16#0000 on Siemens CP341 Modbus Master

Problem Overview

The CP 341 communications processor (6ES7 341-1AH02-0AE0 and related variants) is deployed as a Modbus Master on a CPU 317-2 PN/DP (firmware V3.x). The user program in OB1 calls the PtP-Data Link block pair P_SND_RK (FB 8) and P_RCV_RK (FB 9) for each request. After copying a working project from a second PLC and downloading it into the first PLC, P_SND_RK ceases to produce any feedback. Specifically:

• The DONE, ERROR, and STATUS outputs of P_SND_RK remain at their initial values.
• No CP 341 LEDs (red SF, green RXD, green TXD) flicker during a triggered request.
• STATUS holds at 16#0000 instead of returning a status word such as 16#0001 (job running), 16#7000 (no job in process), or error code 16#80xx.
• The Modbus Master never transmits a request frame on the line.
• Other CP 341-equipped PLCs running the same logic operate correctly.

Because the same program logic functions on identical hardware in sister stations, the failure is project-specific, not hardware-specific. The defect sits in the interaction between the user program, the CP 341 load memory, and the STEP 7 instance DB layout.

Root Cause Analysis

Three overlapping mechanisms have been observed to leave P_SND_RK silent with STATUS = 16#0000. Each must be ruled out in turn because the symptom is identical from the user's standpoint.

Cause 1: Stalled Instance Data Block After Online-to-Online Copy

When STEP 7 transfers the program from a running CPU back to engineering and the project is then re-downloaded into a different PLC, the static instance data of P_SND_RK and P_RCV_RK ships as well. If a previous REQ edge left the block with a pending job or with intermediate enable flags set, the new controller inherits that state. Until the existing job either completes, times out on the CP 341, or the instance memory is cleared, subsequent REQ edges are ignored. The block appears dead even though internally it is still waiting on the prior request.

Symptom: DONE = FALSE, ERROR = FALSE, STATUS = 16#0000 on every call.

Cause 2: Multi-Instance DB Corruption After Block Re-Wiring

The original implementation used multi-instance capability inside a parent FB. The author then converted the call to a single instance with a dedicated DB. Re-downloading the parent FB does not automatically delete the now-orphaned multi-instance fragment. STEP 7 may inherit conflicting startup initialization parameters, especially the internal SEND_DB and RCV_DB pointers expected by the RK 512 driver layer. With the wrong internal pointers, the CP 341 firmware refuses the request before any line activity and the block returns an empty status.

Cause 3: Edge-Trigger Violation on REQ

P_SND_RK, per the Siemens manual on P_SND_RK: Send data with RK 512, requires a positive edge at the REQ input to latch a new job. A level-true REQ is treated as a single-shot trigger on the rising edge only. If OB1 is executing the block faster than the CP 341 firmware can acknowledge (cycle time below the CP turnaround), or if the program's edge-detection logic was lost during the copy, the block can latch an internal "busy" state without ever returning a status. This is the most common fault when the same sequence logic was used in the sister stations but the local run-time is different.

Cause 4: Call-Frequency Limit Per CP

According to the Siemens manual entry on P_SND_RK, each CP 341 supports exactly one outstanding RK 512 send job and one outstanding receive job. Multiple P_SND_RK calls sharing one CP must be sequenced; the REQ inputs cannot be asserted simultaneously. The OB1 cycle must contain only one call to P_SND_RK per CP; nested or repeated calls within the same OB scan queue up internally and silently.

Pre-Diagnostic: Verify CP 341 Configuration

Before troubleshooting code, confirm the CP 341 is healthy.

1. Open STEP 7 (Classic) > HW Config and double-click the CP 341 in the S7-300 station.
2. Select Properties > Interface > Parameter Assignment and verify the protocol selection matches the load memory on the module: RK 512 (ASCII 3964R), Modbus Master, or Modbus Slave. A mismatch where the project says Modbus Master but the CP is loaded with RK 512 firmware (or vice versa) produces a silent STATUS = 16#0000 without a diagnostic buffer entry.
3. Confirm the baud rate, parity, and stop bits match the connected device on the RS-485 or RS-232 interface (default Modbus Master is 19200, 8E1 for PTP parameter set 0 of the Modbus firmware).
4. Open SIMATIC Manager > CP 341 > Diagnostic Buffer. Look for event IDs 0x131 (parameter assignment error), 0x137 (firmware/parameter mismatch), and 0x141 (frame abort). A clean buffer is normal; a populated buffer is the answer.
5. Open the CP 341 online diagnostics (right-click > Module State). "Diagnostic status: OK" must display. If not, address the hardware fault first.

Diagnostic Procedure (Decision Tree)

Solution 1: Regenerate the Instance DBs

When a project is sourced from another PLC, always rebuild the instance DBs rather than reuse them. The DB retention guarantee only applies to retentive symbols, and the static portion of P_SND_RK is non-retentive but absolutely required to initialize the CP handshake.

1. In SIMATIC Manager, right-click the program blocks and choose Generate S7 Blocks > Compile and Download Objects.
2. Delete the existing instance DBs for P_SND_RK and P_RCV_RK via the CPU's online interface (CPU > Delete / Reset > Delete Blocks) only after confirming no other logic depends on them.
3. Perform a full download (OB, FBs, all DBs, and system data). STEP 7 Classic must report Download successful for the system data group; partial downloads leave the CP 341 parameterization in an indeterminate state.
4. Stop the CPU, power-cycle the S7-300 rack to force CP 341 firmware reload, then run a single test request.

If you use a multi-instance parent FB, recompile the parent to regenerate the nested instance area, then download the parent FB and its parent instance DB together.

Solution 2: Verify Edge-Triggered REQ

Replace any direct boolean assignment to REQ with a rising-edge detector. The simplest implementation:

FUNCTION_BLOCK FB_ModbusMaster
VAR
    SendPulse : BOOL;
    SendEdge  : BOOL;
    LastSend  : BOOL;
    Watchdog  : TON;
END_VAR

// 5-second request watchdog
Watchdog(IN := SendEdge, PT := T#5S);

// Rising-edge detector
IF SendPulse AND NOT LastSend THEN
    SendEdge := TRUE;
ELSE
    SendEdge := FALSE;
END_IF;

// Hand the edge to P_SND_RK
P_SND_RK.REQ := SendEdge;
LastSend := SendPulse;
P_SND_RK(...);

The pattern guarantees exactly one job per request lifecycle. After DONE or ERROR asserts or the watchdog expires, the calling sequence logic must clear REQ and reset SendEdge before the next request is enabled.

Solution 3: Enforce One P_SND_RK Call Per CP Per OB1

If your application scans two Modbus slaves, instantiate a state machine in OB 1 and only enable one P_SND_RK call at a time:

If both P_SND_RK calls are inside the same parent FB, the second call must be guarded by the first call's BUSY = FALSE. Sharing the CP's RK 512 resource concurrently without arbitration is the canonical deadlock source for STATUS = 16#0000.

Solution 4: Diagnose STATUS 16#0000 Mapping

The STATUS word returned by P_SND_RK mirrors the response from the CP 341 firmware. A persistent 16#0000 indicates no error event reached the block and no job is currently executing. According to the STATUS parameter documentation, the documentation cites that 16#0000 in a fault scenario instructs the engineer to inspect the transmission parameters and the partner configuration. The reference table below summarizes the codes most useful during field commissioning:

Solution 5: Validate the Physical Layer

Because STATUS = 16#0000 suggests no completion event has been received, physical-layer problems can also produce the symptom on commissioning.

1. Verify the RS-485 termination resistors are present at both line ends (typically 120 Ω) and absent in the middle of the daisy chain.
2. Confirm shield grounding at one end only to avoid ground loops.
3. Measure DC common-mode voltage between CP 341 signal ground and Modbus slave ground; values above ±7 V damage the CP 341 driver.
4. Capture the line with a serial analyzer (e.g., a USB-RS485 dongle at the CP side) to confirm no bytes leave the CP during a request. If nothing transmits, the issue is software or CP firmware, not cabling.

Verification Procedure

After applying any of the solutions above, commission the station with this fixed sequence.

1. From a watch table, force the REQ edge only once on a single P_SND_RK instance and clear it immediately.
2. Read the block outputs:
   • DONE must pulse to TRUE within the Modbus transaction timeout (default 3 s).
   • ERROR must remain FALSE on a healthy read.
   • STATUS must transition through 16#0001 (accepted) → 16#7000 (idle) on completion.
   • The CP 341 TXD LED must flicker once per request.
3. Re-run the multi-slave sequence logic and watch the done-counter increment one increment per cycle.
4. Replay the diagnostic buffer. It should record job acceptance and completion events only, no entry pointing to "uninitialized instance DB" or "protocol mismatch".

Preventive Checklist

• Always rebuild instance DBs after a project is copied from another station.
• Use single instance with dedicated DBs for P_SND_RK and P_RCV_RK unless multi-instance is essential to the architecture.
• Single source for the request watchdog; reuse TON with parameter PT = T#5S.
• Document the maximum OB 1 cycle time at which P_SND_RK still releases the CP between scans. As a rule, the OB 1 cycle must remain below 0.6 × the Modbus turnaround deadline.
• Pin the CP 341 firmware load record in the project version control so the protocol selections cannot silently drift between stations.

Field Notes from Multi-Station Deployment

When a fleet of PLCs shares one project source, the symptom typically appears only on the first station to be re-flashed. Sister stations are unaffected because their instance DBs are healthy. Performing a fleet-wide roll-out on the same evening with the same pre-compiled download ensures all CP 341 instances are identical. Conversely, copying the program block only between stations without resetting the instance DBs produces a class of "first-station-dies" faults that look like hardware failures but are purely a download hygiene problem. Programming the watchdog to 5 s is a deliberate trade-off: too short (< 1 s) trips on transient line noise; too long (> 10 s) hides real Modbus failures. The 5 s value tracks well with a 19200 baud Modbus read of up to 32 registers with retries.

Frequently Asked Questions