Resolving TIA Portal V14 Error 0133:000002 with S7-1200 Online

David Krause12 min read
SiemensTIA PortalTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

1. Problem Summary

A field engineer reports that an Siemens S7-1200 CPU on IP 147.91.9.41 / 255.255.254.0 cannot be reached from a programming PC at 147.91.8.170 / 255.255.254.0 using TIA Portal V14. Ping to both addresses succeeds, the PLC can still be flashed with a new firmware image, yet every attempt to go online from the project tree returns:

Error code 0133:000002 – "Connection failed. The selected online target could not be reached."

The identical hardware, the identical IP configuration, and the identical Windows installation previously established a fully functional online connection with TIA Portal V13 SP1. This delta between V13 SP1 (working) and V14 (failing) is the central clue: the PC-to-PLC path is intact at L3, but the TIA V14 runtime stack cannot complete its PG handshake.

Parameter PC PLC (S7-1200)
IP address 147.91.8.170 147.91.9.41
Subnet mask 255.255.254.0 (/23) 255.255.254.0 (/23)
Default gateway (not stated) (not stated)
OS Windows 7 SP1 (64-bit) Firmware ≥ V4.x (typical for V14 era)
Tool TIA Portal V14 S7-1200 CPU 121x/1215/1217
Ping OK OK
Firmware download OK –
Online connect (TIA V13 SP1) OK OK
Online connect (TIA V14) FAIL – 0133:000002 FAIL – 0133:000002

The 0133:000002 code is reported by the TIA Portal online dialog when the S7ONLINE access point or the internal protocol driver cannot negotiate a connection with the CPU within the time-out window. The string is composed of the TIA event class 0133 and an internal sub-code 000002; Siemens documents the prefix in the TIA Portal Online & Diagnostics help as a generic "online target unreachable" condition.

2. IP and Subnet Analysis (147.91.8.0 /23)

The mask 255.255.254.0 equals a /23 prefix, which spans two consecutive /24 blocks. The arithmetic must be verified before any other step, because a /23 mismatch is the most common reason for "ping works in one direction only" symptoms.

Address Binary (third octet) Decimal Network
Network base 00001000.0 147.91.8.0 147.91.8.0/23
Network broadcast 00001001.1 147.91.9.255 147.91.8.0/23
PC 00001000.10101010 147.91.8.170 In-range
PLC (reported) 00001001.00101001 147.91.9.41 In-range
PLC (test) 00001001.00101010 147.91.9.42 In-range
PC (test) 00001000.10101011 147.91.8.171 In-range

Both reported addresses and both test addresses (147.91.8.171 and 147.91.9.42) fall inside the 147.91.8.0/23 broadcast domain, so the L3 path is provably valid. The fact that ping succeeds in both directions while the TIA handshake fails confirms that the fault is not in the IP layer but in a higher-layer service required only by TIA Portal V14.

A repeated sub-code after switching the PC to 147.91.8.171 or the PLC to 147.91.9.42 is a strong indicator that the issue is not address-related; do not waste time on DHCP reservations, MAC filtering, or ARP entries until the higher-layer checks below are exhausted.

3. TIA Portal V14 vs V13 SP1 – What Changed

TIA Portal V14 (released 2016) introduced several online-stack changes that V13 SP1 does not enforce. Each of these can produce 0133:000002 while L3 connectivity remains intact:

  1. TLS 1.2 mandatory for the PG/PC interface. V14 forces TLS 1.2 on the S7ONLINE / PNIO channel; V13 SP1 still accepts TLS 1.0/1.1. If the OS cipher suite list has been trimmed (group policy, IIS lockdown tools, antivirus web-shield), the handshake aborts silently and TIA reports the connection as unreachable.
  2. Updated S7ONLINE access point handler. V14 re-registers the S7ONLINE access point against a new set of DLLs (e.g. Siemens.Automation.Portal.OnlineAccess.dll). A residual V13 SP1 installation side-by-side can leave the access point pointing at the older Set PG/PC Interface (STEP 7) tool rather than the new TIA dialog.
  3. Windows 10 not officially supported by V14. Although the field engineer is on Win 7 SP1 (where V14 is supported), background discussion notes that V14 under Win 10 is a frequent source of 0133:000002. Always confirm the host OS against the TIA Portal V14 readme before deep troubleshooting.
  4. Firmware ≥ V4.2 requirement for new protection modes. V14 enables the "Know-how protection" and "Access level" wizards that depend on CPU firmware V4.2 or later; older firmware negotiates but may drop the connection after the first authorization request.
  5. Online diagnostics re-architecture. V14 splits online diagnostics into a separate trace service that uses an additional ephemeral TCP port (49152–65535). If a corporate firewall is filtering that range, ping and S7ONLINE will both succeed while the trace service is dropped.

