PROFINET TCP/IP Socket Programming with S7-400 PLCs in VB

Overview

PROFINET is positioned by PROFIBUS & PROFINET International (PI) as an open Industrial Ethernet standard for data acquisition and control, but the practical reality is that the full PROFINET CBA (Component Based Automation) stack is wrapped in DCOM, the specifications are paywalled, and the on-the-wire real-time frames (RTC, RT, IRT) are not exposed through any public Windows socket API. For an engineer who only needs to read and write process data to a SIMATIC S7-416 CPU from a Visual Basic client, the correct path is therefore not PROFINET at all, but the native open communication services built into the S7-400 firmware: ISO-on-TCP (RFC 1006), plain TCP, and UDP. These services ride on standard TCP/IP, accept any Winsock-capable client, do not require a PROFINET stack or DCOM, and are configured with the Step 7 "Open Communication" (OC) Wizard plus a small SCL function block on the PLC side.

This reference walks through the complete architecture, hardware compatibility (CP 443-1 PN vs. CP 343-1 / EM 243-1), the OC Wizard connection setup, the SCL server block, and a Visual Basic 6 / VB.NET client using the Winsock control. It also explains why PI's licensing model looks the way it does, and why an ActiveX/COM wrapper is essentially the only Windows-side alternative when you really do need CBA.

Why PROFINET Is Not a Socket Protocol

PROFINET defines three performance classes on top of Industrial Ethernet:

• NRT (Non-Real-Time) – standard TCP/IP, used for parameterization, diagnostics, and CBA RPC traffic. Latency ≈ 100 ms.
• RT (Real-Time) – Ethernet frames with VLAN priority and a PROFINET-specific EtherType (0x8892), no IP/UDP header. Latency ≈ 1–10 ms.
• IRT (Isochronous Real-Time) – scheduled by a master clock, used only for motion. Latency < 1 ms with jitter < 1 µs.

RT and IRT bypass the IP stack entirely. They are not addressable as socket endpoints, cannot be opened with socket()/connect(), and are offloaded to PROFINET ASICs on the CP or PN-CPU. NRT channels do use TCP/IP, but the only NRT application that PI publishes is the PROFINET CBA RPC/DCOM interface, which is a Microsoft-COM-specific binary protocol. There is no publicly documented plain-text or request/response NRT service that a Winsock client can call directly.

The reason the standard feels "secret" is therefore structural, not accidental:

1. RT/IRT frame formats are defined in IEC 61784-2 and the PI specification "PROFINET IO – Technology and Application", distributed by PI to members and via paid download.
2. CBA's wire format is DCOM, whose detailed spec is held by Microsoft and the Object Management Group. PI does not re-publish it; it ships the DCOM wrappers themselves.
3. Conformance testing and the GSD/GSDML device-description mechanism are also PI-controlled, so a third-party stack cannot claim PROFINET compliance without joining PI.

Hardware Compatibility: Which CP Modules Support Open Communication?

The Open Communication (OC) services on the S7-400 require that the Ethernet interface – whether the CPU's integrated PN port or a communication processor (CP) – exposes the right firmware services. Empirical compatibility from the field is summarized below.

Connection Types Available on the S7-400

NetPro exposes four transport types for open communication. Pick the one that matches your data rate, payload size, and client platform.

For a VB client behind a corporate firewall, ISO-on-TCP on port 102 is the lowest-risk choice: the port is well known, the 4-byte TPDU prefix is trivial to encode, and the S7-400 firmware already knows how to multiplex it. For high-throughput telemetry where you control both ends, plain TCP on a custom port is simpler to debug with Wireshark because the payload starts immediately after the TCP header.

Prerequisites

• PLC side: S7-416 CPU (any -3 PN/DP variant) with STEP 7 V5.5 + SP4 or TIA Portal V15.1 and later. The CPU must have a PROFINET interface (integrated PN or CP 443-1 PN).
• Open Communication Wizard (OC Wizard): Add-on package installed on the STEP 7 PC. Free download from Siemens support (entry ID 25209116).
• PC side: Windows 7/10/11 with a Winsock-capable development environment. Visual Basic 6 (with MSWINSCK.OCX) or VB.NET (with System.Net.Sockets).
• Network: Ethernet switch, 100 Mbit/s or better. Static IP addressing recommended. The PLC and PC must be on the same IP subnet unless you route TCP through a managed switch.
• Administrative rights on the engineering PC to install the OC Wizard and (if you target VB6) to register the Winsock OCX.

Step 1 – Configure the TCP Connection in NetPro

