Migrating CP 343-1 Communication to S7-1500 CPU 1516F Integrated

Overview: From CP 343-1 to Integrated PROFINET on S7-1500

When an S7-300 system with a CPU 316-2 DP and a separate CP 343-1 communications processor is migrated to a single S7-1500 CPU 1516F-3 PN/DP (6ES7516-3FN02-0AB0 or later), the PROFINET functionality that the CP previously handled is absorbed into the CPU. The integrated PN interfaces X1 and X2 of the CPU 1516F-3 PN/DP expose the same TCP/IP, UDP, ISO-on-TCP, and PROFINET IO services the CP used to provide, but the program blocks, address model, and configuration interface in TIA Portal differ from STEP 7 classic. This article shows how to re-establish the camera communication that previously used the CP's input/output address area and the legacy AG_SEND/AG_RECV (FB12/FB13) blocks, using the modern TIA Portal instruction set.

The first engineering decision is to identify which transport protocol the camera actually used on the CP 343-1. Three practical cases dominate field installations:

Hardware and Firmware Prerequisites

Before reconfiguring, verify the CPU 1516F-3 PN/DP part number and firmware. The integrated PN X2 port is a switched 2-port interface with the same TCP/IP stack capabilities as a CP 343-1 Lean/Standard/Advanced on S7-300.

Confirm the firmware version in TIA Portal under Devices & networks > CPU 1516F-3 PN/DP > Properties > General > Identification. If the firmware on the physical CPU is older than the TIA Portal default, perform an online upgrade through Online > Accessible devices > Online & Diagnostics > Firmware update using a firmware file downloaded from the Siemens Industry Online Support portal.

Identifying the Old CP 343-1 Protocol

Open the original STEP 7 V5.x project containing the S7-300 station. Navigate to SIMATIC 300 Station > CP 343-1 > Properties > Ethernet and look at the connection list. The connection type field gives the definitive answer:

• TCP connection — protocol used for plain-stream data, commonly used by Cognex, Keyence, SICK, and Basler cameras that expose a custom ASCII or binary socket.
• ISO-on-TCP connection — RFC1006 wrapped TCP, used by older Siemens-compatible vision systems and some industrial barcode readers.
• UDP connection — connectionless datagram mode, used by some broadcast-style camera triggers.
• S7 connection — only if the camera is itself a Siemens PLC or an S7-protocol emulator.

Open the OB1 (or OB35) in the STEP 7 project and read the AG_SEND/AG_RECV call to confirm the connection ID (ID input) and the LADDR input. The LADDR parameter on the old S7-300 was the I/O start address of the CP 343-1 in the process image, typically W#16#0100 or W#16#0200. On the S7-1500 there is no equivalent LADDR — connections are managed entirely by the TCON block's connection description.

Configuring the PROFINET Interface X2 in TIA Portal

The integrated PROFINET interface of the CPU 1516F-3 PN/DP must be assigned an IP address and subnet mask on the same segment as the camera. This replaces the CP 343-1 IP configuration.

1. In the TIA Portal project tree, open Devices & networks and double-click the CPU 1516F-3 PN/DP device.
2. Select the PROFINET interface X2 in the graphic (the right-hand port block, separate from X1).
3. In Properties > General > Ethernet addresses, choose IP address and enter the same address previously assigned to the CP 343-1 (for example 192.168.10.50) or a free address in the camera subnet.
4. Set the Subnet mask (typically 255.255.255.0) and confirm no router is required.
5. Under Properties > Advanced options > Port statistics, leave the default SNMP and LLDP options enabled to allow diagnostics.
6. If the network requires it, switch on Port [X2 P1] > Activation of the port and confirm the link mode is set to Auto-negotiation.

Verify the configuration by going online and using Online & diagnostics > Ethernet addresses > IP assignment. The CPU should respond to a PING from the camera subnet. If the firmware version is V2.9 or later, the PN X2 stack has the same 8 active connection limit per port as a CP 343-1 Standard.

Creating the Connection in TIA Portal

Unlike STEP 7 V5.x, where the connection was created inside the CP 343-1 hardware object, TIA Portal places connections at the project level so they can be shared between multiple PROFINET nodes.

