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,
C:\Program Files\PTC\Creo 3.0\M120
In your script, you must assign the environment variable PRO_COMM_MSG_EXE. This will likely point to PRO_DIRECTORY\Common Files\x86e_win64\obj\pro_comm_msg.exe
On to actual scripting:
You must first initiate a connection to Creo. This should sound familiar to any J-Link programmers.
You then obtain a session object from the connection. From here, you can open models, access the active model, and the sky is the limit from there.
After you are done, you must disconnect from the session. It seems that the VB API async server only handles a certain amount of handles at a time, and if you don't close out, you will hit a point soon where you cannot connect unless you restart Creo.
Figuring out the API calls is confusing. You may throw PRO_DIRECTORY\Common Files\vbapi\vbapidoc\index.html in a browser to figure out the base VB API calls. Translating them to Powershell is a bit more confusing, you may need to create parent objects to reference their calls. These will all be COM objects. I use a script like the following to dump out all COM Objects on the machine and I just Ctrl-F through there to figure them out.
gci HKLM:\Software\Classes -ea 0| ? {$_.PSChildName -match '^\w+\.\w+$' -and
(gp "$($_.PSPath)\CLSID" -ea 0)} | ft PSChildName
The following is an example script that expects Creo to be open. It links in, gets the current model, runs a mapkey, and disconnects. In theory you can have the VB API script start Creo totally on its own, you can in theory script out workers in this manner.
# 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)