Because V13 SP1 works on the same PC, items 1, 2 and 5 are the most probable root causes for the case described.

4. Root Cause Matrix for Error 0133:000002

Likely cause Symptom evidence in case Verify with Fix
PG/PC interface bound to wrong NIC Ping works but TIA fails on first attempt after reboot Start → "Set PG/PC Interface" → diagnostics Re-bind S7ONLINE (STEP 7) -> <NIC>
TLS cipher mismatch on Win 7 SP1 V13 SP1 OK, V14 fails sslscangui.exe or IE cipher view Enable TLS 1.2 client+server ciphers
Antivirus web-shield intercepting 102/49152+ Already disabled, still fails Temporarily uninstall AV entirely Whitelist ports 102 (ISO-TSAP), 443, 50000–50010, 49152–65535
Stale S7ONLINE registration from V13 SP1 Access point dialog lists duplicate entries Set PG/PC Interface → Diagnostics → Reset Uninstall V13 SP1 cleanly, then re-register V14
CPU protection level blocks V14 PG Firmware update OK but online fails Online → Accessible nodes (V13) Reset CPU to factory or set protection = "Full access incl. fail-safe"
Win 7 SP1 lacks SHA-2 chain for V14 certs V13 OK; V14 fails immediately Event Viewer → Windows Logs → Application Install KB3033929 + KB2921916 + KB3140245
Switch port blocks LLDP/multicast Multiple PLCs reachable, this one not Wireshark capture on PC NIC Enable LLDP/DCP on managed switch

5. PG/PC Interface Configuration

TIA Portal V14 uses the Set PG/PC Interface control panel applet (inherited from classic STEP 7) to map the logical access point S7ONLINE to a physical NIC. Mis-binding is the single most common cause of 0133:000002 when ping is intact.

  1. Close TIA Portal V14 completely.
  2. Open Control Panel → Set PG/PC Interface (32-bit, "Set PC interface for SIMATIC stations"). On 64-bit Windows the 32-bit applet lives in %SystemDrive%\Program Files (x86)\Siemens\Automation\Portal V14\bin as SetPgPcInterface.exe.
  3. Select Access Point of the Applications: S7ONLINE (STEP 7).
  4. In the "Interface Parameterization Used" list, pick the exact NIC whose IP is 147.91.8.170. Do not select <ISO> or any virtual adapter.
  5. Click Diagnostics. With the PLC powered, the dialog should resolve the CPU MAC and report "Module reachable".
  6. If the diagnostic returns "No target found", the binding is wrong – switch to the next NIC in the list and repeat.
On machines that previously hosted V13 SP1, the access point often points to an Intel or Realtek adapter that has since been renamed after a driver update. Always verify by MAC address, not by friendly name.

6. TLS, Cipher, and Certificate Stack on Windows 7 SP1

TIA V14 raises the minimum TLS version to 1.2 for the PG ↔ CPU protocol. Windows 7 SP1 supports TLS 1.2 only after the following updates are applied (per the Microsoft TLS 1.2 default patch):

  • KB3140245 – Update to enable TLS 1.2 as default in WinHTTP
  • KB3033929 – SHA-2 code-signing support
  • KB2921916 – TLS 1.2 in .NET Framework 4.5

Validate the registry after patching:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
  "Enabled"=dword:00000001
  "DisabledByDefault"=dword:00000000

