IM151-8 PN/DP to S7-300: Configuring PUT/GET PROFINET

IM151-8 CPU PN/DP to S7-300 PN/DP: Resolving AG_SEND Status 8093 with PUT/GET over PROFINET

This technical reference documents the field-validated procedure for establishing PROFINET I/O data exchange between a SIMATIC ET 200S IM151-8 CPU PN/DP (order number 6ES7151-8AB01-0AB0, firmware V3.x) and a SIMATIC S7-300 CPU 315-2 PN/DP (6ES7315-2EH14-0AB0). The original failure mode is well documented: the IM151-8 enters SF (System Fault), the diagnostic buffer logs an I/O access error, reading event, and FC5 AG_SEND returns status 0x8093 with DONE=0, ERROR=1. The root cause is a connection-type mismatch: AG_SEND/AG_RECV cannot be bound to an S7 connection. The remedy is to substitute the S7-300 / ET 200S compatible PUT/GET SFBs, or alternatively the T-blocks (USEND/URCV, BSEND/BRCV) over an S7 connection, or alternatively the Open TCP/IP blocks from the SIMATIC NET CP 300 library when no S7 connection is configured in NetPro.

1. Problem Statement

The reported failure on an IM151-8 PN/DP master station appears as follows after FC5 AG_SEND is called from OB1:

• SF LED on the IM151-8 illuminates solid red.
• Diagnostic buffer of the IM151-8 lists "I/O access error, reading" (event ID 0x3924 / 0x39xx family), pointing at the LADDR of the AG_SEND L-area.
• Removing the call of the AG_SEND wrapper (e.g., a user FC90) from OB1 clears the SF immediately.
• FC5 returns STATUS = W#16#8093 with DONE = FALSE, ERROR = TRUE.

The temptation is to assume the LADDR is wrong and to retest the PROFINET port base address (typically 2036*–2047* for an integrated PROFINET IO controller on an IM151-8). The actual root cause sits one layer above: the connection type bound to FC5/FC6 in NetPro.

2. Root Cause: Connection-Type vs. Comm Block Compatibility

SIMATIC S7 communication blocks are not interchangeable across connection types. The STEP 7 help text on "Common Parameters of the SFBs/FBs and SFC/FC for the S7 communication" defines a hard matrix:

The original NetPro configuration in the failure case used an S7 connection. The AG_SEND wrapper is therefore referencing a logical connection that has no AG_SEND/AG_RECV endpoint. The PROFINET IO controller (port 3, base address 2044*) is unrelated to the S7 connection target; it is an I/O area, not a communications socket. The CPU's online diagnostics display the S7 connection establishment attempt against the wrong subsystem and the call is rejected, which surfaces as the I/O access error, reading on the diagnostic buffer because the input area the call tries to read (the LADDR) belongs to the PROFINET IO image, not to the user data area.

3. Decoding Status 0x8093

Status word 0x8093 for FC5/FC6 (and equivalents) is documented in the STEP 7 help index under STATUS parameter of AG_SEND / AG_RECV. The high byte 0x80 indicates an AG_SEND-class status; the low byte 0x93 is the error subtype:

Related AG_SEND statuses the field engineer should also recognise on the IM151-8:

The diagnostic buffer entry "I/O access error, reading" observed on the IM151-8 is a synchronous TZ-1 fault generated by the IM151-8 firmware when the AG_SEND block tries to read the LADDR's process image and detects that the LADDR is part of the PROFINET IO image rather than the user I area. The OB121 (programming error) or OB122 (I/O access error) handler is invoked; if neither OB is loaded, the CPU goes to STOP. Loading OB122 (and OB121) is a standard hardening step for any IO-controller on PROFINET.

4. LADDR Selection — Why the PROFINET Port Base Address Is Wrong

On the IM151-8 PN/DP, the three PROFINET ports of the integrated IO controller (X1, X2, X3) are managed as one logical PROFINET device with a single IO base address range. In a typical STEP 7 / HW Config view the user sees:

Addresses suffixed with * indicate a diagnostic address slot, not a process-data slot. Passing 2044 or 2047 (0x7FC / 0x7FF) as LADDR to FC5 is structurally invalid: the LADDR parameter of AG_SEND expects the start address of the user I/O area in the process image, not a diagnostic address. This compounds the connection-type error and is why both 2044* and 2047* "do not work". When the user later moves to PUT/GET, no LADDR is required at all — PUT/GET reference a remote DB / bit on the partner CPU, not a local I/O area.