1. Open the STEP 7 project that contains the S7-416 station.
2. Launch NetPro from the project.
3. Right-click the S7-400 CPU → Insert New Connection.
4. Connection partner: Unspecified.
5. Connection type: TCP connection (or ISO-on-TCP if you prefer RFC 1006).
6. Local end point: the CPU or the CP 443-1 PN.
7. Partner address: the IP address of the VB host (e.g. 192.168.0.50).
8. Partner port: 2000 (or any free port you will open on the PC side).
9. Local port: leave blank for the PLC (the firmware allocates one).
10. Confirm and Save & Compile All (Ctrl+F9) to download the connection configuration to the CPU on next download.

NetPro writes a connection ID into the generated SDBs. You will need this ID (a small integer such as 1) when you call AG_SEND / AG_RECV in SCL.

Step 2 – Generate the OC Wizard Blocks

1. Start the Open Communication Wizard from the STEP 7 start menu.
2. Select the S7-400 station and the NetPro connection you just created.
3. Choose the transport: TCP, ISO-on-TCP, or UDP.
4. Set the maximum send/receive length (default 240 bytes; max 1460 for TCP, 1452 for ISO-on-TCP).
5. Choose the protocol: Send/Receive (full-duplex) or Fetch/Write (S7 partner service, server-pulled).
6. Select the SCL source library destination and click Generate.

The wizard drops a small SCL library into your project containing:

• An instance DB (DB100 by default) that holds the connection ID, status words, and the receive buffer.
• Two FBs (FB100 SEND and FB101 RCV) that wrap the AG_SEND / AG_RECV system functions.
• A ladder stub for OB1 that calls the FBs cyclically.

Drag the generated FBs into OB35 (the 100 ms cyclic OB) for deterministic timing, or leave them in OB1 if cycle time is not critical.

Step 3 – Server-Side SCL: The S7-400 Application Block

The OC Wizard gives you a transport. You still need an application protocol on top – a frame format that the VB client can build. The simplest possible framing is length-prefixed records:

• 4 bytes (big-endian UINT32): payload length N.
• N bytes: payload (function code + data).

Here is a minimal SCL server that exposes a 16-word data block and accepts read/write requests from the VB client. Function code 0x01 = read words, 0x02 = write words, 0x03 = read DB block name (returns "OK\n").

// SCL sample: server block for S7-416, calls OC-wizard FB100/FB101
FUNCTION_BLOCK "TCP_Server"
VAR
    sSend   : ARRAY[0..239] OF BYTE;   // 240 byte transmit buffer
    sRecv   : ARRAY[0..239] OF BYTE;   // 240 byte receive buffer
    iLenReq : INT;                     // requested length from VB
    iLenIn  : INT;                     // bytes actually received
    iLenOut : INT;                     // bytes to send
    iStat   : INT;                     // AG_RECV status
    iErr    : INT;                     // AG_SEND status
    dbUser  : BLOCK_DB;                // handle to user DB (DB200)
END_VAR
BEGIN
    // 1. Receive a frame
    iStat := "RCV"(                  // FB101 from OC wizard
        ID          := 1,             // NetPro connection ID
        LEN         := 240,           // max bytes
        DATA        := sRecv,
        NDR         := iLenIn);

    IF (iStat = 0) AND (iLenIn >= 4) THEN
        // 2. Decode length prefix (big-endian)
        iLenReq := (BYTE_TO_INT(sRecv[0]) * 16777216)
                 + (BYTE_TO_INT(sRecv[1]) * 65536)
                 + (BYTE_TO_INT(sRecv[2]) * 256)
                 +  BYTE_TO_INT(sRecv[3]);

        // 3. Dispatch by function code (byte 4)
        CASE sRecv[4] OF
            16#01:  // READ_WORDS
                // 4-byte start index in sRecv[5..8]
                sSend[0] := sRecv[5];
                sSend[1] := sRecv[6];
                sSend[2] := sRecv[7];
                sSend[3] := sRecv[8];
                sSend[4] := 16#01;     // echo function code
                sSend[5] := 16#00;     // status OK
                // copy 16 words from DB200.DBW[idx] into sSend[6..37]
                iLenOut := 38;

            16#02:  // WRITE_WORDS
                // index in sRecv[5..8], count in sRecv[9..10], data sRecv[11..]
                sSend[0] := 16#00; sSend[1] := 16#00; sSend[2] := 16#00; sSend[3] := 16#04;
                sSend[4] := 16#02;
                sSend[5] := 16#00;     // status OK
                iLenOut := 6;

            ELSE
                sSend[0] := 16#00; sSend[1] := 16#00; sSend[2] := 16#00; sSend[3] := 16#02;
                sSend[4] := 16#FF;     // unknown function
                sSend[5] := 16#01;
                iLenOut := 6;
        END_CASE;

        // 4. Transmit
        iErr := "SEND"(               // FB100 from OC wizard
            ID          := 1,
            LEN         := iLenOut,
            DATA        := sSend,
            DONE        := iErr);
    END_IF;