1. Right-click the Devices & networks editor and choose Add new connection.
2. Select the CPU 1516F-3 PN/DP as the local endpoint and unspecified partner for the remote endpoint when the camera is not represented as a PROFINET device.
3. Set Connection type to TCP, ISO-on-TCP, or UDP based on the protocol identified in the legacy project.
4. Assign the camera's IP address (for example 192.168.10.20) and port number. Common camera ports: 1024, 5000, 7000, 7777, or the port documented by the vision vendor.
5. Confirm with OK. TIA Portal assigns a connection ID automatically (typically 1); this is the value the TCON block will reference.

Open the newly created connection and check Properties > Address details > Connection ID; this is the symbol you will use as the ID input on the TCON/TSEND/TRCV blocks.

Program Block Selection and Implementation

The S7-1500 instruction set provides two equivalent ways to communicate: the compact compound blocks TSEND_C and TRCV_C (which fold TCON, TDISCON, TSEND, and TRCV into one FB), or the granular blocks TCON, TDISCON, TSEND, TRCV, TUSEND, TURCV for fine control. For a migrated camera link the compact form is recommended because it reproduces the connection-establishment logic the CP 343-1 used to handle autonomously.

Compact Implementation with TSEND_C and TRCV_C

Insert a TSEND_C block in OB1 to send the trigger to the camera, and a TRCV_C block to receive the part-height payload. Both are available under Instructions > Communication > Open user communication.

// TSEND_C - trigger command
// Input signals
REQ    := TRUE;                  // rising edge triggers send
CONT   := TRUE;                  // keep connection alive after send
LEN    := 16;                    // length of trigger payload in bytes
DONE   => send_done;            // one-cycle pulse on success
BUSY   => send_busy;            // TRUE while send is active
ERROR  => send_error;           // TRUE if send failed
STATUS => send_status;          // 16#0000 on success

// Connection description
CONNECT := "Conn_DB_camera";     // generated by TIA connection wizard
ID      := 1;                    // connection ID
// Data area
DATA    := P#DB_Camera_Trigger.DBX 0.0 BYTE 16;

// TRCV_C - receive part type and height
EN_R   := TRUE;                  // always ready to receive
LEN    := 0;                     // 0 = use ADHOC mode (read whatever is queued)
RCVD_LEN => recv_len;           // actual bytes received
DONE   => recv_done;
ERROR  => recv_error;
STATUS => recv_status;

// Connection description
CONNECT := "Conn_DB_camera";
ID      := 1;
DATA    := P#DB_Camera_Result.DBX 0.0 BYTE 256;

The Conn_DB_camera instance is generated automatically when TIA Portal creates the connection; its name appears in the project tree under Program blocks > System blocks > Connections. It encapsulates the local and remote IP, port numbers, and protocol type. Do not edit its members directly.

Granular Implementation with TCON + TSEND + TRCV

When the camera requires non-blocking I/O or a precise control flow that the compact blocks do not allow, the granular implementation gives full freedom. Below is the equivalent pattern using TCON, TSEND, and TRCV.

// TCON - establish connection once on startup
TCON_DB (REQ := start_edge, CONNECT := "Conn_DB_camera", ID := 1);
// Wait for DONE then issue sends/receives

// TSEND - request part height from camera
TSEND_DB (REQ := send_req, ID := 1, LEN := 16, DATA := P#DB_Trigger.DBX 0.0 BYTE 16,
          DONE => send_done, BUSY => send_busy, ERROR => send_err, STATUS => send_stat);

// TRCV - receive response with part type and height
TRCV_DB (EN_R := TRUE, ID := 1, LEN := 0, DATA := P#DB_Result.DBX 0.0 BYTE 256,
         RCVD_LEN => recv_len, DONE => recv_done, BUSY => recv_busy,
         ERROR => recv_err, STATUS => recv_stat);

// TDISCON - tear down on shutdown
TDISCON_DB (REQ := stop_edge, ID := 1, DONE => disc_done, ERROR => disc_err, STATUS => disc_stat);

Mapping the Old CP 343-1 I/O Area to the New Receive DB

In the legacy S7-300 program the data from the camera ended up at a fixed process-image input address, for example PIB 256 through PIB 271 (16 bytes). On the S7-1500 this address space does not exist. Replace every read from the old PEB/PIB area with a read from the receive DB that the TRCV/TRCV_C block fills:

