S7-300 to S7-200 MPI Data Transfer Using X_PUT and X_GET

This technical reference details the engineering workflow for exchanging process data between a Siemens SIMATIC S7-300 (master/client) and a SIMATIC S7-200 (slave/server) over an existing MPI bus. The procedure uses the S7-300 system function blocks SFC67 X_GET, SFC68 X_PUT, and SFC69 X_ABORT — the only blocks in the standard S7-300 instruction library that natively speak the S7-200 server protocol on MPI.

1. Architecture and Protocol Background

The S7-300 and S7-200 are linked by an MPI subnet (default 187.5 kbit/s, up to 12 stations without repeaters, up to 32 with two repeaters on a bus segment). The S7-200 cannot initiate communication; it only responds to read/write requests from the S7-300. Each CPU has a unique MPI address; the S7-200 default is 2, the S7-300 default is 2 — these must be made unique before commissioning.

The X_GET / X_PUT services are S7-communication variants wrapped by the SFC layer. They operate on a single connection at a time per block instance and require the S7-200 to be parameterized with at least one TSAP (Transport Service Access Point) reserved for S7 communication. By default Micro/WIN allocates TSAP 02.01 on the S7-200; this value is hard-coded into the SFC67/68 instance and cannot be changed from STEP 7 on the S7-300 side.

2. Prerequisites

Before any block is written, verify the following:

1. STEP 7 (Simatic Manager) version compatible with the installed S7-300 CPU firmware. STEP 7 V5.5 SP2 or later is recommended; earlier versions (V5.3, V5.4) also support SFC67/68/69 but may require an HSP for newer CPUs.
2. STEP 7 Micro/WIN V4.0 SP6 or later (Micro/WIN Smart is for S7-200 SMART and is not covered here). Micro/WIN is required only to configure the S7-200 as an MPI server, not to write user logic.
3. An PC adapter (USB/PPI or USB/MPI) or CP 5611 / CP 5613 on the engineering station, with the right to access both MPI nodes.
4. Profibus/MPI cable with proper terminating resistors (terminator switches ON at the two end stations only).
5. Unique MPI addresses (commonly S7-300 = 2, S7-200 = 4).
6. The S7-200 project file (MWP) so the server configuration can be re-applied after any firmware update.

3. Configuring the S7-200 as an MPI Server

Open the S7-200 project in Micro/WIN and navigate to View → Component → Configure the CPU (or use the "System Block" dialog). The key parameters are:

