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