END_FUNCTION_BLOCK

Step 4 – Visual Basic 6 Client (Winsock Control)

For VB6, the canonical solution is the MSWINSCK.OCX Winsock control. Drop it on a form and use the following skeleton.

' VB6 client skeleton, ISO-on-TCP (port 102) to S7-416
Dim gConn As Boolean

Private Sub Form_Load()
    Winsock1.Protocol = sckTCPProtocol
    Winsock1.RemoteHost = "192.168.0.10"   ' PLC IP
    Winsock1.RemotePort = 102              ' ISO-on-TCP port
    Winsock1.Connect
End Sub

Private Sub Winsock1_Connect()
    gConn = True
    ReadWords 0, 16                       ' initial read of 16 words from offset 0
End Sub

Private Sub Winsock1_Close()
    gConn = False
End Sub

Public Sub ReadWords(ByVal iIndex As Long, ByVal iCount As Integer)
    Dim b(0 To 7) As Byte
    Dim i As Integer

    ' Build length prefix (4 bytes, big-endian) = 5 (func + index + count)
    b(0) = 0: b(1) = 0: b(2) = 0: b(3) = 5
    b(4) = &H1                           ' function code READ_WORDS
    b(5) = (iIndex And &HFF000000) \ &H1000000   ' big-endian index
    b(6) = (iIndex And &HFF0000)   \ &H10000
    b(7) = (iIndex And &HFF00)     \ &H100
    b(8) =  iIndex And &HFF
    ' count would go into b(9..10) if your protocol needs it
    If gConn Then Winsock1.SendData b
End Sub

Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)
    Dim b() As Byte
    Winsock1.GetData b, vbByte + vbArray, bytesTotal
    ' parse length, function, status, then payload
    ' ... project-specific handling ...
End Sub

For VB.NET, replace the Winsock control with System.Net.Sockets.TcpClient and NetworkStream; the wire format is identical.

Step 5 – VB.NET Client (System.Net.Sockets)

' VB.NET client skeleton
Imports System.Net.Sockets
Imports System.IO

Module PlcClient
    Dim cli As TcpClient
    Dim ns  As NetworkStream
    Const PLC_IP As String = "192.168.0.10"
    Const PLC_PORT As Integer = 102

    Sub Connect()
        cli = New TcpClient(PLC_IP, PLC_PORT)
        ns  = cli.GetStream()
    End Sub

    Function ReadWords(idx As Integer, count As Integer) As Byte()
        Dim pkt(9) As Byte
        pkt(0) = 0 : pkt(1) = 0 : pkt(2) = 0 : pkt(3) = 6      ' length=6
        pkt(4) = &H1                                            ' READ
        pkt(5) = CByte((idx >> 24) And &HFF)
        pkt(6) = CByte((idx >> 16) And &HFF)
        pkt(7) = CByte((idx >> 8)  And &HFF)
        pkt(8) = CByte(idx And &HFF)
        pkt(9) = CByte(count And &HFF)
        ns.Write(pkt, 0, pkt.Length)

        ' 4-byte length prefix
        Dim hdr(3) As Byte : ReadExact(ns, hdr, 4)
        Dim n As Integer = (hdr(0) << 24) Or (hdr(1) << 16) Or (hdr(2) << 8) Or hdr(3)
        Dim buf(n - 1) As Byte : ReadExact(ns, buf, n)
        Return buf
    End Function

    Sub ReadExact(s As Stream, buf As Byte(), n As Integer)
        Dim got As Integer = 0
        While got < n
            got += s.Read(buf, got, n - got)
        End While
    End Sub
End Module

Verification

1. Connection test. From the engineering PC, open a command prompt and run telnet 192.168.0.10 102. A successful TCP handshake proves the CPU and CP 443-1 PN are accepting connections on port 102.
2. Wireshark trace. Filter on tcp.port==102. You should see the SYN/SYN-ACK/ACK three-way handshake, then length-prefixed application data. ISO-on-TCP frames will show the 4-byte TPDU header (00 00 00 xx 11 d7 ...) before the application data.
3. OB1 status LEDs. The OC wizard's instance DB exposes two status words: RCV.STATUS and SND.STATUS. A healthy connection reads 0 (W#16#0000). Common non-zero values are listed in the troubleshooting table below.
4. Read/write round-trip. From VB, request a known value (e.g. read 16 words starting at offset 0), then write that same value plus one back, then read again. If the third read returns the incremented value, the full request/response cycle is working.