5. Recommended Remedy: S7 Connection with PUT/GET (FB14 / FB15)

For an IM151-8 CPU talking to an S7-300 CPU over the integrated PROFINET port, the lowest-friction, best-supported configuration is:

1. An S7 connection defined in NetPro from the IM151-8 (client) to the S7-300 CPU 315-2 PN/DP (server).
2. Use of the FB15 PUT and FB14 GET instances from the SIMATIC_NET_CP → CP 300 → Standard Library.
3. Each block instance requires a unique connection ID matching the NetPro connection entry.
4. No LADDR is needed; PUT/GET carry the data directly to / from a remote DB on the partner CPU.

5.1 NetPro connection entry (IM151-8 side)

Open the IM151-8 station in NetPro, right-click the CPU and select Insert New Connection. Choose the partner CPU 315-2 PN/DP and connection type S7 connection. The resulting connection record carries:

• Local ID: e.g. 1 (decimal), 1-based; this becomes the ID input of PUT/GET.
• Partner IP: 192.168.0.x as set on the S7-300 CPU's PROFINET interface (X2).
• Local end point: IM151-8 PROFINET interface (X1 / X2 / X3; the connection is bound to the CPU, not the port — any port can carry the S7 connection as long as the IP route is correct).
• Block parameters: Active connection establishment = yes on the IM151-8 side.

5.2 Calling FB15 PUT in OB1 (IM151-8)

// FB15 PUT — IM151-8 sends a 20-byte block to S7-300 DB100
// Instance DB: DB115 ("iPUT")
// Connection ID: 1 (must match NetPro)

CALL  "PUT" , DB115
  REQ     := M10.0          // Edge-triggered start bit
  ID      := W#16#1         // NetPro connection ID (decimal 1)
  DONE    := M20.0
  ERROR   := M20.1
  STATUS  := MW22
  ADDR_1  := P#DB100.DBX 0.0 BYTE 20   // Remote: S7-300 DB100, bytes 0..19
  SD_1    := P#DB200.DBX 0.0 BYTE 20   // Local : IM151-8 DB200, bytes 0..19
  LEN     := 20

5.3 Calling FB14 GET in OB1 (IM151-8)

// FB14 GET — IM151-8 reads 32 bytes from S7-300 DB110 into local DB210
// Instance DB: DB114 ("iGET")
// Connection ID: 1 (must match NetPro)

CALL  "GET" , DB114
  REQ     := M11.0          // Edge-triggered start bit
  ID      := W#16#1
  DONE    := M21.0
  ERROR   := M21.1
  STATUS  := MW24
  ADDR_1  := P#DB110.DBX 0.0 BYTE 32   // Remote: S7-300 DB110, bytes 0..31
  RD_1    := P#DB210.DBX 0.0 BYTE 32   // Local : IM151-8 DB210, bytes 0..31

For a 1-to-N layout (one IM151-8, multiple S7-300 stations) define one NetPro S7 connection per partner and instantiate one FB14/FB15 DB per connection, each with its own ID. The connection ID is the integer shown in the NetPro connection properties, not a hash of the partner IP.

6. Alternative 1: T-Blocks (USEND/URCV, BSEND/BRCV) on the S7 Connection

If the application requires handshake-driven, segmented data transfer (e.g. recipes or large process records), the T-blocks from the same CP 300 library are valid on an S7 connection:

The call signature uses the same ID parameter as PUT/GET (NetPro S7 connection ID) and uses an R_ID (DWORD) to demultiplex multiple T-block pairs on the same connection. BSEND/URCV call pattern:

CALL  "BSEND" , DB112   // IM151-8 sends 800 bytes to S7-300 DB300
  REQ    := M30.0
  ID     := W#16#1
  R_ID   := DW#16#1A2B3C4D   // Must match partner BRCV's R_ID
  DONE   := M31.0
  ERROR  := M31.1
  STATUS := MW32
  SD_1   := P#DB200.DBX 0.0 BYTE 800
  LEN    := 800

