Resolving TIA Portal V13 License Error at First Execution

The TIA Portal V13 (without Service Pack 1) engineering suite, when combined with WinCC Professional V13 and the Automation License Manager (ALM), can produce a recurring license error on the very first launch of the IDE. The error blocks access to SIMOTION configuration editors, PLC code blocks (FC/FB/OB/DB), and WinCC HMI pages. Closing and reopening TIA Portal — without a Windows reboot — clears the condition. The root cause is a startup race between the TIA Portal user interface and the ALM Windows service, compounded by an outdated ALM V5.3 distribution. This article documents the proven field fix: switching the ALM service startup type to Automatic (Delayed Start) and patching ALM to Service Pack 2 / Update 2.

1. Problem Statement

The reported defect follows an exact, repeatable sequence:

1. Boot Windows 7 (32-bit or 64-bit). The ALM service is already active because it is configured with Automatic startup.
2. Launch TIA Portal V13. The project opens normally.
3. Select any one of these editor entry points:
   • SIMOTION configuration (under "Devices & Networks")
   • PLC editor — opening a Function (FC), Function Block (FB), Organization Block (OB), or Data Block (DB)
   • WinCC Professional — opening an HMI page in the graphics designer
4. TIA Portal returns a license error dialog and refuses to open the requested editor.
5. The user closes TIA Portal completely (no reboot), relaunches it, and every editor opens without error.

The condition is 100% reproducible on first launch after a Windows logon. Subsequent launches in the same Windows session are always clean.

2. Affected Software Stack

Engineering stations that have been upgraded to TIA Portal V13 SP1, V14, V15, V15.1, V16, or later do not exhibit this defect because the ALM runtime shipped with those releases is the patched V5.3 SP2 Update 2 (or later).

3. Symptom Catalog

The license error dialog shows one of the following strings, depending on which feature triggered the licensing check:

• License error - No valid license found for TIA Portal Engineering
• Cannot start SIMOTION Scout. The license for "SIMOTION" is missing or invalid.
• WinCC Professional: A license is required to edit the HMI page.
• License error opening FC/FB/OB/DB. Check Automation License Manager.

All four messages share the same internal Siemens error code range and are issued by the same ALM client API call (SLScsAPI.GetLicense()) returning SLERR_NO_LICENSE even though a valid license key is physically present on the local license server.

4. Root Cause Analysis

The Automation License Manager on the engineering station is implemented as a Windows service named ALMService (display name: "Automation License Manager Service"). TIA Portal V13 communicates with this service over a local named pipe (\\.\pipe\ALM_PIPE) using the Siemens License Server Client API.

On a fresh Windows logon, the following race condition occurs:

1. Windows starts ALMService in Automatic startup type — meaning it begins during Phase 1 of Windows service initialization.
2. ALM V5.3 (pre-SP2) attempts to enumerate all installed license containers (USB dongles, CF cards, soft containers in %ProgramData%\Siemens\Automation\Licenses) and bind them to the ALM_PIPE endpoint.
3. The container enumeration takes 5-15 seconds on a typical workstation, during which the service appears to be running (SCM > Services > Status = "Started") but the named pipe is not yet accepting calls.
4. The user double-clicks the TIA Portal shortcut. The TIA executable is fast — the IDE initializes in 2-4 seconds — and the first editor it opens issues a license check immediately.
5. The SLScsAPI.GetLicense() call hits the not-yet-bound ALM_PIPE, returns SLERR_NO_LICENSE, and the dialog appears.
6. By the time the user closes and reopens TIA Portal (typically 10-20 seconds later), the ALM service has finished binding its containers, and the license check succeeds.

This timing window is the entire defect. ALM V5.3 SP2 Update 2 includes a fix where the service transitions its SCM status from START_PENDING to RUNNING only after the named pipe is bound, eliminating the race. TIA Portal V13 SP1 and later bundle the patched ALM.

5. Resolution Path A — Service Startup Configuration

This is the most reliable field workaround and requires no installation. It changes the ALM service to start 2 minutes after Windows reaches the desktop, giving the platform enough time to stabilize before the license infrastructure is asked to serve requests.

5.1 Prerequisites

• Local administrator account on the engineering station
• Access to services.msc (built-in Windows 7 console)
• TIA Portal V13 closed (no TIA process running)

5.2 Procedure

1. Press Win + R, type services.msc, press Enter.
2. Scroll to the service Automation License Manager (internal name ALMService).
3. Right-click → Properties.
4. Change Startup type from Automatic to Automatic (Delayed Start).
5. Click Apply, then OK.
6. (Optional, for immediate effect on the current session) Right-click the service → Restart. Do NOT use Stop + Start in this order — restart is atomic.
7. Close services.msc.
8. Launch TIA Portal V13. Confirm that opening a PLC DB, a WinCC HMI page, and the SIMOTION configuration all succeed on the first attempt.

5.3 What "Delayed Start" Does

Windows 7 implements the Automatic (Delayed Start) startup type as follows: the SCM marks the service as AUTO_START but defers the actual StartService() call by a kernel-defined interval. The default delay is 120 seconds for client SKUs and 0 seconds for server SKUs (the delay can be tuned by the AutoStartDelay registry value under HKLM\SYSTEM\CurrentControlSet\Control).

