Resolving Siemens PN/BACnet LINK TIA Portal Reachability Errors

Problem Overview

The Siemens PN/BACnet LINK is a protocol gateway that translates between PROFINET IO (PNIO) on the plant-floor side and BACnet/IP on the building-automation side. Field engineers commissioning the gateway frequently encounter the following symptom set:

• The PN/BACnet LINK appears in a PRONETA network scan with its MAC address, IP address, and PROFINET device name.
• From the same engineering station, TIA Portal cannot establish an online connection to the S7 PLC to which the PN/BACnet LINK is assigned, and returns an IO/PN diagnostics error indicating the module is unreachable.
• The PLC's online diagnostics view shows the LINK device with a red fault icon (typically "Device not reachable" / "Station failure").

This symptom is almost always the result of mismatched configuration between the TIA Portal project, the physical PROFINET device name stored in the LINK, and the BACnet/IP subnet configuration. The PRONETA tool uses Layer-2 discovery (LLDP/DCP) and therefore can detect the device on the wire even when higher-layer PROFINET AR (Application Relationship) and BACnet/IP routing are broken. Treat PRONETA visibility as a physical link confirmation only — it does not validate logical reachability.

PN/BACnet LINK Product Identification

Before troubleshooting, confirm the exact hardware variant. Siemens ships the gateway under multiple catalog numbers depending on the BACnet profile and approvals required:

Verify the firmware version on the device web interface (default http://<ip>/main.htm) under Diagnostics → Device Information. Cross-check the firmware against the TIA Portal HSP (Hardware Support Package) installed; TIA Portal V17 and earlier will not recognize V3.x firmware modules without the matching GSDML and HSP updates from the Siemens Support download portal.

Root Cause Matrix

The table below maps the dominant failure modes observed in field commissioning. Each row identifies the symptom layer, the likely cause, and the diagnostic test that confirms it.

Diagnostic Procedure in TIA Portal

The fastest first action is to use the integrated online diagnostics in TIA Portal rather than scanning from PRONETA. The Online & Diagnostics view resolves Layer-2 visibility from Layer-7 reachability:

1. Open the TIA Portal project containing the S7-CPU that hosts the PN/BACnet LINK in its PROFINET IO system.
2. Right-click the CPU → Go online.
3. If the CPU itself is reachable, expand Online & Diagnostics → PROFINET IO → Devices.
4. Locate the PN/BACnet LINK node. A red status indicates one of the standard PROFINET diagnostic codes:
   - 0x0001 Station failure
   - 0x0002 Station diagnosis available
   - 0x001E AR establishment failure (name mismatch dominant cause)
5. Double-click the LINK node and read the Status and Diagnostic buffer tabs. The text of the message names the specific cause ("PROFINET device name not assigned", "IP address duplicate", "Submodule mismatch").

For diagnostic background refer to the Siemens Technical Support portal and the official PN/BACnet LINK operating instructions: PN/BACnet LINK Operating Instructions (PDF).

IP Address and PROFINET Name Configuration

The single most common cause of the "visible in PRONETA but not in TIA" symptom is a missing or mismatched PROFINET device name on the PN/BACnet LINK. PROFINET IO uses DCP (Discovery and Configuration Protocol) to assign a station name that the controller's AR uses to identify the device; the IP alone is not sufficient.

Recommended procedure:

1. In TIA Portal, open Devices & Networks and select the PN/BACnet LINK in the PROFINET IO system.
2. Note the configured PROFINET device name (e.g., pn-bacnet-link-1) — TIA requires this to match exactly what is stored in the gateway.
3. Open PRONETA on the engineering station.
4. Run Network analysis → select the LINK → Assign PROFINET name.
5. Type the exact name configured in TIA, including case. The default name in new TIA projects is often the device article number with hyphens — do not change it during troubleshooting.
6. Cycle the AR by right-clicking the device in TIA Online view → Operate → Reinitialize, or power-cycle the LINK if reinit does not clear the fault.

IP addressing pitfalls to clear during the same exercise:

• Duplicate IP: PN/BACnet LINK will accept the first DCP-assigned IP and respond to ARPs even with a duplicate on the wire. Use arp -a on the PG to confirm the MAC-to-IP mapping is unique.
• Subnet mismatch: The PG must be on a subnet that can reach the LINK without NAT. If the PG is on 192.168.0.0/24 and the LINK is on 192.168.1.0/24, TIA cannot open the AR even though PRONETA (which broadcasts DCP) still finds it.
• Router configuration: PN/BACnet LINK does not act as an IP router. The PROFINET and BACnet ports are bridged at Layer-2 only.

BACnet/IP Network Considerations

Once the PROFINET AR is up and TIA Portal reports the LINK as reachable, validate the BACnet/IP side. The PN/BACnet LINK behaves as a BACnet/IP device on the building-automation side. In routed BACnet/IP networks — almost every plant installation — broadcast messages such as Who-Is and I-Am do not cross router boundaries by default.

The Siemens Diagnostics and troubleshooting for BACnet/IP networks knowledge base explicitly identifies this as a primary fault class: "The BACnet clients cannot access the different BACnet devices on the various VLANs. BACnet devices do not have a fixed IP address (if configured as BBMD)."

Resolution paths:

1. BBMD (BACnet/IP Broadcast Management Device): Configure one BBMD per IP subnet containing BACnet devices and populate the BBMD table on each device with the foreign device entries.
2. Foreign Device Registration (FDR): If the BACnet client lives on a different subnet than the LINK, register the client as a foreign device with the BBMD on the LINK's subnet.
3. Static binding on the client: As a fallback, manually add the LINK to the client's device list using its IP and UDP port 47808 (decimal) / 0xBAC0. The CAS BACnet Explorer guidance at CAS BACnet Explorer — Manually adding a device across a subnet details this procedure.

PRONETA Versus TIA Portal Detection

Understanding why PRONETA detects the device while TIA does not is critical to choosing the correct fix:

PRONETA's DCP multicast operates at the Ethernet broadcast domain level. It can see any device on the local VLAN regardless of IP configuration. TIA's online connection requires the full PROFINET AR handshake — DCP identify → DCP identify response → AR establishment → CR (Connect Request) → CC (Connect Confirm). Any failure along that chain returns "device not reachable" in TIA even though PRONETA is satisfied.

Firmware and GSDML Verification

A subtle but recurring cause of unreachable LINK modules is a TIA Portal project built against a newer GSDML than the firmware on the device. The LINK will reject the AR if the GSDML version in the controller's project is newer than what the firmware understands. Compare:

• TIA Portal: Devices & Networks → PN/BACnet LINK → Properties → Identification & Maintenance — note IM_HW_Rev and the GSDML revision (e.g., GSDML-V2.35-Siemens-PNBCLINK-20190327.xml).
• PN/BACnet LINK web UI: Diagnostics → Device Information — note firmware build date and revision.

If the GSDML in the project is newer than the firmware supports, either update the LINK firmware via the web UI's firmware update page or roll the device in the project back to the matching GSDML revision. Firmware images and GSDML files are available from the official Siemens Industry Online Support downloads area.

Step-by-Step Resolution Procedure

The following ordered procedure resolves the majority of field-reported PN/BACnet LINK reachability faults. Execute each step, do not skip, and confirm before moving on.

1. Verify Layer-1: Confirm link LEDs on both PROFINET ports of the LINK and on the switch port. Replace cable if uncertain.
2. Verify Layer-2: Run PRONETA network analysis. The LINK should appear with its MAC and current IP.
3. Verify Layer-3 from PG: From the engineering station, execute ping <LINK-IP>. If it fails, the PG is on the wrong subnet or a managed switch ACL is blocking the port.
4. Assign PROFINET name: In PRONETA, use Assign PROFINET name with the exact string from the TIA Portal device configuration. Wait 10 seconds for the device to write the name to non-volatile memory.
5. Verify AR in TIA: TIA Portal → Online → Accessible devices. The LINK should now appear with status "OK".
6. Confirm BACnet side: From a BACnet client on the same subnet (or via a correctly configured BBMD), issue a Who-Is. The LINK should respond with an I-Am within 5–10 seconds.
7. Test point read: Read a known analog or binary point via the client. Success confirms full bidirectional reachability.

Verification and Acceptance Testing

Use the following checks to formally accept the LINK as commissioned:

Field-Commissioning Checklist

Print and complete this checklist at every PN/BACnet LINK site before handing the system over to operations:

• Article number and firmware version recorded in commissioning report
• GSDML revision in TIA project matches firmware capability
• PROFINET device name assigned and verified
• IP address assigned (static or DCP) and confirmed unique via ARP sweep
• PG subnet route to LINK confirmed with ping
• BBMD tables configured if BACnet spans more than one IP subnet
• Firewall rules allow UDP 47808 between BACnet subnets
• Online diagnostic buffer clean after 30-minute soak under simulated load
• Backup of device configuration saved to commissioning archive (LINK web UI → Configuration → Export)

FAQ