S7-1200 PUT/GET Communication Setup for Shared Counter Totals

Overview

S7 communication between two SIMATIC S7-1200 CPUs (for example, CPU 1214C / DC/DC/DC or CPU 1214C / DC/DC/Rly) using the PUT and GET instructions is the fastest way to share process data without adding third-party hardware. In a typical counter-aggregation application, CPU 1 publishes its running total and CPU 2 publishes its running total; each side reads the other's value and computes a grand total. Because PUT/GET runs over the integrated PROFINET interface, you need only a switched Ethernet cable (or a shared switch) and two IP addresses in the same subnet.

This tutorial walks through every parameter required to make two CTUD-based counters visible across the link, including:

• Hardware and firmware prerequisites
• Project setup and CPU protection / security settings
• Non-optimized versus optimized data blocks
• Creating the S7 connection in the network view
• Calling PUT and GET and mapping the REQ, ID, ADDR_1, SD_1 parameters
• Adding the two CTUD values and verifying the result

Prerequisites

Step 1: Configure IP Addresses and Subnet

1. Open the TIA Portal project containing both CPUs (or add the second CPU via Devices & networks > Add new device).
2. Select each CPU in the device view and open Properties > PROFINET interface [X1] > Ethernet addresses.
3. Assign:
   • CPU_1: IP 192.168.0.1, subnet mask 255.255.255.0
   • CPU_2: IP 192.168.0.2, subnet mask 255.255.255.0
4. Tick Use router only if a router is present; for direct/subnet-local PUT/GET the router field stays empty.

Step 2: Enable PUT/GET Access on Both CPUs

Modern S7-1200 firmware ships with the connection mechanism blocked by default. Without enabling it, GET returns STATUS = 0x0001 (communication error) and PUT returns STATUS = 0x0001 as well.

1. Select the CPU in the project tree.
2. Open Properties > Protection & Security > Connection mechanisms.
3. Tick Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, ...) on both CPUs.
4. Compile and download to each controller.

Step 3: Create Non-Optimized Data Blocks

PUT/GET cannot dereference symbolic, fully-qualified optimized-block addresses. Each block that holds data exchanged over S7 communication must be created with Standard access (compatible with S7-300/400) — i.e. "Non-optimized".

1. In the project tree, right-click Program blocks > Add new block > Data block (DB).
2. In the block creation dialog, clear the tick on Optimized block access (Standard access is selected by default for new DBs but verify it).
3. Declare at least one variable of type DInt (32-bit signed, range -2 147 483 648 to 2 147 483 647) to hold the running total. Use DInt for CTUD accumulation; Int rolls over at ±32 767.

DATA_BLOCK "DB_CounterShare"
TITLE = 'Counter share published to partner'
AUTHOR : 'AutoGen'
VERSION : 0.1
NON_RETAIN
VAR
   TotalCount : DInt;   // running total exposed to the partner CPU
END_VAR
BEGIN
END_DATA_BLOCK

Repeat the procedure on the second CPU. The DB number must be unique within each CPU. There is no requirement for the numbers to match between the two controllers — the partner's DB number is passed into the ADDR_1 parameter of GET/PUT.

Step 4: Program the CTUD Counters and the Total

Insert an IEC counter in each CPU. The IEC CTUD function block in TIA Portal is found in Instructions > Basic instructions > Counter operations > IEC counter > CTUD. In each CPU, on every scan cycle, copy CV (current value) into the published DB:

// OB1 - CPU_1
"CTUD_1"(CU := I0.0,        // count up input
         CD := I0.1,        // count down input
         R  := I0.2,        // reset
         LD := I0.3,        // load preset (PV)
         PV := 1000);

"DB_CounterShare".TotalCount := "CTUD_1".CV;   // DInt copy, non-optimized DB

Now add the math that adds the local count to the remote count. Wait until the remote count has been refreshed — call GET before the add block:

// OB1 - CPU_1 - call PUT/GET in OB1 or a cyclic OB
// Local total plus remote total
"DB_GrandTotal".GrandCount :=
    "DB_CounterShare".TotalCount + "DB_RemoteShare".RemoteCount;

Step 5: Create the S7 Connection in the Network View

