S7-1200 to S7-1500 GET/PUT Ethernet Data Transfer for PostgreSQL

This technical reference covers the end-to-end design, configuration, programming, and verification of an architecture in which multiple SIMATIC S7-1200 test-bench controllers publish process data to a single SIMATIC S7-1500 gateway that, in turn, archives the data into a PostgreSQL database. The document addresses the architectural decision between a gateway-based design and a direct PLC-to-service model, the engineering steps inside TIA Portal, the prerequisites for PostgreSQL connectivity, and the commissioning checks that must pass before a system can be signed off.

1. System Architecture Overview

The reference design assumes the following physical and logical layers:

• Edge layer – one or more SIMATIC S7-1200 CPUs (e.g. 6ES7215-1AG40-0XB0 CPU 1215C DC/DC/DC) controlling individual test benches, each paired with a Comfort HMI (TP700 / TP900 / TP1200).
• Gateway layer – one SIMATIC S7-1500 CPU with PROFINET interface (e.g. 6ES7515-2AM02-0AB0 CPU 1515-2 PN) that acts as the S7 communication concentrator and PostgreSQL bridge.
• Network layer – industrial Ethernet / Wi-Fi infrastructure (TP-Link switches / access points) that interconnects the test benches and the gateway. ISO-on-TCP port 102 is used for S7 communication; TCP port 5432 is used for PostgreSQL.
• Archive layer – PostgreSQL server (Linux or Windows) accepting INSERT statements from the S7-1500 via the SIMATIC ODK 1500S SQL driver or via an external service that polls the S7-1500.

2. Prerequisites

3. CPU Configuration for PUT/GET

By default, an S7-1200 rejects PUT/GET access from a remote partner. This protection must be explicitly enabled on every S7-1200 that participates in the data exchange.

1. Open the S7-1200 device configuration in TIA Portal.
2. Select the CPU and open Properties > Protection & Security > Connection mechanisms.
3. Tick Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, …).
4. Configure an access password (write protection ≥ 1) so that untrusted clients cannot change the operand image.
5. Confirm the Access level for the HMI and the GET/PUT connection – both should be set to Full access (no protection) only if the password is centralised in the project.

4. S7 Connection Engineering in TIA Portal

The S7-1500 is the active partner; the S7-1200 is the passive server. The connection is engineered in the Devices & Networks editor and downloaded into the S7-1500 only – the S7-1200 requires no connection configuration because the server role is automatic once PUT/GET is enabled.

1. Open Devices & Networks and select the S7-1500 CPU.
2. Click the Connections tab in the inspector window.
3. Choose S7 connection as the connection type and create a new partner entry pointing at the S7-1200 CPU.
4. Set Local ID (connection ID) – e.g. 100 for the first test bench. Keep IDs unique per partner.
5. Set the Partner address to the static IP of the S7-1200 (for example 192.168.10.21).
6. Leave Active connection establishment unchecked on the S7-1200 side and checked on the S7-1500 side.
7. Compile and download the S7-1500 hardware configuration.

5. GET and PUT Block Programming

The GET and PUT blocks (FBs FB14 / FB15 under the legacy instruction set; multi-instance capable in TIA Portal) are inserted from Instructions > Communication > S7 Communication. A typical S7-1500 OB1 cycle invocation looks as follows:

// Read 100 bytes of process data from S7-1200 (DB100) into S7-1500 (DB200)
"GET_DB".REQ   := TRUE;                          // Trigger
"GET_DB".ID    := W#16#0064;                     // Connection ID 100
"GET_DB".ADDR_1:= P#DB100.DBX0.0 BYTE 100;       // Remote source
"GET_DB".RD_1  := P#DB200.DBX0.0 BYTE 100;       // Local destination

// Write 50 bytes of configuration from S7-1500 (DB201) to S7-1200 (DB101)
"PUT_DB".REQ   := TRUE;
"PUT_DB".ID    := W#16#0064;
"PUT_DB".ADDR_1:= P#DB101.DBX0.0 BYTE 50;
"PUT_DB".SD_1  := P#DB201.DBX0.0 BYTE 50;

// Status evaluation
IF "GET_DB".DONE AND NOT "GET_DB".ERROR THEN
    // success – increment a cyclic counter, etc.
