Hi -- first off, thanks for TiaCommander; setup and licensing were smooth and the tool itself works well. I've hit a wall on version selection, though.
Environment: TiaCommander v2.30.3 (portable), Windows 11 Pro, TIA Portal V17, V18, and V21 installed side by side. All Openness prerequisites in place (Openness user group, .NET 4.8).
Problem: My work is in a V17 project, but TiaCommander always binds the V18 engine, no matter which project path I pass to session open. Opening a .ap17 project then fails with the Openness compatibility error: "Project ... with version 'V17' can only be opened with a software product of the same version. The current product version is 'V18'." I couldn't find any way to influence which version the resolver picks -- no MCP tool parameter, nothing in settings, and nothing in the docs covering multi-version installs.
What I ruled out:
- Pre-launching TIA Portal V17 myself and using
session connect doesn't work as a workaround -- TiaCommander doesn't see externally launched instances at all (get_state reports TIA_NOT_RUNNING while the V17 process is verifiably running).
- Your own log confirms the binding:
tiacommander-<date>.log records Siemens API: C:\Program Files\Siemens\Automation\Portal V18\PublicAPI\V18 [registry] on every startup -- never V17 or V21.
- The Openness whitelist entry (
HKLM\SOFTWARE\Siemens\Automation\Openness\...\Whitelist\TiaCommander.exe) exists only under 18.0 on this machine -- TiaCommander has never authorized against the 17.0 or 21.0 engines.
Request: a way to pin the target TIA Portal major version -- a setting, CLI argument, or environment variable would all work -- or better yet, have the resolver pick the version matching the project file being opened. Multiple TIA versions side by side is the norm on engineering workstations, so silently binding one version currently makes every other installed version unreachable.
Happy to share full logs or registry findings, or test a build on this machine
Hi -- first off, thanks for TiaCommander; setup and licensing were smooth and the tool itself works well. I've hit a wall on version selection, though.
Environment: TiaCommander v2.30.3 (portable), Windows 11 Pro, TIA Portal V17, V18, and V21 installed side by side. All Openness prerequisites in place (Openness user group, .NET 4.8).
Problem: My work is in a V17 project, but TiaCommander always binds the V18 engine, no matter which project path I pass to
session open. Opening a.ap17project then fails with the Openness compatibility error: "Project ... with version 'V17' can only be opened with a software product of the same version. The current product version is 'V18'." I couldn't find any way to influence which version the resolver picks -- no MCP tool parameter, nothing in settings, and nothing in the docs covering multi-version installs.What I ruled out:
session connectdoesn't work as a workaround -- TiaCommander doesn't see externally launched instances at all (get_statereportsTIA_NOT_RUNNINGwhile the V17 process is verifiably running).tiacommander-<date>.logrecordsSiemens API: C:\Program Files\Siemens\Automation\Portal V18\PublicAPI\V18 [registry]on every startup -- never V17 or V21.HKLM\SOFTWARE\Siemens\Automation\Openness\...\Whitelist\TiaCommander.exe) exists only under18.0on this machine -- TiaCommander has never authorized against the 17.0 or 21.0 engines.Request: a way to pin the target TIA Portal major version -- a setting, CLI argument, or environment variable would all work -- or better yet, have the resolver pick the version matching the project file being opened. Multiple TIA versions side by side is the norm on engineering workstations, so silently binding one version currently makes every other installed version unreachable.
Happy to share full logs or registry findings, or test a build on this machine