Community Tip - You can change your system assigned username to something more personal in your community settings. X
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.
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.
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" 🙂
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:
I wish they hadn't dropped support for Linux since it would have made publishing a whole lot easier.
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.
Yes, this is something we should consider too since the Windchill servers need to be upgraded soon anyway.
Which versions of SW, WWGM, Adapters..?
Currently running Solidworks 2021 SP05.1, Creo View Adapters 8.1.0.0, and Windchill Workgroup Manager 12.1.0.0.
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
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
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...
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.