CPU 410 SMART Data Transfer: PUT/GET and TSend/TRCV Setup

CPU 410 SMART Data Transfer: PUT/GET and TSend/TRCV Setup

Transferring binary process data between two CPU 410 SMART controllers (article number 6ES7 410-5H...) arranged in a ring topology is a routine requirement in SIMATIC PCS 7 plants. The source scenario describes six CPU 410 SMART units in a ring (CPU1–CPU6) and a request to move binary tags from CPU5 to CPU6. This reference documents the engineering workflow, the IP addressing rules that govern the PUT/GET blocks, the Open User Communication alternative (TSend/TRCV), the I-Device option, the Media Redundancy Protocol (MRP) requirements on the PROFINET ring, and the firmware/CP constraints that decide which path is feasible on any given revision of firmware.

1. System Overview and Hardware

The CPU 410 SMART ships with two PROFINET interfaces that are physically implemented as a 2-port switch (interface X1 with port 1 and port 2, plus an Ethernet/PROFINET service interface X2 in some revisions). For plant bus communication the PROFINET interface is used. For terminal bus / engineering access an additional CP 443-1 or Ethernet CP is typically added.

Each CPU 410 SMART supports up to 64 S7 connections in the standard product, and more with CP 443-1 Advanced. The exact number depends on the firmware version and the active PCS 7 version (V8.2 / V9.0 / V9.1).

2. Ring Topology Requirements (MRP)

A ring of six CPU 410 SMARTs is closed at the PROFINET level using Media Redundancy Protocol (MRP) as defined in IEC 62439. Configure MRP as follows:

1. Set the role of one CPU PROFINET port to MRP Manager (typically CPU1 or any non-critical node; do not assign the manager to a CPU whose loss would degrade the AS).
2. Set all remaining CPUs to MRP Client.
3. Verify that the physical fiber/copper cabling closes the ring. Port 2 of the last CPU must terminate at port 1 of the first CPU.
4. Disable MRP on the secondary (non-ring) PROFINET interface if it exists; MRP must run on a single ring only.

Ring reconfiguration time with MRP on a CPU 410 SMART is typically < 200 ms. With MRPD (MRP with PROFINET device-level redundancy) on HMI panels connected to the ring, the reconfiguration is bumpless. For S7-connection traffic this is sufficient; do not require PROFINET IRT for S7 communication traffic.

3. Communication Methods Available

For binary data only (a handful of bits/markers), the S7-Communication path with PUT/GET is the smallest, fastest, and most maintainable option. The Open User Communication path becomes necessary only when:

• The partner is non-Siemens and does not accept ISO-on-TCP.
• The number of connections exceeds the S7-connection resource.
• The data payload is larger than 64 KB and the S7-Communication length becomes the bottleneck.

4. S7-Communication: PUT and GET Block Semantics

The S7-Communication services are configured in two places:

1. NetPro / connection configuration (SIMATIC Manager) or Devices & Networks > Connections (TIA Portal for PCS 7 V9.0+): the connection partner, IP, connection resource, and slot are declared here.
2. User program: the PUT / GET FBs are called in OB1 or a cyclic OB; the local connection ID is referenced in the block's ID input.

4.1 PUT block parameters

The remote IP address is not a parameter on the FB. It is set in the connection editor and stored in the CPU's connection database. The ID input ties the call to that configured connection.

4.2 GET block parameters

For CPU5 → CPU6 binary exchange, CPU5 calls PUT with SD_1 = P#DB100.DBX0.0 BYTE 1 and ADDR_1 = P#M100.0 BYTE 1 (one byte of markers on CPU6). The opposite direction is mirrored with GET.

5. Step-by-Step: Configuring the CPU5 → CPU6 PUT

5.1 Prerequisites

• PCS 7 V9.0 SPx (or V8.2 SPx) installed with a valid license for the AS 410.
• CPU 410 SMART firmware image present in HWCN (default for PCS 7 V9.0+).
• Both CPUs online-reachable from the ES via PROFINET (PG cable or plant bus).
• IP plan: each CPU has a unique IPv4 in the same subnet, e.g. 192.168.1.51 (CPU5) and 192.168.1.61 (CPU6) with mask 255.255.255.0.
• A free S7-connection resource on both CPUs (CPU 410 SMART provides 64 max, far above the 6 needed in the ring).

5.2 Procedure (SIMATIC Manager / PCS 7 Engineering)

1. Open the S7 project containing the AS stations of CPU5 and CPU6. Both must be in the same multiproject or be cross-referenced via Cross-Project Connections.
2. In the CPU5 component view, right-click the CPU and select Insert New Connection > S7 Connection.
3. In the partner dropdown, choose the CPU6 station. Set Type = S7 Connection and confirm. This places the connection entry in the CPU5 connection table.
4. Open the connection. On the General tab the local ID is generated; write it down. On the Addresses tab enter the partner IP 192.168.1.61 if it is not auto-populated from HWCN. Make sure the Connection Resource on the partner side is free (slot 0, second local ID = 1 by default for the first S7 connection).
5. Repeat the action on the CPU6 side so both stations list each other as the partner. Without the partner entry, the connection will not establish in the live system.
6. Compile and download HWCN to both CPUs. Compile only if you want to compare offline/online; otherwise full download is required for the connection to become effective.
7. Insert FB 15 PUT (from Standard Library > Communication > S7 Communication) into a cyclic OB of CPU5. Provide a global instance DB (e.g. DB200). The FBs in PCS 7 V9 are typically called via the multi-instance mechanism inside the CFC chart.
8. Wire ID = W#16#1 (the local connection ID assigned by NetPro). The ID is a hex value, not the slot number; convert the displayed decimal ID to W#16# if necessary.
9. Configure the data area:

