CreoView Publishing has been running fine for a couple of years, but last week, it quit. The message is "Failed to Register Windchill Server <workspace_name> --15.
Nothing has changed from a Windchill standpoint, no username or password changes, etc. The only change might be a Windows update patch that IT installed in 1/13. I am still waiting on word from them if the installed any patches. They say no patches installed .
Does anyone have any ideas what may be wrong. I have deleted the cache files as recommended in CS articles, checked the auth.properties file, etc.
It's a new workspace or an old one that causing the error?
In the past we have had some problems registering Creo with Windchill if the WS name contained the "-" character.
This article show same error you wrote above
Went through that article and other than Clean Re-Installation of latest Creo View Adapters, nothing has worked.
I can load a part in Creo from Windchill on the publishing machine with the default worker username/password.
Deleted all of the cache files.
Made sure all processes were stopped.
I have rebooted all 3 machines this morning.
Are you seeing anything in the Windchill method server logs or just in the CAD worker logs? What version of Windchill, Adapters, CAD software, etc.?
Only seeing error messages in the CAD worker logs, nothing in the 4 method server logs.
Windchill 11.0 m030 CPS06
Creo 4 M080
This setup has been working for the past 2 years and suddenly stopped and won't connect.
The Windchill server and the publishing machine can ping each other.
This is an interesting article: https://www.ptc.com/en/support/article/cs101430
If you receive the error message Failed to register Windchill server ending with the error code -15 this indicates a problem an access control issue, e.g. wrong username or password for accessing the Workspace.
That is what I was thinking from the error messages and documents. The username and password have not changed in 12 years!
The auth.properties file uses the wcadmin username and I was able to open Creo, log into Windchill with the wcadmin account and open one of the files that failed to publish on the publishing workstation. Why it won't authenticate has me stumped as it worked 3 weeks ago and nothing has changed in the meantime.
The only 2 things left to double check are if some cache file is corrupt (I deleted the .wf and .wls folders) and delete them or reload the adapters. I may end up reloading as this system is on 4.2 and we use 5.0 on the other 2 Windchill systems. When this system gets upgraded to 11.1 M020 CPS20, I will be removing the standalone publishing machine and using the Windchill server to do the publishing. This will be CV5.0 or maybe higher since we will also be on Creo 7 instead of Creo 4.
When this system gets upgraded to 11.1 M020 CPS20, I will be removing the standalone publishing machine and using the Windchill server to do the publishing. This will be CV5.0 or maybe higher since we will also be on Creo 7 instead of Creo 4.
I'd be really hesitant to run Creo directly on my Windchill server. I wouldn't want to risk a runaway Creo session consuming all of the memory and killing Windchill. I've had really good luck running the CAD workers on their own separate servers (VMs). Having multiple workers allows me to easily take one offline for updates without impacting publishing on the other ones.
I'd also suggest going to the latest Creo View Adapters available and compatible with your Windchill version. It looks like 11.1 is compatible with CVA 8.1. I've recently updated to that version and have been pleased with it so far. CVA 8.0 and later have a 'real' installer that lets you properly uninstall the previous version and remove the worker daemon service without resorting to the command line.
Back to the issue at hand, what happens if you run the worker daemon interactively instead of as a service. Does that make any difference? If so, I'd take a look at the user profile for your service account and make sure there aren't any Windchill cache related files that need to be cleaned up for that account (in the user's profile, etc.)
Since I only have 5 users and a single queue for publishing, from a resource standpoint, it makes more sense in our situation to run the publishing on the Windchill server. In the 2+ years on the other 2 Windchill systems, this has never been an issue. I do get some jobs that run for hours but the timeout settings in wvs.properties have always killed jobs that take too long.
This system has never been able to use an autostart for publishing. I have always had to log in on Monday mornings and manually start the worker daemon, then disconnect my session and let the machine run. It has always started and published jobs prior to last week.
I will plan on installing CreoView Adapters 5.0 or higher when I am back in the office later this week. This Windchill system is behind firewalls that cannot be connected remotely. I may just put CVA on the Windchill server to see if that will allow the system to autostart.
Unfortunately no. I have put off trying on that one server as it is the lowest in usage at this time and I am trying to get it updated to Windchill 22.214.171.124 and hope that provides some resolution.
Okay. We connect multiple Windchill server to the same CAD worker. I was able to connect one, but was getting authentication issue on another. They both are exact same configuration. Do you think it could be because we are connecting multiple Windchill instances to the same worker? It was working fine in before we updated Windchill. We update from 11.1 M010 to 11.1 M020.
I have test and prod hitting same Worker machine. Each worker is setup as its own virtual hostname and port even though its physically the same machine. Each worker has its down workerDaemon service. When you upgraded to M020, did you update the recipe file to match Windchill version? I can tell it works so something else is the cause.
Yeah, it there. Here are the contents:
adapter/proeCommand=C:\/Program Files\/PTC\/Creo 126.96.36.199\/Parametric\/bin\/parametric.bat
I'd also suggest going to the latest Creo View Adapters available and compatible with your Windchill version. It looks like 11.1 is compatible with CVA 8.1. I've recently updated to that version and have been pleased with it so far.
I need to provide an update to this statement. I have since discovered a serious flaw where the DXF files generated by Creo View Adapters 8.1 via Creo Parametric are corrupt. For whatever reason, the output log file is being supplied to Windchill and called the DXF instead of the actual DXF file itself. PTC is going to pull the download and replace it with an updated build, but I figured I should say something since I've been encouraging people to use this version.
I am glad you posted that. I had no idea but sure enough the post published "dxf's" are in fact the log file and not the dxf.
We just switched back to Creo View Adapters 188.8.131.52 from 184.108.40.206. We are post-publishing both pdf and dxf for drawings. The pdf is heavily used and the dxf is obviously rarely used - nobody had complained about invalid dxf yet.
Yeah, I had to roll back too and then find and republish every DXF generated since I moved to 8.1. Fortunately my publish rules include the word 'DXF' in the representation description, so it was pretty easy to locate them in the database and then feed to corresponding idA2A2 values into the CSV mass republish script PTC makes available. (See section 2 of CS211115.)
select ed.idA2A2, edm.CADName, concat(concat (ed.versionIdA2versionInfo,'.'),ed.iterationIdA2iterationInfo) AS [Version], di.description, di.updateStampA2 from DerivedImage as [di] join EPMDocument as [ed] on di.idA3theRepresentableReferenc = ed.idA2A2 join EPMDocumentMaster as [edm] on ed.idA3masterReference = edm.idA2A2 where di.classnamekeytheRepresentable = 'wt.epm.EPMDocument' and edm.authoringApplication = 'PROE' and edm.docType = 'CADDRAWING' and di.description like '%DXF%' and di.updateStampA2 > convert(datetime, '2022-02-01') order by di.updateStampA2
I just wrote a java class to do the re-publishing. It is doing the same thing as your sql query. Querying for DerivedImage's in a certain date range and sending the drawings ones back to the publisher. I just started it on the production server late this morning (11:50am) and it sent 11004 drawings for republishing. The cadworkers have currently worked through 4.4k of those so far (2:25pm). For anyone interested this is your sql query tweaked for Oracle and adding an ending date in the where clause:
select ed.idA2A2, edm.CADName, concat(concat (ed.versionIdA2versionInfo,'.'),ed.iterationIdA2iterationInfo) Version, di.description, di.updateStampA2 from DerivedImage di join EPMDocument ed on di.idA3theRepresentableReferenc = ed.idA2A2 join EPMDocumentMaster edm on ed.idA3masterReference = edm.idA2A2 where di.classnamekeytheRepresentable = 'wt.epm.EPMDocument' and edm.authoringApplication = 'PROE' and edm.docType = 'CADDRAWING' and trunc(di.updateStampA2) > TO_DATE('2021-12-27','YYYY-MM-DD') and trunc(di.updateStampA2) < TO_DATE('2022-02-10','YYYY-MM-DD') order by di.updateStampA2
It sounds like you've already cleaned up these files, but I add this to the top of the system generated 'proestartup.bat' files so they get cleaned up every time:
echo Killing any remaining processes taskkill /f /fi "imagename eq xtop.exe" /fi "username eq <computer_name>\<service_account_name>" taskkill /f /fi "imagename eq prod_dcu.exe" /fi "username eq <computer_name>\<service_account_name>" echo Cleaning up TEMP directory for /d %%x in (%TEMP%\proe2pv*) do rd /s /q "%%x" del %TEMP%\proe2pv*