S7-1500 ET200S 1SI Modbus FC03: Resolving LEN=8 Error 0E4A

Overview of the ET200S 1SI Modbus Communication Stack

The Siemens ET200S 1SI serial interface module (order number 6ES7 138-4DF11-0AB0) adds a Modbus RTU master or slave port to an S7-1500 CPU over PROFINET. The module handles the entire Modbus Application Data Unit (ADU) on behalf of the CPU: it builds the request frame, computes and appends the CRC-16 checksum, transmits the frame, receives the response, validates the response CRC-16, and returns the validated payload to the CPU. The CPU only has to supply the function code and the function-specific data bytes through the S_SEND instruction that ships with the Siemens Point-to-Point communication library for S7-1500.

Engineers familiar with the classic CP 340 / CP 341 / CP 440 / CP 441 point-to-point modules will recognise the same CPU-to-CP split, but the ET200S 1SI is unique in that it is parameterised entirely through the GSD file (or HSP) inside TIA Portal and reuses the standard S7 point-to-point library blocks S_SEND, S_RCV, S_STATUS, and S_XON / S_XOFF rather than the older USS / Modbus master FBs. This article clarifies the most frequent configuration error encountered with this module: the misuse of the LEN input of S_SEND. LEN counts bytes transferred from the CPU into the CP, not bytes transmitted on the serial line. The on-wire byte count is always higher because the module adds the slave address prefix (in master role) and the CRC-16 suffix automatically.

Hardware Identification and Firmware Constraints

The relevant module is the ET200S serial interface, order number 6ES7 138-4DF11-0AB0. The "-0AB0" suffix denotes the hardware release shipping with the current firmware revision at time of order. Always cross-check the firmware (FW) version visible in the device properties of TIA Portal (or in the diagnostic buffer of the IM 151) against the release notes for the GSD file installed in the project. Newer firmware revisions add additional protocol options, longer receive buffers, and updated error codes; older firmware revisions on the same hardware article number reject frame layouts that newer firmware accepts. Always confirm compatibility before upgrading the IM 151 firmware in a running plant.

For full electrical, mechanical, and diagnostic specifications, consult the Siemens "ET 200S Serial Interface Module" manual available from Siemens Industry Online Support by searching the order number.

Modbus FC03 Frame Specification and Byte Accounting

Modbus function code 03 ("Read Holding Registers") uses a fixed-size 8-byte request ADU on the RS-485 line regardless of slave vendor. The structure is:

Bytes 0 through 5 (the slave address, function code, two register bytes for the start address, and two register bytes for the quantity) are the bytes the user application must hand to the 1SI module. Bytes 6 and 7 are the CRC-16 little-endian checksum; the 1SI firmware computes them automatically from the preceding six bytes and appends them to the transmit shift register without involving the CPU.

The response ADU for FC03 varies with the quantity of registers requested: 1 byte slave address + 1 byte function code + 1 byte byte-count + 2×N register data bytes + 2 bytes CRC-16 = 5 + 2N bytes on the wire. Requesting 10 holding registers yields a 25-byte response. The 1SI module strips the slave address byte, validates the response CRC-16, and delivers only the function-code-through-byte-count payload to the CPU's S_RCV buffer (RD_i); the CRC-16 validation result is reported as a status bit, not as raw bytes.

The LEN Parameter: CPU-to-CP Payload, Not On-Wire Bytes

S_SEND has three inputs that are commonly confused:

LEN does not count the slave address byte or the CRC-16 in Modbus master mode because the 1SI firmware synthesises those endpoint bytes itself. The 1SI manual is explicit: the value placed into the LEN input corresponds to the bytes the application must prepare in the SD_i buffer, which for FC03 equals six bytes. The "6-byte form" mentioned in the manual is therefore the user payload, not the on-wire frame.

A common engineering mistake is to size LEN to match the number of bytes the engineer expects to see on an oscilloscope or Modbus sniffer. That convention is correct only for protocol layers where the application builds the entire ADU (for example, transparent ASCII with manual CRC appended). In Modbus master mode on the 1SI it is incorrect, and the CP rejects oversized payloads with status code 0E4A.