// CPU5 PUT call in SCL (instance DB = DB200)
"PUT_DB"(REQ  := bSendTrig,
         ID   := W#16#1,
         DONE := bDone,
         ERROR:= bErr,
         STATUS:= wStatus,
         SD_1 := P#DB101.DBX0.0 BYTE 4,   // 4 bytes = 32 bits of binary on CPU5
         ADDR_1 := P#M 200.0 BYTE 4);     // destination marker byte 200 on CPU6

10. Download the program to CPU5 only. CPU6 does not need a PUT block; it acts as the S7-Communication server (it accepts the write into its marker area).
11. For the reverse direction (CPU6 → CPU5), insert FB 14 GET on CPU5 (CPU5 pulls from CPU6) or PUT on CPU6 (CPU6 pushes to CPU5). The choice depends on who triggers the transfer; for cyclic exchange using OB35 (1 s) the most common pattern is PUT on the sender and GET on the receiver.

6. Where the Remote IP Lives in PUT/GET

The question "How can we mention the Ethernet IP address for the particular CPU in the PUT/GET block?" is the most common newcomer issue. The answer: the IP is not on the FB. It is in the connection configuration.

If the STATUS output of PUT returns 16#8080, 16#8181, or 16#8184, the connection is wrong; the partner cannot be reached at the configured IP or the partner S7 service is not yet up. These are connection-resource errors, not FB errors, and they almost always point to an IP, subnet, or downloaded-HWCN mismatch.

7. Open User Communication Alternative: TSend / TRCV

For TCP-based open user communication, the CPU 410 SMART supports the following FBs from the Standard Library > Communication > Open User Communication folder:

• FB 65 TCON – establish connection
• FB 66 TDISCON – tear down
• FB 67 TUSEND / FB 68 TURCV – UDP send / receive
• FB 63 TSEND / FB 64 TRCV – TCP send / receive

7.1 TCON configuration data block (TCON_PARAM)

DATA_BLOCK DB_TCON_5
STRUCT
  BlockLength   : WORD := W#16#40;
  Id            : WORD := W#16#1;        // local connection ID
  ConnectionType: BYTE := B#16#11;       // 11h = TCP, 12h = TCP (no passive), 13h = UDP
  ActiveEstabl  : BOOL := TRUE;          // TRUE = active (client), FALSE = passive (server)
  LocalDeviceID : BYTE := B#16#0;        // 0 = PN-IO, 1 = IE/AS-i, 2 = CP
  LocalTsapIdLen: BYTE := B#16#0;        // 0 = auto TSAP from IP+port
  LocalTsapId   : ARRAY[1..16] OF BYTE;  // not used here
  RemSubnetIdLen: BYTE := B#16#0;
  RemSubnetId   : ARRAY[1..6] OF BYTE;
  RemStaddrLen  : BYTE := B#16#4;        // IPv4 = 4 bytes
  RemStaddr     : ARRAY[1..4] OF BYTE := B#16#C0, B#16#A8, B#16#01, B#16#3D; // 192.168.1.61
  RemTsapIdLen  : BYTE := B#16#2;        // port as 2 bytes (e.g. 2000 = 0x07D0)
  RemTsapId     : ARRAY[1..16] OF BYTE := B#16#07, B#16#D0;
  Spare         : WORD := W#16#0;
END_STRUCT;
END_DATA_BLOCK

Unlike PUT/GET, the partner IP is visible in the user program through the RemStaddr field. This is one reason engineers prefer OUC when the partner is not a Siemens controller and the IP is more visible in code reviews.

7.2 TSEND / TRCV cycle

// CPU5 SCL: cyclic send of 8 bytes from DB102 to CPU6 (192.168.1.61, port 2000)
IF bConnectOK THEN
  "TSEND_DB"(REQ := bCyclicTrig,
             ID  := W#16#1,
             LEN := 8,
             DATA:= P#DB102.DBX0.0 BYTE 8,
             DONE=> bDone,
             BUSY=> bBusy,
             ERROR=> bErr,
             STATUS=> wStatus);
END_IF;

8. I-Device Communication

If the binary data is part of a process image that should be IO-mapped between two AS stations (CPU5 is a PROFINET IO Device to CPU6's IO Controller), the I-Device approach removes the need for any communication FB. Configure CPU5 as an I-Device in HWCN, export the I-Device slots, and import them as IO on CPU6's PROFINET subnet.

• Submodule granularity down to 1 bit is possible.
• Latency is the PROFINET update time, not S7 connection time.
• No connection resource is consumed.

Drawback: the I-Device relationship is one-direction and one-to-one. If you need CPU5 → CPU6 and CPU6 → CPU5, you must create a second I-Device relationship in the opposite direction. For purely binary tag exchange, this is often more engineering effort than the PUT/GET path.

9. CP 443-1 Considerations

The field report raises an important firmware constraint: some older CPUs only support S7-Communication as server. A CPU 410 SMART with the latest firmware supports S7-Communication as both client and server. If your engineering works with mixed firmware (for example, a stock CPU 410 SMART running an older FW that has not been upgraded), the CPU that must act as client must be confirmed. If neither CPU can act as client:

1. Insert a CP 443-1 Advanced in the slot of the CPU that needs to act as client. The CP supports S7-Communication as both client and server on the firmware levels delivered with PCS 7 V9.x.
2. Configure the S7 connection to terminate at the CP (not at the CPU's PROFINET interface). The CP's MAC and IP are then the partner endpoint, and the CP forwards to the CPU via the backplane.
3. Download the CP configuration. Activate the connection.

The CPU 410 SMART is a single-width module with a fixed number of plug-in CPs. For AS 410 stations, common companion CPs are 6GK7 443-1EX30-0XE0 (CP 443-1) and 6GK7 443-1GX30-0XE0 (CP 443-1 Advanced). Verify availability and firmware compatiblity against the PCS 7 V9.0 catalog.

10. Connection Resource Budget for the 6-CPU Ring

For the full-duplex binary exchange between every pair (CPU1↔CPU2, CPU2↔CPU3, …, CPU6↔CPU1), the number of S7 connections grows with topology choice:

The CPU 410 SMART handles 64 connections easily. The bottleneck, if any, is on the CP 443-1 or on the engineering station acting as OP/PG with its own connection reservation.

11. Verification and Diagnostics

1. Online > Accessible Nodes from the ES: confirm that every CPU is visible at its configured IP and that the PROFINET device name is correct.
2. CPU > Connection table (online): confirm the S7 connection is in state Established. Status should read 0x04 (Connected).
3. Watch the STATUS word of PUT/GET in a VAT table. 16#0000 = OK; 16#7FFF = no job active; 16#8183 = no resources; 16#8184 = connection not established.
4. Diagnostic buffer on the partner CPU: search for events of class Communication with IDs around 0x1A, 0x3B, 0x3D for connection establishment / abort.
5. PROFINET diagnostics: in the topology editor, the ring ports must show MRP active. Use Online > PROFINET Topology to view the LLD status.
6. Watch table on CPU6 to confirm the marker byte written by CPU5 has the expected value (e.g. toggle a bit at 1 Hz on CPU5 and observe on CPU6).

12. Troubleshooting Matrix

13. Firmware and Compatibility Notes

• CPU 410 SMART MLFBs in the 6ES7 410-5H... range cover firmware V8.x and V9.x. The functional scope (number of connections, I-Device, MRP client/manager) depends on the binary.
• Open User Communication (TSend/TRCV/TCON) is supported on CPU 410 SMART from firmware V8.1 onward. Earlier binaries need a CP 443-1 for OUC.
• MRP Manager role requires at least V8.0 of the CPU firmware and the corresponding GSD-based PN interface.
• If the project is migrated to PCS 7 V9.0 with TIA Portal, the S7-Connection editor and the FB ID conventions remain the same, but the Connection path UI changes. Always re-validate local IDs after a migration.

14. Sample Project: Minimal Binary Exchange Between CPU5 and CPU6

1. CPU5: DB101 contains 32 bits of binary at byte 0..3. Mark these as RETAIN = NO for volatile exchange.
2. CPU6: marker area MW200..MW207 (16 bytes) is the receive buffer.
3. CPU5: CFC chart S7_CPU5 → S7_CPU6 with one PUT block (instance DB = CPU5_S7TO_CPU6), connected to OB35 (1 s).
4. Wire as in the SCL snippet of section 5.2. Trigger on a 1 s pulse from OB35_PULSE.
5. CPU6: CFC chart S7_CPU6 → S7_CPU5 with one GET block pulling 16 bytes from CPU5's DB101.
6. Compile and download both charts.
7. Verify in VAT: on CPU5, toggle DB101.DBX0.0; on CPU6, observe M200.0 follow after at most 1 s.

15. Safety and Engineering Best Practice

• Do not route inter-CPU binary signals through the safety IO path. Use safety F-CPU communication (F-SEND / F-RECV or F-I-Device) if the bits are part of a safety function; S7-Communication PUT/GET is not safety-rated.
• Tag the S7-Connection with a project-wide unique Local ID and document the value in the connection table export.
• Use OB35 (1 s) or OB32 (500 ms) for the trigger; avoid OB1, which can make error analysis harder.
• Always compile and download both sides in a single maintenance window. A one-sided HWCN download leaves the ring with a connection-state mismatch that does not self-heal until the next restart of the unmodified side.
• For diagnostic visibility, route the STATUS and ERROR outputs of every PUT/GET into a status DB and expose the DB to WinCC / PCS 7 OS for operator-level fault display.