1. Open Devices & networks and select the Network view tab.
2. Drag a line from CPU_1's PROFINET port to CPU_2's PROFINET port. TIA Portal will create an S7 connection automatically with the connection ID 1 on the local CPU and a corresponding partner ID on the remote.
3. If you prefer to call PUT/GET with a manually managed ID, right-click the line and choose Properties > General > Connection ID — typical values are 100, 200, etc., to keep IDs stable across rebuilds.
4. Confirm that the connection is established: the line in the network view turns solid green when online; an orange dashed line indicates "not yet downloaded / inconsistent".

Step 6: Call the GET and PUT Instructions

GET reads data from the partner into a local DB; PUT writes data to the partner. In TIA Portal, drop the GET and PUT instructions from Instructions > Communication > S7 communication into a cyclic OB (OB1 is acceptable for slow counters; OB30+ for deterministic 100 ms cycles).

Per the S7-1200 GET and PUT reference, the function block pinout is:

Calling GET to read the partner's counter share:

// OB1 - CPU_1 - read partner total into DB_RemoteShare
"GET_Remote"(REQ  := TRUE,                 // run continuously
             ID   := 1,                     // connection ID from network view
             ADDR_1 := P#DB2.DBX0.0 DINT 4, // partner DB2 starts at byte 0, length 4 bytes
             RD_1   := "DB_RemoteShare".RemoteCount);  // local destination

Calling PUT to send the local total to the partner:

// OB1 - CPU_1 - publish local total to partner DB3
"PUT_Local"(REQ   := TRUE,
            ID    := 1,
            SD_1  := "DB_CounterShare".TotalCount,  // local source
            ADDR_1 := P#DB3.DBX0.0 DINT 4);         // partner destination

The pointer syntax P#DB<n>.DBX<offset>.<type> <length> is mandatory on the ADDR_x pins of PUT/GET when communicating with S7-1200 partners. The compiler rejects symbolic / fully-qualified addresses for the partner side because the partner's DB numbers are only known at runtime.

Step 7: Add the Two Totals

After the GET call, DB_RemoteShare.RemoteCount holds the partner's DInt. The grand total is then a single ADD instruction:

// OB1 - CPU_1
"DB_GrandTotal".GrandCount :=
    DINT_TO_DINT("DB_CounterShare".TotalCount) +
    DINT_TO_DINT("DB_RemoteShare".RemoteCount);

Cast only if you have changed the source variable type. DInt + DInt is intrinsically safe and avoids implicit type warnings.

Step 8: Verification

1. Download both CPU programs.
2. Go online with both CPUs (each in its own TIA Portal instance or by switching the online target).
3. Force CTUD_1.CU = TRUE on CPU_1 via the watch table and monitor DB_CounterShare.TotalCount on CPU_1 and DB_CounterShare.TotalCount on CPU_2 (after its PUT completes).
4. Monitor DB_GrandTotal.GrandCount on both CPUs — both totals must match the sum of the two CTUD current values.
5. Inspect GET_Remote.STATUS and PUT_Local.STATUS. A healthy job reports STATUS = 0x0000 on each completed call.

PUT/GET Status Word Reference

Troubleshooting Matrix

Engineering Best Practices

• Always create a dedicated non-optimized DB for S7 communication. Mixing communication variables with program variables in an optimized DB is the most common commissioning delay.
• Use DInt for counters; reserve the sign for direction-of-counting (count-up positive, count-down negative) and let LInt handle roll-over for very long-running applications.
• Trigger PUT/GET on a rising edge of a clock bit (e.g. Clock_1Hz or a custom slow timer) when continuous refresh is not required — this reduces PROFINET load on larger projects.
• Use the same connection ID for all PUT/GET calls between the same pair of CPUs. Each S7 connection supports parallel PUT and GET operations.
• Document the partner's IP address and DB numbers in the block header comment of the local GET/PUT call so future engineers can trace the data flow.
• On firmware V4.4 and later, consider assigning a separate "S7 communication" user in Users & roles and a per-connection password to satisfy hardening policies. PUT/GET itself does not authenticate, but the partner CPU's access protection does.

Alternative Approaches

Frequently Asked Questions