S_SEND Instruction and Status Code 0E4A

When LEN=8 is supplied for a Modbus FC03 request, S_SEND returns error 0E4A (hexadecimal). The CP firmware interprets this as a parameter violation: the application is attempting to ship more payload bytes than the Modbus PDU for the selected function code permits. The error originates inside the CP, not in the CPU; the CPU-side STATUS word reflects the CP-to-CPU error mapping. The actual root cause is the LEN value, not a wiring, baud-rate, or timing problem. Replacing the cable, changing parity, or extending the response timeout will not resolve 0E4A.

For the complete error-code list refer to the diagnostics section of the Siemens "ET 200S Serial Interface Module" manual at Siemens Industry Online Support.

CRC-16 Generation by the 1SI Firmware

The 1SI module uses the Modbus-standard CRC-16: polynomial 0xA001 (the reflected representation of 0x8005), initial value 0xFFFF, no final XOR, no reflection of output (input reflection only). The CRC is calculated over every byte preceding the checksum field, beginning with the slave address. The two resulting bytes are transmitted low-byte first, then high-byte. This is the same CRC used by every Modbus RTU device worldwide; the algorithm is documented in section 6.2.2 of the Modbus Application Protocol Specification V1.1b3 published by the Modbus Organisation.

Because the CRC is computed inside the 1SI firmware, the CPU never sees the two checksum bytes and never has to allocate buffer space for them. Manual calculation by the user is unnecessary and would in fact produce a doubly-CRC'd frame that no slave would accept. The same applies to the ASCII protocol variant, where the 1SI firmware adds the LRC byte automatically.

Building the Correct FC03 Request Buffer

The application code must populate the SD_i buffer with the six FC03 bytes in the order shown below. Example: read 10 holding registers from slave address 1 starting at register 0x0000.

// S7-1500 SCL example for FC03 read of 10 holding registers from slave 1
"iDB_Serial".SD[1] := 16#01;   // Slave address
"iDB_Serial".SD[2] := 16#03;   // Function code 03
"iDB_Serial".SD[3] := 16#00;   // Start address high
"iDB_Serial".SD[4] := 16#00;   // Start address low
"iDB_Serial".SD[5] := 16#00;   // Quantity high
"iDB_Serial".SD[6] := 16#0A;   // Quantity low (10 registers)
"iDB_Serial".LEN   := 6;       // CPU-to-CP payload length (NOT wire length)
"iDB_Serial".REQ   := TRUE;    // Trigger on rising edge

The buffer offsets depend on the SD_i data block layout declared when the S_SEND multi-instance DB is generated. The offsets in the example assume SD[1] is the first byte handed to the CP; in many library versions SD[1] starts at offset zero. Verify the offsets in the DB declaration generated by TIA Portal under "Program blocks > System blocks > [Instance DB] > SD_i".

Modbus exception codes the slave may return in RD_i[2] when the request is rejected:

Configuring the 1SI Module in TIA Portal

1. Open the ET200S station in the device view of TIA Portal and insert the 6ES7 138-4DF11-0AB0 module into a free slot of the IM 151.
2. Open the module properties and select the protocol "Modbus master (RTU)" for the chosen sub-module.
3. Set the baud rate, parity, and stop bits to match the slave exactly. Any mismatch produces framing errors (0E81) or response timeouts (0E90).
4. Configure the response timeout. Recommended initial value: 2000 ms; adjust per the worst-case slave turnaround time including its own scan cycle.
5. Configure the inter-frame pause. Default 3.5 character times is correct for most baud rates. For 19200 bit/s and above, the firmware enforces the 3.5-character delimiter automatically; for sub-9600 baud rates verify the pause is at least 3.5 character times.
6. Assign the sub-module identifier and slot according to the GSD file requirements.
7. Compile the hardware configuration and download to the IM 151.
8. Call S_SEND in a cyclic OB (typically OB1) and pair it with S_RCV in the same OB or a higher-priority OB depending on traffic volume.
9. Use a clock-bit OB (or a timer) to pace the S_SEND requests; the slave needs time to process each request before the next one arrives.