Bulk-replace by searching the original S7-300 sources for PIB, PEB, PEW, PED, and PQB, PAB, PQW, PAD references with the CP's LADDR prefix and rewriting each occurrence. In LAD/FBD this is also where the BIE/ENO behavior of the old AG_RECV (FB13) must be re-evaluated: TSEND_C/TRCV_C report success through the DONE bit rather than BR/ENO. Old FB13 outputs STATUS and ERROR map to STATUS and ERROR on the new blocks, but the encoding follows the SIMATIC S7-1500 communication error codes rather than the legacy CP 343-1 status set.

Commissioning with Hercules SETUP

Before connecting the real camera, validate the PLC side using Hercules SETUP utility (HW-group) as a TCP server or UDP peer on a laptop connected to X2.P1 or X2.P2. Hercules can echo bytes and display received payloads in both ASCII and hex.

1. Install Hercules on a Windows laptop and connect the laptop to the CPU's X2 port via patch cable.
2. Set the laptop IP to 192.168.10.99 (same subnet as the CPU's X2 address) and ping the CPU to verify the link.
3. In Hercules, switch to TCP Server mode, set the listening port (e.g. 5000), and click Listen.
4. Go online with TIA Portal, trigger the TSEND_C block (force REQ := TRUE once), and confirm Hercules shows the sent bytes.
5. Type a payload into the Hercules Send field and click Send. The S7-1500 receive DB should populate; monitor recv_status in the watch table.
6. Repeat for UDP by switching Hercules to UDP and using TUSEND/TURCV on the PLC.

If TRCV returns STATUS = 16#0000 and RCVD_LEN equals the byte count sent from Hercules, the migration is functionally correct.

Status Code Reference for TSEND_C and TRCV_C

The block STATUS output reports local errors (16#7000 - 16#7FFF) and remote errors (16#8000 - 16#FFFF). The most relevant values when migrating from a CP 343-1:

The full mapping is documented in the TIA Portal Online Help under Instructions > Communication > Open User Communication > STATUS parameter. For comparison, the legacy AG_SEND/AG_RECV status codes are not numerically identical; treat them as different number spaces and re-derive error handling logic instead of copying it byte-for-byte.

S7 Routing Considerations for Multi-Network Setups

If the camera is on a separate subnet (for example 192.168.20.0/24) and the HMI or engineering station is on 192.168.10.0/24, the CPU 1516F-3 PN/DP performs routing through X1 and X2 without needing the CP 343-1's S7 routing services. This works because the integrated PN interfaces expose S7 routing functions analogous to those the CP used to provide. Verify routing under Properties > Ethernet addresses > IP router; if the camera subnet sits behind a managed switch with a gateway, declare the gateway IP in the CPU's PROFINET interface.

Routing can be confirmed with Online & diagnostics > Functions > Routing: a successful ping from HMI station through the CPU to the camera IP closes the loop. Reference: S7 routing between CPU and CP interfaces (Siemens TIA Portal documentation cloud).

Troubleshooting Matrix

Migration Checklist Before Going Online with the Camera

• Compile the TIA Portal project — confirm zero errors, zero warnings on TSEND_C/TRCV_C blocks.
• Download HW config and SW blocks together to the CPU.
• Verify CPU X2 IP via Online & diagnostics > Ethernet addresses.
• Confirm the connection ID used by TSEND_C matches the one in the connection editor.
• Run a watch table with send_status, send_busy, recv_status, recv_len and force REQ := TRUE on TSEND_C.
• Validate payload structure with Hercules round-trip before connecting the camera.
• Switch the cable from the laptop to the camera, observe the first real transmission, and capture both the STATUS code and the received bytes.
• Once stable, save the project to the SIMATIC memory card so it survives power cycle.

Field-Proven Notes

Engineers migrating from CP 343-1 to the integrated PN of a CPU 1516F-3 PN/DP commonly encounter three practical situations that the textbook migration does not cover:

1. Vendor-specific protocol on top of TCP. Most cameras do not speak raw TCP; they wrap a binary header (4 bytes length + payload, or 2 bytes sync + payload). The TRCV block will deliver the bytes faithfully — parsing the header is the application's responsibility in the receive DB.
2. Camera expects periodic polling. If the camera acts as a TCP server and replies only when polled, the S7-1500 must initiate the send. Put TSEND_C in OB1 gated by a cyclic trigger (for example from a 100 ms cyclic interrupt OB) rather than relying on a one-shot.
3. Camera closes the connection after each reply. Use TSEND_C with CONT = FALSE so the connection is dropped after each cycle; this matches a vision system that releases the socket between scans. Conversely, set CONT = TRUE if the camera expects a persistent session.