• MPI Address: 4 (or any unused address 1–31, ≠ S7-300 address).
• MPI Baud Rate: 187.5 kbit/s (must match the S7-300's MPI subnet baud rate).
• Highest MPI Address: 31 (default), unless the segment is intentionally small.

Then enable the S7 communication channel. In Micro/WIN V4.0 the relevant toggle is System Block → Communication; the field is "Number of communication connections for S7 protocol" and must be ≥ 1. The CPU reserves internal resources for this. Download the system block to the S7-200; the S7-200 does not need user code modifications for the X_PUT/X_GET to work.

4. S7-300 Hardware and NetPro Configuration

Open HW Config and double-click the MPI interface of the S7-300 CPU. Set:

• Address: 2 (example)
• Subnet: MPI(1), 187.5 kbit/s
• Highest MPI address: 31

The S7-200 will not appear in the STEP 7 hardware catalog as a normal DP/PN slave. It is represented by a "S7-200-Station" placeholder inserted via Insert → Other Station → SIMATIC S7-200 in NetPro (STEP 7 V5.x). Assign it MPI address 4 and download the net configuration. If NetPro cannot see the S7-200 over MPI, run PLC → Accessible Nodes in Simatic Manager to confirm that the S7-200 responds; the placeholder station may still be inserted even when the S7-200 is offline, and the configuration is then downloaded to the S7-300 only.

5. Writing the X_PUT Block (S7-300 → S7-200 Write)

SFC68 X_PUT writes from a source area in the S7-300 to a destination area in the S7-200. The block has a fixed interface:

Sample call in an SCL / STL block. The standard pattern is to use OB1 (cyclic main) with a cyclic trigger on the REQ input, or a time-based interrupt (see §7).

// SCL example - call X_PUT from OB1 or OB35
// Transfers 20 bytes from DB20 to S7-200 VB100..VB119
// Rising-edge on bTrig starts the job, bHold = TRUE keeps connection open

IF bInit THEN
    iBusy := 0;
    bInit := FALSE;
END_IF;

// Call once after PLC startup to establish the connection context
X_PUT(REQ := bTrig,         // BOOL trigger (pulse)
      CONT := TRUE,         // keep connection established
      DEST_ID := W#16#4,    // MPI address of S7-200 = 4
      VAR_ADDR := P#V100.0 BYTE 20,  // S7-200 destination
      SD := P#DB20.DBX0.0 BYTE 20,   // S7-300 source
      RET_VAL := iRetVal,   // error code
      BUSY := bBusy);

6. Writing the X_GET Block (S7-200 → S7-300 Read)

SFC67 X_GET is the read counterpart. The interface is identical to X_PUT except that SD is replaced by RD (receive destination on the S7-300 side). The same MPI address and the same TSAP are used; X_GET and X_PUT can be issued from independent OBs and the firmware handles the connection table internally.

7. Where to Place the SFC Calls in the S7-300 Program

The SFC67/68/69 calls do not have to live in OB1. Three placement strategies are field-proven:

For a Reverse Osmosis control application (as in the source scenario) where the S7-300 already contains the running control logic, do not insert the X_PUT/X_GET into the main control block. Wrap the calls in a dedicated FB (e.g. FB100 "MPI_S7_200_Transfer") and call it once from OB35 with a 200 ms period. This decouples the data exchange from the control scan, simplifies the OB1 of the running program, and makes the timing deterministic.

Sample F-block stub:

FUNCTION_BLOCK FB100
VAR
    bTrig        : BOOL;
    bBusyPut     : BOOL;
    bBusyGet     : BOOL;
    iRetPut      : INT;
    iRetGet      : INT;
END_VAR

BEGIN
    // 200 ms cyclic - instance DB carries the persistent state
    X_PUT(REQ := bTrig, CONT := TRUE, DEST_ID := W#16#4,
          VAR_ADDR := P#V100.0 BYTE 20,
          SD := P#DB100.DBX0.0 BYTE 20,
          RET_VAL := iRetPut, BUSY := bBusyPut);

    X_GET(REQ := bTrig, CONT := TRUE, DEST_ID := W#16#4,
          VAR_ADDR := P#V200.0 BYTE 10,
          RD := P#DB101.DBX0.0 BYTE 10,
          RET_VAL := iRetGet, BUSY := bBusyGet);

    bTrig := NOT bTrig;  // edge generation for next cycle
END_FUNCTION_BLOCK

8. STOP / RUN Mode Handling on First Commissioning

When SFC67/68/69 are first downloaded into an S7-300 that is in RUN, the blocks are present in the work memory but the connection resources are not initialized. The published Siemens guidance is to set the S7-300 CPU to STOP once, then back to RUN, so that OB100 / restart logic re-initializes the internal S7-communication table. After that first initialization cycle, subsequent edits and downloads of the SFC calls do not require a STOP transition.

Practical procedure in Simatic Manager:

1. Online → Accessible Nodes confirms the S7-300 at MPI address 2 is online.
2. Right-click the S7-300 station → PLC → Operating Mode (or CTRL+I).
3. Click "Stop"; wait for the diagnostic buffer entry "STOP caused by operator".
4. Download the blocks (SFBs, DBs, FB100, OB35 if newly created).
5. Switch the CPU back to Run via the same dialog or the mode selector on the CPU.
6. Monitor the instance DBs in online view — BUSY must oscillate 0 → 1 → 0 and RET_VAL must read W#16#0000 on a successful job.

9. Return Codes and Error Mapping

RET_VAL is the single most important value to capture. Always store it in a DB and trend it on the HMI, because the S7-300 will silently skip the job on the next scan if RET_VAL is non-zero.

The SFC69 X_ABORT RET_VAL set is identical but with 0x8001 indicating "no connection was established" — that is normal at first call and is not an error.

10. Verification Procedure

After commissioning, the data exchange must be confirmed in three independent ways:

1. PLC-to-PLC test (online monitor): Open the source DB on the S7-300 and the V-area in the S7-200 with both CPUs online. Force a distinct value in the S7-300 source byte and confirm the S7-200 V-byte updates within the next OB35 period. Do the reverse for X_GET.
2. Diagnostic buffer: On the S7-300, view PLC → Diagnostic Buffer. Successful S7-200 connections log "S7-200 server connection established" and "connection in operation" within a few seconds of RUN.
3. Bus monitor (optional): With a CP 5611 and a softing PROFIBUS monitor or Siemens BT200, capture the MPI telegrams. X_PUT appears as an S7 Put PDU addressed to the S7-200 MPI node. The S7-200 acknowledges with a single positive ACK PDU. This is the only way to prove the wire-level protocol is healthy when the higher-level SFCs return ambiguous codes.

11. Data Rate and Sizing Notes

The MPI bus at 187.5 kbit/s carries approximately 1500–2000 bytes/s of useful payload per active pair. Each X_PUT/X_GET exchange of 76 bytes takes 30–50 ms end-to-end including the S7-300 OB scan overhead. For a Reverse Osmosis plant the typical update cycle is 1 s, well within the bus budget.

If multiple S7-200 stations must be polled, place each SFC pair in its own OB35 instance or use OB35 with a state machine that services one S7-200 per OB35 tick. Do not run more than 3 active X_PUT calls per second against a single S7-200; the CPU 22x's internal S7 stack is small and will refuse new connections with RET_VAL 0x80C3 if flooded.

12. Troubleshooting Matrix

13. FAQ