Siemens CP341 Modbus Master/Slave Error 1E0F: Troubleshooting

1. Problem Overview: CP341 Modbus Master/Slave Error 1E0F

A SIMATIC S7-300 / S7-400 station using a CP341 point-to-point module with the Modbus Master/Slave library occasionally fails to bring the link up. The most common symptom reported in field service is the P_SND_RK_WORK_STATUS word of the FB7 Modbus master cycling between 0 and 7695 (hex 16#1E0F) every scan, with ERROR = 1. The TX LED never blinks, the RX LED never latches into the active state, and the slave never sees a valid request frame.

Error 1E0F is the Modbus master library's "parameter error in the send/receive function" indicator. It does not describe a Modbus protocol fault; it describes an internal disagreement between FB7 (MODBUS master), the underlying FC81 (P_SND_RK) send block, and the data buffer / parameter block they reference. In almost every CP341 service case the actual fault is one of three root causes:

• The send block was wired with R_TYP = D (data block) when the Modbus library expects R_TXP = X (no separate data block needed for some transfer modes) or vice-versa, with R_NO pointing to an empty / wrong DB.
• The CP341 was parameterized for RS422 4-wire full-duplex while the physical cable is RS485 2-wire half-duplex (or the parameterization tool left the interface in an incompatible mode).
• The application attempts to move > 256 bytes per Modbus transaction, exceeding the RTU maximum PDU size.

2. CP341 Hardware Variants and Modbus License

The CP341 is available in three interface variants. The Modbus Master/Slave library runs only on the RS485/422 variants and requires a separate license dongle (or activated license key on newer firmware).

Confirm the loaded module type in HW Config matches the physical card. A V.24 (RS232) CP341 can be mis-flagged as the 422/485 variant if the rack was rebuilt. The Modbus library refuses to load against an 1AH02 because the underlying point-to-point driver is 3964(R) ASCII-only.

3. Modbus Library Block Architecture (FB7 / FB80 / FC81 / FC82)

The Modbus Master/Slave library consists of two control FBs, two protocol FBs, and two I/O FBs. They are normally called from OB1 or a cyclic interrupt OB on the S7-300 / S7-400 CPU.

The send and receive FBs both expose a P_SND_RK_WORK_STATUS (a WORD) and an ERROR (a BOOL). On success, WORK_STATUS = 0 and ERROR = 0. The instant WORK_STATUS shows a non-zero value and ERROR is high, the send request was rejected before it reached the CP341.

Typical master call skeleton in OB1:

// Network 3 - copy request data into Modbus send DB
     L     DB_REQ.Number_Of_Registers
     T     DB_MODBUS.REQ_LEN
     CALL  FB    7, DB_MODBUS_MASTER          // MODBUS master
      LADDR    := 256                          // logical CP341 address
      DB_NO    := 100                          // Modbus data DB
      ...
// Network 4 - send
     CALL  FC   81, DB_SND                    // P_SND_RK
      R_TYP    := 'D'                          // <-- WRONG - see section 5
      R_NO     :=                              // <-- empty
      ...
// Network 5 - receive
     CALL  FC   82, DB_RCV                    // P_RCV_RK
      ...

4. Decoding Error 1E0F (7695) in P_SND_RK_WORK_STATUS

The P_SND_RK_WORK_STATUS word is not a CP341 driver error - it is the Modbus library's interpretation of the lower CP status. The relevant codes for error 1E0F:

The diagnosis path that almost always applies to a cycling 1E0F is to read the raw SFC status from P_SND_RK_DATA.SFCSTATUS inside the instance DB of FC81. That value, regardless of the wrapper's WORK_STATUS, points at the underlying CP341 driver fault (resource allocation, wrong protocol class, or hardware diagnostic).

5. R_TYP versus R_TXP Parameter Mismatch

The single most common reason for a CP341 Modbus master to cycle on 1E0F is wiring the FC81 call incorrectly. The send block has the following relevant formal parameters:

The combination R_TYP = D + R_NO = empty is logically incoherent: the library is told "the data is in a data block" but is not told which one. The library rejects the job and sets WORK_STATUS = 1E0F. The fix is to use R_TXP = TRUE when the Modbus library has already placed the frame in its instance DB and R_NO must be left blank, or to use R_TYP = 'D' with a valid R_NO.

Correct call for Modbus master / slave (the application holds the request in the FB instance):

     CALL  FC   81, DB_SND                    // P_SND_RK
      R_TYP    :=                              // leave blank
      R_TXP    := TRUE                         // data is in FB instance
      R_NO     :=                              // leave blank
      LADDR    := 256                          // CP341 logical address
      DB_NO    := 100                          // receive DB
      DBNO     := 100                          // redundant alias
      LEN      := W#16#0                       // length taken from FB
      RCV_TYP  := 'D'

Correct call when the application owns a separate request DB:

     CALL  FC   81, DB_SND
      R_TYP    := 'D'                          // data source = DB
      R_TXP    := FALSE
      R_NO     := 110                          // request DB number
      LADDR    := 256
      DB_NO    := 100                          // receive DB
      DBNO     := 100
      LEN      := 16                           // explicit length
      RCV_TYP  := 'D'

Mixing both modes produces 1E0F on the first send call.

6. RS422 4-Wire vs RS485 2-Wire Configuration

CP341 hardware variant 1BH02 and 1CH02 exposes an X27 front connector with the following relevant pins:

The CP341 parameterization tool (started from HW Config by right-clicking the CP341 -> "Object Properties" -> "Parameter Assignment" tab, or from the standalone "PTP Param" tool on the engineering station) has a radio button labelled "Interface" with two choices: RS422 (4-wire full-duplex) or RS485 (2-wire half-duplex). This selection is downloaded to the CP341 at STOP-to-RUN transition and is not editable online.

If the parameterization tool is set to RS422 and the bus is wired as 2-wire, the receiver's idle-state biasing network is wrong, the CP341 never sees a valid differential voltage on R(A)/R(B), and the RX LED stays dark. The send path still tries to drive T(A)/T(B), but because the parameterization does not match the cable the bus is electrically idle and the Modbus library aborts with 1E0F after one inter-frame timeout. The cable selected for Modbus must therefore be RS485 2-wire, with the parameterization tool set to the same.

7. Modbus Frame Size Limits (256-Byte Maximum PDU)

Modbus Application Protocol Specification v1.1b3 limits the Protocol Data Unit (PDU) to 253 bytes of payload. Adding the 1-byte slave address and the 2-byte CRC16 produces a maximum RTU frame of 256 bytes on the wire. The CP341 Modbus library enforces this on the master side and rejects any send request whose total length exceeds 253 bytes with status 1E0F on P_SND_RK_WORK_STATUS.

Attempting to send 400 bytes of register data - which a field application may reasonably do when reading a 200-register block - requires splitting into multiple FC03 (Read Holding Registers) or FC04 (Read Input Registers) requests, each ≤ 125 registers per Modbus convention. The Modbus master library has a parameter REQ_LEN at the request DB that must be set to the register count, not to the byte count. The library translates that count internally:

// Per-request register limit (Modbus spec, FC03/FC04):
     REQ_LEN := 125    // maximum registers per transaction
// Per-request byte limit:
     BYTES   := 250    // 125 regs * 2 bytes
// PDU size:
     PDU     := 1 (FC) + 1 (start addr hi) + 1 (start addr lo)
              + 1 (qty hi) + 1 (qty lo)
              + N * 2    // payload for FC03 / FC04
// Total RTU frame size:
     FRAME   := 1 (addr) + PDU + 2 (CRC) = 256 bytes max

When the application tries to dispatch a 400-byte single request, the master library raises 1E0F before the data is loaded into the CP341, which is exactly the observed behaviour.

Recommended workaround for large block reads is to issue a loop of up-to-125-register reads from the user program and concatenate them into the application DB. The CP341 can then handle each transaction inside the 256-byte limit.

8. Retrieving SFCSTATUS from P_SND_RK_DATA

The Modbus library does not pass the raw CP341 status code up through WORK_STATUS when the parameter stage fails. To get the underlying driver fault, open the instance DB of FC81 in STEP 7 / TIA and inspect the following UDT members:

A typical SFCSTATUS dump after a 1E0F error reveals:

• 0001 - length parameter ≤ 0: confirms R_LEN or R_NO not properly populated.
• 0008 - resource allocation failure: confirm CP341 is in RUN and the LADDR matches the slot.
• 001F - interface-specific driver error: look at CP341 diagnostic buffer.

Add a VAT or watch table that reads P_SND_RK_DATA.SFCSTATUS every cycle while troubleshooting; do not rely on WORK_STATUS alone.

9. RS485 Idle State Biasing and Cable Recommendations

RS485 receivers require the bus to be in a defined idle (mark) state when no driver is active. The convention is:

• R(A) / Data+ (CP341 pin 11) idle voltage = 0 V (relative to bus ground)
• R(B) / Data- (CP341 pin 14) idle voltage = +5 V (relative to bus ground)
• Equivalent differential: V(A) - V(B) = -5 V = logical "1" / idle

If the cable has no fail-safe bias (i.e. the bus floats), the CP341 RX line latches into indeterminate logic, the RX LED never lights, and the Modbus library's inter-frame timer expires. The result is again a 1E0F on the next send.

Recommended cable plant:

• Twisted pair, characteristic impedance 120 ohm, e.g. Belden 3106A or Lapp UNITRONIC BUS LD.
• Terminating resistor 120 ohm between A and B at each end of the segment only (master + farthest slave).
• Bias resistors: 680 ohm pull-up from +5V to B and 680 ohm pull-down from A to GND at one point on the bus (typically the master).
• Shield grounded at one end only.
• Maximum stub length ≤ 0.3 m from tap to device.

10. TX / RX LED Diagnostic Behavior

The two LEDs on the front of the CP341 (labelled "TXD" and "RXD") are essential first-line diagnostics:

11. Step-by-Step Troubleshooting Procedure

1. Place the CPU in STOP and verify the CP341 module type. In HW Config, confirm slot address and MLFB match the physical card. Wrong MLFB ("CP341 RS232" loaded where "CP341 RS485/422" is installed) is the most overlooked root cause.
2. Open the CP341 parameterization tool. Select Interface = RS485 (2-wire). Click "Protocol" -> "Modbus Master" or "Modbus Slave". Save and download to the CP341.
3. Inspect the CP341 diagnostic buffer. STEP 7 -> PLC -> Module Information -> Diagnostic Buffer. Entries such as "Parameter assignment error", "Wrong interface parameterization", or "Interface fault" pinpoint configuration issues.
4. Audit the FB7 (master) or FB80 (slave) call. Verify LADDR, DB_NO, and request DB length. Confirm request DB exists and is the correct length.
5. Audit the FC81 (P_SND_RK) call. Confirm the combination is one of:
   • R_TXP = TRUE, R_TYP and R_NO blank, OR
   • R_TXP = FALSE, R_TYP = 'D', R_NO = <valid DB number>
6. Check the requested transaction size. If REQ_LEN > 125 (registers) or implied byte length > 253, split into multiple transactions.
7. Wire the RS485 bus per the table in section 6. Use only X27 pins 11 and 14. Add terminating 120 ohm resistors at both ends. Add the bias network at the master.
8. Power the station and observe TX/RX LEDs. In RUN, the TX LED must blink on each request. If TX remains dark with WORK_STATUS = 0, the application is not calling FB7 or it is gated by a missing handshake.
9. Read P_SND_RK_DATA.SFCSTATUS on the next error and translate the code per section 8.
10. Use a Modbus scanner (e.g. a PC with pymodbus or CAS Modbus Scanner) on the same segment. If the scanner can talk to the slave but the CP341 cannot, the problem is between the CP341 and the bus, not the Modbus slave. If the scanner also fails, the problem is the slave.

12. Verification Checklist

Once the corrections are made, the following must all be true:

• CP341 diagnostic buffer reports no new entries after 5 minutes of cyclic Modbus traffic.
• TX LED blinks on every request from the application.
• RX LED blinks on every slave reply.
• P_SND_RK_WORK_STATUS = 0 and ERROR = 0 during normal operation.
• P_SND_RK_DATA.SFCSTATUS = 0 during normal operation.
• P_RCV_RK.RCV_COUNT increments by the expected length of each slave reply.
• Slave-side FB80 reports REQ_COUNT incrementing, no PRTCL_ERR set.
• Application read values are coherent with the actual slave data.
• Cyclic re-run for 1 hour produces zero error toggles in P_SND_RK_WORK_STATUS.

FAQ