The S7-300 partner BRCV must use the same ID and the same R_ID; the S7-300 instance DB is created by the wizard or by right-clicking FB13 and choosing Instance DB in STEP 7.

7. Alternative 2: Open TCP/IP Communication Without NetPro

When no S7 connection is desired — for example, when the IM151-8 is exchanging data with a non-Siemens controller — use the Open TCP/IP blocks from the same library. The relevant FBs are FB63 TSEND, FB64 TRCV, FB65 TCON, FB66 TDISCON, FB67 TUSEND, FB68 TURCV. Configuration is purely parameter-driven via the TCON block; no NetPro entry is required. The connection parameters (partner IP, partner port, local port) are stored in the instance DB of TCON.

8. SF LED and I/O Access Error — Cleanup Procedure

After replacing AG_SEND with PUT/GET, clear the residual diagnostic state:

1. In STEP 7, go online with the IM151-8.
2. Open CPU → Operating Mode; the IM151-8 should already be RUN if OB122 was loaded — if not, perform a STOP → RUN transition.
3. Open PLC → Clear/Reset and execute Clear Reset (MRES) only if the diagnostic buffer cannot be cleared online. For an I/O access error, MRES is normally not needed; deleting the offending call from OB1 is sufficient.
4. Open the Diagnostic Buffer and confirm no new entries appear once the corrected PUT/GET calls are running.
5. Observe the IM151-8 LEDs: SF should be off, BF (bus fault) off, RUN solid green.

9. Verification Procedure

After commissioning, validate the corrected PROFINET communication in five steps:

1. Connection state — In NetPro, right-click the S7 connection, select Connection Status. State should read established within 1–2 s of RUN.
2. DONE / ERROR flags — In a watch table, force REQ = TRUE on a PUT instance and confirm DONE pulses, ERROR stays FALSE, STATUS = 0.
3. Round-trip data — Increment a counter in IM151-8 DB200.DBX0 (BYTE), write via PUT to S7-300 DB100.DBX0, then read back into IM151-8 DB210.DBX0 via GET. The GET-read value should follow the PUT-write value within 100–300 ms on a 100 Mbit/s PROFINET link.
4. Cable and link integrity — On the IM151-8 PROFINET port LED, link/activity should flash at the S7-300 PROFINET port rate (green/amber per Siemens PROFINET LED convention).
5. Diagnostic buffer cleanliness — After 1 h of cycling, the diagnostic buffer on the IM151-8 should contain no entries related to the S7 connection or the PUT/GET instance DBs.

10. Troubleshooting Matrix

11. Common Field Pitfalls

• Optimised DBs on the S7-300 partner. PUT/GET require non-optimised (absolute-addressable) DBs on the target. S7-300/400-class CPUs do not support optimised blocks, but if the S7-300 station is later replaced with an S7-1500, the blocks must be re-engineered — PUT/GET cannot address optimised DBs on S7-1500 by symbolic name alone; use absolute offsets in the S7-1500 DBs.
• Connection ID confusion. The connection ID in the NetPro connection table is a 16-bit integer. The ID input of PUT/GET is a WORD; do not pass the partner IP, the connection name, or the slot number.
• SFB vs FB selection. The S7-400 SFB14/SFB15 (PUT/GET as system function blocks) are not supported on S7-300 or IM151-8. Always use the FB14/FB15 instances from the CP 300 library.
• One REQ per call cycle, not level-triggered. PUT/GET require an edge on REQ. Holding REQ high causes only one job to start; the block does not retrigger.
• LEN on PUT must match the byte count of the largest ADDR_1 segment. If you set LEN to 0 with ADDR_1 specified, PUT evaluates ADDR_1's byte count automatically; for a multi-segment PUT, LEN must equal the total of all ADDR_1 segments.
• PROFINET port base address in HW Config is not a comms LADDR. Treat slot 0–X diagnostic addresses as diagnostic, not as data pointers for PUT/GET or AG_SEND.

12. Engineering Reference Summary

With the connection type corrected to S7 and the AG_SEND wrapper replaced by FB14/FB15 (or the T-block family), the IM151-8 establishes a clean, deterministic PROFINET data path to the S7-300 CPU 315-2 PN/DP. The SF LED clears on the next STOP→RUN transition, the diagnostic buffer stays empty, and the 0x8093 status no longer occurs because AG_SEND is no longer called.