If the host was upgraded from a base Win 7 SP1 image without these patches, TIA V14 will silently fail the handshake while leaving the IP layer untouched. Confirm by opening the certificate store (certmgr.msc) and verifying that the Siemens Automation certificate chain roots at a SHA-2 CA.

7. Windows Firewall and Antivirus Inspection

TIA V14 opens several TCP/UDP ports during a PG session:

Port Protocol Service
102 TCP ISO-TSAP (S7 communication)
34962–34964 UDP PROFINET DCP, LLDP
49152–65535 TCP (ephemeral) Online diagnostics, trace, web server
443 TCP S7-1200 Web server (if enabled)

Create inbound and outbound rules named Siemens TIA V14 PG that allow the entire 49152–65535 range, plus port 102 TCP and ports 34962–34964 UDP. On managed networks, request the same allowances on the corporate edge firewall. Disabling the antivirus "web shield" or "HTTPS inspection" component is not sufficient – the AV must be uninstalled or have its entire network filter driver disabled to confirm that it is not the culprit.

Some endpoint-protection suites (Symantec Endpoint Protection, Trend Micro OfficeScan, Kaspersky Endpoint Security) inject a Winsock LSP that silently drops ISO-on-TCP packets. Run netsh winsock show catalog and look for any non-Microsoft LSP entries before deep diving into TIA itself.

8. S7-1200 Firmware and CPU Protection

TIA V14 expects CPU firmware ≥ V4.2 for full feature parity. Mixed-version environments often show symptoms identical to those described:

  1. Open an accessible nodes search from a working V13 SP1 installation on the same PC.
  2. Confirm the CPU firmware version under Online & Diagnostics → Diagnostics → Module Information.
  3. If the firmware is older than V4.2, plan a maintenance window and flash the CPU using a V14-compatible firmware file (downloadable from the Siemens Industry Online Support portal).
  4. Verify that the CPU protection level is not set to "No access (complete protection)". In V14 this is configured under Device Configuration → Properties → Protection & Security → Access level. Set to Full access (no protection) during commissioning.
The original poster mentions that "I can flash PLC" – this proves the ISO-TSAP transport on port 102 is open. It does not prove the higher-level S7 diagnostic service is reachable, because firmware download uses a separate TIA sub-protocol that tolerates stricter firewall policies than full online operation.

9. Step-by-Step Resolution Procedure

Apply the following sequence in order. Stop after each step and re-test the online connection from TIA Portal V14.

  1. Confirm the OS patch baseline. Install KB3140245, KB3033929 and KB2921916 on Windows 7 SP1. Reboot.
  2. Re-register S7ONLINE. Launch Set PG/PC Interface → select the correct NIC → click Diagnostics → confirm "Module reachable" with the PLC powered.
  3. Add firewall rules. Allow TCP 102, TCP 443, TCP 49152–65535, UDP 34962–34964 in both directions for the TIA Portal V14 executable (Siemens.Automation.Portal.exe) and the S7DOS helper service.
  4. Uninstall the antivirus network filter driver. Use the vendor's removal tool (e.g. cleanwsp.exe for Symantec, KAVREMOVE for Kaspersky). Reboot and retry.
  5. Inspect Winsock LSPs. Run netsh winsock reset from an elevated command prompt, then reinstall the NIC driver and the TIA V14 "SIMATIC Communication Settings" component.
  6. Confirm CPU protection level. From V13 SP1, connect to the CPU → Online & Diagnostics → Protection → set "Full access incl. fail-safe".
  7. Force TIA V14 to rediscover. In the project tree: Online → Accessible nodes → Show all accessible nodes. The S7-1200 should appear with its MAC and IP. Double-click to force the handshake.
  8. If still failing, capture a network trace. Start Wireshark on the PC NIC, filter tcp.port==102 || tls.handshake, and reproduce the error. Look for an immediate FIN/RST or a TLS Alert 40 (handshake failure) within milliseconds of the SYN – this confirms cipher mismatch.

10. Verification

