I’m wondering how everyone is handling cases where SOLIDWORKS becomes unresponsive and the only thing to do to continue the program is to kill the SOLIDWORKS instance and start a new one.
One approach is to use a timeout but this opens the door for race conditions between your main thread and any background timeout thread.
@artem @PeterBrinkhuis @BigCrazyAl
Programmatically I’m not sure but in the everyday world I usually try to let SWx finish the task if possible, unless it’s so obvious that it’s just not going to finish. From experience with a large group of users tracking this thought, it appears that once you crash most often without a computer reboot, it’ll crash in that same amount of time of sooner for the next crash.
Meaning if I started working at 8 am and crashed SWx at 11 am, I’m fairly confident that without rebooting the computer the next SWx crash will be under the 3 hours that it took for the last crash to occur.
My disclaimer to this is that we did this test/tracking a few years ago so it may different in newer releases of SWx.
The only case where that may apply is a stand-alone program that relies on Solidworks to keep running. Up to this point, I have more experience with macros and add-ins so this is somewhat unexplored territory for me.
With that said, my first thought would likely be to use a timer to perform a query every 15-30 seconds to the SldWorks interface to return something simple like the GetBuildNumbers2. If that fails to return before the timeout, then I would try to safely terminate any running threads and restart a new SolidWorks instance.
The “safely terminate any running threads” is where I would have to do a lot of research since I’m not terribly well versed in managing threading. I’m sure others have more input in that area.
When we were setting up automated pdfs and dxfs through PDM we started with the Solidworks PDM Task Add-In. Got it set up and it was ok, but would often take over a minute to run the pdf, so some users were running the task over and over or calling to say the pdf failed. Since I also had to add the pdf and dxf functionality for Solid Edge as well I decided to have my add-in do both SE and SW and forget about the SW PDM Add-in. In doing so I learned that a big reason the SW add-in took so long is it would start up SW instance for each task. I was told they do this because is was the most straight forward way to deal with the memory leaks and crashes. The task setup tool offers the ability to retry tasks x number of times every y minutes…
Something that comes to mind is, the reliability of your program as it’s manipulating SW is dependent on the consistency of what’s being sent form the user. In my case of pdf/dxf task, I added some sanity checks on the files. For example a slddrw file that’s over 400MB isn’t worthy of a pdf in our case; users shouldn’t be making the drawing that big, but it happens and it crashes the task host. So try to filter out the bad inputs (whatever it may be) before letting them crash SW.
The problem is that if your SOLIDWORKS is unresponsive, your program is and this check every 15-30 seconds is not possible. This might be possible from other a background but still create race conditions.
Yeah, the more I think about it, the more this will only tell you when solidworks stops responding. I’m sure there’s a way to eliminate the possibility of race conditions, but that’s far beyond me at this point.
Take a look at the Polly Framework with a timeout policy. I am using this in a Batch+ as I need to handle timeouts and crashes to restart SW and continue. You can look at the source code here
This polly thing is a lifesaver. With a few modifications, I’m able to handle timeout without race conditions. Thanks a lot @artem.