By the time the ALM service is asked to start, the user has not yet reached the TIA Portal icon — the Winlogon desktop is still being populated, the user is typing credentials into the TIA Portal splash credentials dialog, and the IDE itself takes another 5-10 seconds to reach its first editor-open event. The race is eliminated.

6. Resolution Path B — Patch Automation License Manager to V5.3 SP2 Update 2

The root-cause fix is delivered in ALM V5.3 SP2 Update 2, available from the Siemens Industry Online Support portal. The installer patches the service binary almservice.exe and the named-pipe server logic so that SCM RUNNING state is published only after the pipe is bound.

6.1 Prerequisites

• Local administrator rights
• Stable internet connection (installer is approximately 180 MB)
• All TIA Portal and WinCC instances closed
• License keys backed up (exported via ALM UI or copied from %ProgramData%\Siemens\Automation\Licenses)

6.2 Procedure

1. Navigate to the Siemens Industry Online Support entry ID 114358.
2. Download ALM_V53_SP2_U2.exe (or the build version published for your region).
3. Right-click the installer → Run as administrator.
4. Follow the installer wizard. Accept the default install path C:\Program Files (x86)\Siemens\Automation\ALM\.
5. When prompted, allow the installer to restart the ALM service. Do not select Reboot Windows — the ALM update does not require a full reboot.
6. After installation, verify the new version: open ALM UI → Help → About. The reported build must be 5.3.2.2 or later.
7. Revert the service startup type from Automatic (Delayed Start) back to Automatic (no longer required, but recommended for a clean state). Restart the service once.
8. Launch TIA Portal V13 and confirm the error is gone.

7. Diagnostic Procedures

Use these procedures to confirm the diagnosis before applying any fix.

7.1 Service Status Probe

Open an elevated command prompt and run:

sc query ALMService

Expected output fields:

Note that the SCM status is identical in both cases. The defect is invisible to sc query. This is why the issue is hard to diagnose from service status alone.

7.2 Named-Pipe Probe

From an elevated command prompt, enumerate the named pipes owned by the ALM service:

powershell -Command "Get-ChildItem \\.\pipe\ | Where-Object { $_.Name -like '*ALM*' }"

On a healthy patched system, the ALM_PIPE endpoint is present within 1-2 seconds of service start. On a defective V5.3 pre-SP2 system, the endpoint may take 10-20 seconds to appear, during which TIA Portal license checks fail.

7.3 TIA Portal Diagnostic Trace

TIA Portal V13 writes license-trace data to:

%LOCALAPPDATA%\Siemens\AutomationLogs\TIA_Portal_<timestamp>\LicenseTrace.log

Open the trace file. Look for these markers:

SLScsAPI.GetLicense(<feature>) -> SLERR_NO_LICENSE
PipeConnect(\.\pipe\ALM_PIPE) failed: 2 (The system cannot find the file specified.)
Retrying license check after 500 ms...
SLScsAPI.GetLicense(<feature>) -> SUCCESS (second call)

The first-call failure followed by second-call success on the same feature is the diagnostic fingerprint of this defect.

8. Verification Tests

After applying either Resolution Path A or B, perform the following three checks. All three must pass on the very first launch of TIA Portal in a freshly rebooted Windows session.

1. PLC block open test: Open the project navigator, expand Program blocks, double-click any FB. The LAD/FBD/ST editor must open without a license dialog. Repeat for an OB1 and a DB100.
2. WinCC HMI test: Expand HMI → Screens, double-click any screen. The graphics designer must open, and the screen canvas must render within 3 seconds.
3. SIMOTION configuration test: In the project tree, double-click Devices & Networks, then the SIMOTION device. The SIMOTION configuration editor must open without a license error.

Perform this sequence 5 times across 5 cold reboots to confirm 100% reliability before declaring the workstation service-ready.

9. Troubleshooting Matrix

10. Prevention and Best Practices

• Standardize on TIA Portal V13 SP1 or later. The defect is fully addressed in the SP1 release. New engineering stations should never be deployed with bare V13.
• Bake ALM V5.3 SP2 Update 2 into the OS image. If TIA Portal V13 must be retained for compatibility with legacy projects, deploy ALM V5.3 SP2 Update 2 as part of the standard image.
• Apply the Delayed Start setting via Group Policy. Use a GPO startup script to set HKLM\SYSTEM\CurrentControlSet\Services\ALMService\Start = 2 (delayed automatic). This survives most re-imaging and cloning workflows.
• Monitor ALM service bind latency. Use a PowerShell-based health check that runs at logon and logs the time between ALMService START and the appearance of ALM_PIPE. Latency above 5 seconds should trigger an alert.
• Document the workaround in commissioning procedures. Field engineers should treat the Delayed Start setting as a mandatory post-install step until the ALM patch is deployed.

11. Related Siemens References

For deeper technical context, consult the official Siemens Industry Online Support entry:

• Siemens Support Entry ID 114358 — Automation License Manager V5.3 SP2 Update 2

FAQ