cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

How to get CAD Worker to restart and connect consistently

mdigman-2
2-Guest

How to get CAD Worker to restart and connect consistently

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.
    TaskScheduler.jpg
  3. Modify the SolidWorks worker to run a startup script. Open the swworker.bat file, and add the highlighted text.
    swworker mods.jpg
  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.

 

6 REPLIES 6
ascorupco
6-Contributor
(To:mdigman-2)

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
13-Aquamarine
13-Aquamarine
(To:ascorupco)

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.

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:

avillanueva_0-1647517036300.png

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

TomU
23-Emerald III
(To:avillanueva)

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
13-Aquamarine
13-Aquamarine
(To:TomU)

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
23-Emerald III
(To:HJ1)

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

Announcements