How to get CAD Worker to restart and connect consistently

[mdigman-2]

I have had lots of issues through the years trying to get CAD workers to run consistently. There are various issues involved, including Windows fault messages, SolidWorks debug messages, and uwgm_clients left running after CAD application has a bad exit.

This is what I am currently using for SolidWorks, and it has been working without an issue for a while. I thought I would share it in case it helps anyone else. I will assume that you have a SolidWorks worker setup.

1. Setup a Windows 10 machine to auto logon on boot. In most cases I suggest doing the auto login using a local account, not a domain account. There are registry settings on how to do this. Google that. For companies that have a policy statement you need to agree to before the login will complete, ask the IT department to create an OU that disables the policy statement, and put the publishers in that OU.
2. Set the Worker Daemon to run in the foreground. I use Task Scheduler to start the application on login. With all the security update in Windows it is almost impossible to get SolidWorks to run as a service, even with the check box to allow it to interact with the desktop. You have to mess with registry settings to view the interactive desktop. And now you can't get interactive keyboard or mouse control, so SolidWorks will just sit there waiting for you to accept the license agreement and other dialog boxes, but you can't because the mouse doesn't work anymore. Just give up on that and run it in the foreground.
   
3. Modify the SolidWorks worker to run a startup script. Open the swworker.bat file, and add the highlighted text.
   
4. Add the swstartup.bat and swstart.ps1 files to the worker directory. The SWSTARTUP.BAT file runs the SWSTART.PS1 powershell script with elevated access, and then deletes all the working directories. The Powershell script basically looks for any running process that didn't close, tries to get them to exit nicely, and then just kills them. If you find that you have other programs that you need to close, or you want to tailor this for other CAD adapters, just modify the $HashTable.Add lines in the script. Add the name of the process you want to kill, and a message for the program to print so you know which one it is working on. The script also spits out a list of the names of the running processes, so you can a) check to see what the name is, and b) see what is running when the script is done to make sure it is killing what you expect it to kill.

For me, the main issues with getting the SolidWorks worker to restart is one of two issues; a process is still running, such as the uwgm_client, which prevents the new SolidWorks instance from attaching to it's own, or there is garbage in the *\run, \.wf, or \.ws directories that prevents the worker from connecting, resulting in any number of errors. The new, favorite error in SW2019 with 11.0 M030 CPS 16, for instance, is:

Downloading file using WWGM :

sw2pv Error:13032: WWGM worker failed to sync file "256820-00_Rev01.SLDPRT"
WWGM ERROR: Open of file "C" failed

Clearing the three directories makes this error, and many/most/all others, go away.

Hope this helps anyone who is having problems with SolidWorks workers.

[ascorupco]

thanks for the workaround; to be honest in the last few years we are using more and more workarounds rather than valid solutions even with TSAM and all the "support" from PTC - i need to take long vacation from this as this is very frustrating and PTC never at fault, look at Windows , looks at cloud providers, look at network solutions, too many loose ends....but we are "DOING great" 🙂

[HJ1]

Man, that post is 1,5 years old and still current as were experiencing everything and all related again...  😄  I'm wondering whether there is anything better yet than trying to do this publish thing on virtual Win 10 machines? Just a ridiculous amount of time spent on monitoring publish.

[avillanueva]

There are just too many points of failure. Windows services, FTPS, firewalls, scrips, queues, license servers, crashes, CAD agent out to lunch. The biggest issue is when a worker fails to start, it is marked and does not try again. That's why I've tried to build in redundancy. I have notice stability differences between Win 10 VMs and Win Server 2019/6 VMs. Process is more fault tolerant on Win Server but that does not work for SW publisher. I pop in daily to clear stuff like this:

I wish they hadn't dropped support for Linux since it would have made publishing a whole lot easier. 

[TomU]

I'm doing all Solidworks publishing on a Windows Server 2019 cad worker VM.  Rock solid.  No issues at all.  I don't use FTP, just a shared folder for transferring files. The worker daemon is running as a Windows service.

[HJ1]

Yes, this is something we should consider too since the Windchill servers need to be upgraded soon anyway.

Which versions of SW, WWGM, Adapters..?

[TomU]

Currently running Solidworks 2021 SP05.1, Creo View Adapters 8.1.0.0, and Windchill Workgroup Manager 12.1.0.0.

[abhishekarya]

Hi Tom,

We are trying to setup CAD Worker for Solidworks on Server 2019 as well, you said it works rock solid, how long you have been running it for? PTC compatibility doesn't show the support of WGM/CAD Worker for Solidworks clearly on a Server OS, any insight would be helpful

[Ajit_Kulkarni]

Hello,

We are also on SW 2021, WGM 12.1, and Windows server 2019. The overall architecture is rock solid. We have been using a similar configuration (just version difference) for more than 5 years now.

We faced issues while daily publishing. Tow mainly 1. Failed to start SolidWorks , 2. unable to get SolidWorks UWGM COM Helper.

Because of these the worker goes down but still accepts the Windchill queue entries. We have developed a customization that overcomes this and restarts workers gracefully. 

Regards

Ajit

[HJ1]

@Ajit_Kulkarni 

Ajit,

Sorry my English but could you confirm,

this  "2. unable to get SolidWorks UWGM COM Helper." you still have with workers on Win server 2019?

If this issue is also with the Win server, what's then "rock solid" compared to Win 10?

As it is, that is the only issue we have with a worker run as a service on Win 10. If you run it in the background there's an issue equally frequently with some .dll error showing up in Win error log and I suspect it's all the same in the end, but maybe not... either way, you end up restarting the worker. Maybe not every day, but then again maybe several times a day...

[MikeLockwood]

In the past (same company as Ajit Kulkarni), I spent many, many hours studying this.  Posting some comments here - hopefully will help others.

The default Solidworks install results in SW presenting various UI's to EACH user who launches it on a given host.  These include accepting the license agreement and accessing the community forum.  These UI's popping up can prevent SW fully launching for the CAD worker.

When each user accepts the license agreement, checks the box to not show the forum UI, etc., it's stored in the registry for that user, but doesn't affect the "default user" which is utilized on a server for publishing.

We were successful editing the registry for the default user directly on these things, using the registry changes for a real user as a guide (under HKEY_CURRENT_USER\SOFTWARE\...).

It's one of the key differences between the server and workstation OS.