Thought I'd give back a bit to the community, one secret weapon that I've been leveraging for quick and dirty automation is to access the asynchronous VB API through PowerShell. VB API is a .NET construct, so it's accessible through VB, C#, as well as PowerShell. API wise, it is almost 1:1 with the base J-Link package, so you are not missing out on much. You will not have Toolkit functionality, but you can in theory create Toolkit DLLs to load in via config.pro that you can invoke via the VB API.
The convenience of using PowerShell is that it is deployed by default on all machines Win7+. You may run into some compatibility issues with Powershell V2, since that was a rather primitive version compared to what we have today. Win10 deploys with Powershell 5 and above.
It is also a shell environment. You do not need to compile anything or open any special program, you can literally link up in a new shell window and immediately start piloting Creo.
So far I can pretty much create a quick one off script on a network drive, point a user to it, and immediately have them running my automation.
To link up, you must ensure you have the VB API installed with Creo.
I'll refer to the loadpoint of Creo Parametric from here on out as PRO_DIRECTORY. This is, for example,
gci HKLM:\Software\Classes -ea 0| ? {$_.PSChildName -match '^\w+\.\w+$' -and
(gp "$($_.PSPath)\CLSID" -ea 0)} | ft PSChildName
# Get path of running Creo executable $proc = Get-Process | Where-Object {$_.ProcessName -eq "xtop"} if ($proc -eq $null) { Write-Output "Running Creo process (xtop) not found"
Write-Output "Press any key to continue..."
Read-Host exit } $pc_path = $proc.Path -replace "xtop.exe", "pro_comm_msg.exe" $Env:PRO_DIRECTORY = $proc.Path.TrimEnd("xtop.exe") $Env:PRO_COMM_MSG_EXE = $pc_path # Check if VB API is registered. try { $testasync = New-Object -ComObject pfcls.pfcAsyncConnection } catch { Write-Output "VB API not yet registered on this machine, performing first time setup..." $vb_path = $proc.Path -replace "Common Files(.*)$", "Parametric\bin\vb_api_register.bat" Start-Process -Wait -FilePath $vb_path } # Initiate connection to Creo. try { $async = New-Object -ComObject pfcls.pfcAsyncConnection $connection = $async.Connect($null, $null, $null, $null) $session = $connection.Session } catch { $_ Write-Output "Could not connect to Creo session." Write-Output "Press any key to continue..." Read-Host exit } $session.GetActiveModel() $session.RunMacro('~ Command `ProCmdRibbonOptionsDlg` ') $connection.Disconnect($null)
Hi,
thanks for sharing your knowledge 🙂
Note: To prevent displaying emoticons inside code, use Insert Code button ... </>.
Noted, corrected above. Thanks for the tip!
For what it's worth to you and any other users, I've been trying to automate Creo for a few years now, and your post finally explained how it worked.
Using your code to show all the COM Objects to determine which proper Powershell classes correspond to the classes used in the vbapidoc and vbug.pdf is the only way to get anything to work.
Also, your Powershell code to connect and disconnect really helped me get off the ground, too. I couldn't even make use of any of the information I was reading in the documentation since I could not even get it to connect first! There was no way for me to know if my VB API installation was wrong, or if I messed up changing the PATH variable, or if something else was going on. It turns out that I was simply not using the Powershell versions of the classes.
Thank you for posting this information. Thanks to your post, I have already implemented updating tables and parameters via Powershell.
PTC really needs to put this info in the vbug.pdf or something.