Troubleshooting Matrix

Cross-Platform Notes (Win CE, Windows Mobile)

The whole reason an engineer considers a raw TCP/IP socket approach instead of a Siemens-supplied OPC server or DCOM wrapper is portability to a small embedded HMI or a Windows Mobile / Win CE device. Two practical constraints apply:

1. DCOM is heavy. PI's PROFINET CBA wrapper requires DCOM, COM, and often an out-of-process server. Win CE 5/6 supports COM, but the full DCOM stack is optional and often stripped from BSPs. Windows Mobile 5/6 does not include DCOM at all.
2. ActiveX control availability. The "OC Wizard" generates a SIMATIC-side function block; the PC-side MSWINSCK.OCX is part of Visual Basic 6, not Win CE. A Compact Framework (CF) app on Win CE must use System.Net.Sockets – which is exactly the VB.NET path shown above.

The TCP-socket approach therefore scales down better than the PROFINET/COM approach. A CF client connecting via ISO-on-TCP port 102 needs only the .NET Compact Framework 2.0 or later; the S7-416 server-side code is identical to the SCL block above.

PROFINET CBA vs. Native TCP/IP – When to Choose Which

Pick PROFINET CBA when you must exchange data with a third-party controller or HMI that already speaks CBA. Pick native TCP/IP for any in-house tool, mobile HMI, or one-off data-acquisition job.

Performance Numbers (typical, S7-416-3 PN/DP, firmware V6.0)

• Single-frame round-trip, 240-byte payload, 100 Mbit/s, both ends on the same switch: 2–3 ms.
• Throughput with 1460-byte payloads, 100 ms OB35 cycle: ~7,000 read requests/second, limited by application FB processing, not the TCP stack.
• Maximum sustained connection count on CP 443-1 PN: 64 (32 of which are reserved for S7/HMI; the remainder are free for OC).
• AG_SEND / AG_RECV latency inside the CPU: ~0.4 ms per call when the CP's internal buffer is hit; ~1.2 ms when it spills to the user DB.

Common Pitfalls

1. Mixing the two connection types in the same S7 program. An ISO-on-TCP port 102 connection and a plain TCP port 2000 connection can coexist, but the OC wizard's instance DBs must be assigned distinct connection IDs in NetPro.
2. Forgetting to download the connection configuration. The SDBs containing the connection description live in the CPU, not in NetPro. A "Save & Compile" without "Download to Target" leaves the PLC with no listener on port 102.
3. Expecting AG_SEND to queue. AG_SEND returns DONE after the data is copied into the CP's internal buffer. If the partner is slow, the CP can refuse additional sends with status 0x80C3. Build a small back-pressure mechanism in the SCL block.
4. Trusting the OC wizard on every firmware. Siemens updates the wizard with each STEP 7 release. Re-generate the blocks after a STEP 7 upgrade; the generated FBs are not always backward compatible.
5. Disabling the integrated PROFINET port. If the CPU 416 has both an integrated PN port and a CP 443-1, the wizard may attach the connection to the wrong interface. Pin the connection to a specific interface in NetPro.

Migration Path: From Custom TCP to PROFINET

If you later need to interoperate with PROFINET controllers from third parties, the cleanest migration is to keep the SCL server block as-is and add a PROFINET IO device image in the same CPU. The S7-416 with PROFINET firmware can run both PROFINET IO and the OC open communication in parallel, on the same physical port. The wizard-generated FBs and your custom SCL are independent of the PROFINET IO image; they share only the Ethernet MAC/PHY.

When interoperability is required, the alternative – exporting your server block as a PROFINET CBA component – requires the PI toolkit and a non-trivial modeling step in SIMATIC iMap. For most point-to-point PC links, the cost-benefit ratio favours keeping the TCP/IP path indefinitely.

References in This Article

Siemens KB 25209116, "Communication between S7-CPU and third-party device via TCP/IP", is the official entry point and the source of the connection-type, port, and max-payload figures cited above. The S7-400 Communication Function Manual (entry ID 1117396 in Siemens Support) documents AG_SEND, AG_RECV, AG_LSEND, and AG_LRECV, including the error-code matrix summarized in the troubleshooting table. PROFINET CBA architecture and conformance requirements are published by PROFIBUS & PROFINET International at the PI downloads portal.

FAQ