Diagnostic Block (S_RCV / S_STATUS) for Verification

Pair every S_SEND call with an S_RCV call on the same logical connection. S_RCV places the response payload into the RD_i buffer and returns a STATUS that decodes the CP-side diagnostics. The most useful STATUS values for verifying a successful FC03 exchange:

If S_RCV never fires (DONE stays FALSE for the configured timeout), the most likely cause is that S_SEND itself never accepted the job: revisit LEN, the SD_i offsets, and the protocol parameterisation in TIA Portal.

Troubleshooting Matrix

RS-485 Wiring Notes Specific to the 1SI Module

The 6ES7 138-4DF11-0AB0 uses a sub-D connector on the front; pin assignments vary by sub-module. For RS-485 2-wire, the relevant signals are pin 2 (T(R)T) and pin 7 (T(R)T-) in 4-wire mode; for 2-wire mode pins 8 and 9 carry the data. Always cross-check the wiring diagram printed on the inside of the sub-module cover and the table in the Siemens manual. Common field faults include A/B swapped (which manifests as 0E85 break errors or zero-byte responses), shield grounded at both ends (which produces circulating currents and intermittent CRC errors), and missing failsafe bias resistors on a multi-drop bus.

Field Verification Procedure

1. Connect an oscilloscope or Modbus sniffer to the RS-485 A/B lines. A simple USB-RS485 adapter running a tool such as the Siemens Modbus TCP/RTU scanner or a generic Modbus poll utility works well.
2. Trigger S_SEND with LEN=6 and confirm the sniffer captures exactly 8 bytes: 01 03 00 00 00 0A plus a 2-byte CRC-16. The CRC-16 for this specific request is C5CD (little-endian on the wire: CD C5).
3. Verify the CRC-16 in the captured frame using an off-line calculator. The polynomial 0xA001 over the six payload bytes must yield the captured CRC.
4. Observe the slave's response: 01 03 14 followed by 20 register data bytes plus a 2-byte CRC-16. Total length 25 bytes.
5. In TIA Portal, place a watch on the RD_i buffer and confirm RD_i[1] equals 0x03 (function code echo), RD_i[2] equals 0x14 (byte count, 20), and the subsequent bytes match the slave's known register contents.
6. Force a deliberate error: set LEN=7 and verify that S_SEND reports 0E4A. This confirms the error path is exercised and that the test fixture is healthy.
7. Revert LEN to 6 and capture the long-term CRC error count from the CP diagnostics. A non-zero count indicates a physical-layer issue rather than a configuration issue.
8. Stress-test by sending 1000 requests at 50 ms intervals; verify no buffer overruns, no timeouts, and no CRC errors. Sustained errors at high rates point to slave latency rather than master configuration.

Alternative Controllers and Module Variants

The same LEN-vs-on-wire-byte distinction applies to other Siemens point-to-point modules that implement Modbus master: the CP 341 (6ES7 341-1xH0x-0AE0), CP 441-2 (6ES7 441-2AA0x-0AE0), and the newer CM PtP (6ES7 540-1AA0x-0AA0) for S7-1500. On all of them, LEN counts only the application-supplied payload; the Modbus framing and CRC are handled by the protocol firmware. Engineers migrating code between these modules should verify LEN values per module because the maximum allowed payload differs: CP 341 accepts up to 1024 bytes per call, CP 441 up to 4096, CM PtP up to 8192.

For non-Siemens Modbus masters (e.g. third-party PLCs, embedded microcontrollers), the convention is the opposite: LEN or its equivalent must include the slave address and the CRC, because those masters typically run a "raw Modbus" stack where the application owns the entire ADU. When porting code from such a master to the ET200S 1SI, subtract 3 from LEN (one byte address, two bytes CRC) to obtain the equivalent CPU payload size.

Frequently Asked Questions