END_IF;
IF "GET_DB".ERROR THEN
    // record "GET_DB".STATUS into a diagnostic word
END_IF;

5.1 Common STATUS Codes

5.2 Data Block Design

Pre-allocate one optimised DB per test bench on the S7-1500 to receive the GET payload. Optimised blocks are required when the S7-1500 firmware is V2.0 or later and the S7-1500 must share data with OPC UA. If the S7-1500 only feeds the ODK 1500S C/C++ program, an absolute (non-optimised) DB is preferable because C code can read it via DB_GET with fixed offsets.

// S7-1500 DB200 "RecvBench01" – absolute, length 100 bytes
DATA_BLOCK "RecvBench01"
{ S7_Optimized_Access := 'FALSE' }
AUTHOR : Engineer
FAMILY : Archiving
VERSION : 0.1
  STRUCT
    Timestamp   : DATE_AND_TIME;   // 8 bytes  – BYTES 0..7
    Pressure    : REAL;            // 4 bytes  – BYTES 8..11
    Temperature : REAL;            // 4 bytes  – BYTES 12..15
    CycleCount  : DINT;            // 4 bytes  – BYTES 16..19
    StatusBits  : WORD;            // 2 bytes  – BYTES 20..21
    Spare       : ARRAY[1..78] OF BYTE; // 78 bytes – BYTES 22..99
  END_STRUCT;
END_DATA_BLOCK

6. PostgreSQL Connectivity Options

6.1 SIMATIC ODK 1500S SQL Driver

The SIMATIC ODK 1500S (Open Development Kit) provides a C/C++ API on the S7-1500 user space. The bundled SQL driver links the ODK program to a 32-bit ODBC data source. PostgreSQL is supported through the open-source psqlODBC driver, which must be installed on the engineering station that compiles the ODK project. At runtime the ODBC driver is loaded by the ODK runtime on the S7-1500.

1. Install psqlODBC 13.x (ANSI or Unicode, x86) on the engineering PC.
2. Create a 32-bit ODBC System DSN named, for example, PG_S7_ARCHIVE pointing at the PostgreSQL server (default port 5432, target database archive).
3. From the ODK Eclipse project, include SQL.H and call SQLConnect with the DSN, user, and password.
4. For each test-bench record, prepare an INSERT statement and bind parameters from the S7-1500 DB.

// ODK 1500S C example – INSERT into bench_log
SQLHENV   hEnv;
SQLHDBC   hDbc;
SQLHSTMT  hStmt;
SQLCHAR   DSN[] = "PG_S7_ARCHIVE";
SQLCHAR   UID[] = "plc_user";
SQLCHAR   PWD[] = "***";

SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv);
SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0);
SQLAllocHandle(SQL_HANDLE_DBC, hEnv, &hDbc);
SQLConnect(hDbc, DSN, SQL_NTS, UID, SQL_NTS, PWD, SQL_NTS);

SQLAllocHandle(SQL_HANDLE_STMT, hDbc, &hStmt);
SQLCHAR *sql = (SQLCHAR*)
  "INSERT INTO bench_log (bench_id, ts, pressure, temperature, cycle) "
  "VALUES (?, ?, ?, ?, ?)";
SQLPrepare(hStmt, sql, SQL_NTS);

int  bench_id = 1;
TIMESTAMP_STRUCT ts;
float pressure = 0.0f, temperature = 0.0f;
int  cycle = 0;
// ... populate ts / pressure / temperature / cycle from DB200 ...

SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, SQL_C_LONG,   SQL_INTEGER, 0,0, &bench_id,    0, NULL);
SQLBindParameter(hStmt, 2, SQL_PARAM_INPUT, SQL_C_TYPE_TIMESTAMP, SQL_TYPE_TIMESTAMP, 0,0, &ts, 0, NULL);
SQLBindParameter(hStmt, 3, SQL_PARAM_INPUT, SQL_C_FLOAT,  SQL_REAL,    0,0, &pressure,    0, NULL);
SQLBindParameter(hStmt, 4, SQL_PARAM_INPUT, SQL_C_FLOAT,  SQL_REAL,    0,0, &temperature, 0, NULL);
SQLBindParameter(hStmt, 5, SQL_PARAM_INPUT, SQL_C_LONG,   SQL_INTEGER, 0,0, &cycle,       0, NULL);
SQLExecute(hStmt);