After the resolution, verify the fix with three independent checks:

  • Online node discovery. Online → Accessible nodes must list the CPU at 147.91.9.41 with type "S7-1200" and the correct firmware version.
  • Online & Diagnostics. Double-click the CPU → confirm that the diagnostic buffer, cycle time, and memory usage panes populate without an error overlay.
  • Download to device. Compile the project (Ctrl+B) → Download to device → Hardware and software (only differences). The download must complete without prompting for a CPU stop that is not expected.

Log the final configuration in a commissioning sheet:

PG/PC Interface : S7ONLINE (STEP 7) -> Intel I219-V (MAC 70-85-C2-xx-xx-xx)
TLS             : 1.2 client + server enabled, SHA-2 chain trusted
Firewall rules  : TCP 102, TCP 443, TCP 49152-65535, UDP 34962-34964
CPU firmware    : V4.4.2 (or current)
Protection      : Full access (no protection)
Antivirus       : Trend Micro OfficeScan – network filter driver disabled for TIA V14
Result          : Online connection OK – 0133:000002 no longer reproducible

11. Prevention and Best Practices

  • One TIA version per engineering workstation. V13 SP1 and V14 side-by-side installations are supported but require careful access-point management. Where possible, dedicate one PC per TIA major version.
  • Image the engineering PC. After successful commissioning, capture a sysprepped image so that a re-image restores the complete TLS, firewall, and S7ONLINE state.
  • Whitelist by executable, not by port. Adding firewall rules for Siemens.Automation.Portal.exe is more robust than opening port 102 globally.
  • Document the cipher baseline. Store a screenshot of sslscangui.exe output for each PC. A delta after a Windows update is the fastest way to prove TLS regression.
  • Subscribe to Siemens security advisories. Register on Siemens Industry Online Support to receive notifications for TIA Portal and S7-1200 firmware updates that may affect online behavior.

12. FAQ

What does Siemens error 0133:000002 mean in TIA Portal V14?

It is the TIA Portal generic "online target unreachable" event. TIA V14 raises it when the PG/PC interface or the S7ONLINE access point cannot negotiate a TLS 1.2 session with the CPU within the time-out window, even when L3 ping succeeds. It does not encode a specific cause; the operator must walk through the PG/PC interface, TLS, and firewall checks above to isolate the fault.

Why does TIA Portal V13 SP1 work but V14 fails on the same PC and PLC?

V14 enforces TLS 1.2, uses a re-architected S7ONLINE access handler, and opens additional ephemeral ports for online diagnostics. V13 SP1 still permits TLS 1.0/1.1 and uses the legacy ISO-TSAP path exclusively. If the Win 7 SP1 host is missing KB3140245 or if a Winsock LSP is filtering traffic, V14 will fail while V13 SP1 still completes the handshake.

Are 147.91.8.170 and 147.91.9.41 actually in the same subnet?

Yes. The mask 255.255.254.0 is a /23 that covers 147.91.8.0 through 147.91.9.255. Both addresses fall inside that range, so IP connectivity is mathematically valid and is confirmed by successful ping in both directions.

Which Windows updates are mandatory for TIA Portal V14 on Windows 7 SP1?

Install KB3140245 (TLS 1.2 default in WinHTTP), KB3033929 (SHA-2 code-signing support), and KB2921916 (TLS 1.2 in .NET Framework 4.5). Without these, TIA V14 cannot negotiate the secure channel with the S7-1200 and reports 0133:000002.

Which TCP and UDP ports must be opened in the firewall for TIA Portal V14?

Open TCP 102 (ISO-TSAP), TCP 443 (web server), TCP 49152–65535 (ephemeral diagnostics and trace), and UDP 34962–34964 (PROFINET DCP and LLDP). Whitelist the executable Siemens.Automation.Portal.exe rather than opening the ports globally to reduce attack surface.

Can I keep TIA Portal V13 SP1 and V14 installed on the same engineering PC?

Siemens supports side-by-side installation, but the S7ONLINE access point will register entries from both versions. Always open Set PG/PC Interface and confirm that S7ONLINE (STEP 7) points to the NIC used by the TIA version you intend to launch. A duplicate or stale binding is one of the most common causes of 0133:000002 in mixed-version workstations.

Back to blog