SQLFreeHandle(SQL_HANDLE_STMT, hStmt);
SQLDisconnect(hDbc);
SQLFreeHandle(SQL_HANDLE_DBC, hDbc);
SQLFreeHandle(SQL_HANDLE_ENV, hEnv);

6.2 External Service Alternative

If the IT department owns the PostgreSQL server and prefers to keep a service-oriented boundary, the ODK driver can be replaced by a service on the database host that:

1. Hosts a snap7 client (or a S7-1500 OPC UA client) to read the S7-1500 tags.
2. Decodes the data, attaches a server-side timestamp, and writes to PostgreSQL using libpq or the chosen language driver (psycopg2 / Npgsql / pg-promise).
3. Replicates or partitions the data per test bench – typically one table per bench, indexed by a TIMESTAMPTZ column.

This topology removes the ODK licensing cost and the S7-1500 work-memory burden, but introduces an additional host that must be hardened and monitored.

7. TIA Portal Multi-Project Layout

Consolidating several test-bench projects with one gateway project is best handled with a TIA Portal multi-project (master project that references sub-projects). The recommended structure is:

1. Master project – contains the S7-1500 CPU, the PostgreSQL handshake, and the connection to the database host.
2. Sub-projects – one per test bench, each containing an S7-1200 CPU and its Comfort HMI. Sub-projects are referenced from the master using Insert > Subproject.
3. The S7 connections from each sub-project to the master are defined inside the master project's Devices & Networks editor; the local endpoints are resolved via the sub-project references.
4. HMI tags can be passed across project boundaries by exposing the S7-1500 DBs as HMI tags and using cross-reference or WinCC proxy tags in the comfort panels.

8. Network and Wi-Fi Considerations

Test-bench installations frequently rely on consumer-grade TP-Link access points. ISO-on-TCP / RFC1006 is reasonably tolerant of packet loss, but the S7 communication stack uses a sliding window and resends on timeout, so a sustained loss > 1% will manifest as elevated 80A0 / 80C0 STATUS codes and growing cycle times.

9. Security Hardening

1. CPU password – assign a unique password to every S7-1200 and the S7-1500; do not leave "Full access (no protection)" selected.
2. Firewall – on the S7-1500 subnet firewall, allow only TCP/102 from the S7-1500 IP to each S7-1200 IP, and TCP/5432 from the S7-1500 IP to the PostgreSQL host.
3. TLS – on S7-1500 firmware V2.9 and later, enable Secure PG/OP and Secure S7 Communication with self-signed certificates. Replace the ODK ODBC connection with a TLS-tunneled psqlODBC DSN (use sslmode=require in the connection string and configure PGSSLROOTCERT).
4. Database roles – the plc_user PostgreSQL role should be granted only INSERT on the logging tables and USAGE on the schema, with no SELECT / UPDATE / DELETE permissions.
5. Audit – enable PostgreSQL log_statement = 'mod' and ship logs to the central SIEM for forensic analysis.

10. Commissioning and Verification

1. Connect a programming PC to the S7-1500 PROFINET port and open Online & Diagnostics. Confirm all S7 connections are in state Established.
2. Force GET_DB.REQ = TRUE from a watch table; confirm the DONE pulse, ERROR = FALSE, and a valid STATUS.
3. From the S7-1500 online watch table, write a known pattern into DB200 and verify with the S7-1200 watch table that the corresponding offset in DB100 matches.
4. Tail the PostgreSQL pg_log file or run SELECT * FROM bench_log ORDER BY id DESC LIMIT 5; – rows must appear within the configured cycle time.
5. Pull the PROFINET cable on the test bench for 30 s; confirm that the S7-1500 marks the connection as broken, buffers records, and that PostgreSQL catches up after the cable is reinserted.
6. Run a 24-hour soak test capturing a heartbeat row every cycle; verify row count equals the expected count ± 0.

11. Alternative Architectures

12. Troubleshooting Matrix

13. Reference Documentation

• SIMATIC S7-1200 Programmable Controller – System Manual
• SIMATIC S7-1500 Automation System – System Manual
• SIMATIC ODK 1500S – Programming Manual
• PostgreSQL Documentation – Server / Client / libpq
• psqlODBC – Download Archive
• Snap7 – Open Source S7 Communication Library