What line does the error occur at?
The RPC Disconnected error means that the pointer to the COM object is no longer valid, usually a ModelDoc2 object that no longer exists (model closed) or a SolidWorks variable that has been lost (SolidWorks closed or error in SolidWorks COM functionality, try re-installing SW).
I'm not sure if it occurs on any one line or not, since I can't replicate the problem on demand.
The problem occurs on all our workstations, and all those were just recently built, so I don't think a reinstall would help.
I'm not familiar with the inner workings of COM. Are there any 'gotchas' or things I could check my code for to prevent COM related problems?
If you want to email me your code I will find the bug for you. email@example.com
I'm getting the same RPC_E_DISCONNECTED error in my add-in and in my stand-alone app. It's seems to be occuring randomly, yet I'm sometimes able predict when it's going to happen as if it was occuring periodically. Let me give you all the details:
The error is thrown exactly while processing the code line comprising the Face2::GetTessTriangles method. Calls to SW objects before, or even after, the faulty code line work fine. Basically, what I'm trying to do, it's getting a body's bounding box with good precision, what the various GetBox methods from the API can't do.
Here's the funny part. If I change the image quality (SldWorks::SetTesselationQuality) from fine (90) to coarse (10), the error still occurs, but less frequently. Also, given a constant image quality index, complex parts (large number of complex faces) won't be processed at all, whereas simpler parts willfail systematically 1 time out of 2, and even more simpler parts (prismatic with holes) will fail systematically 1 time out of 4.
This behaviour have been reproduced on at least three different computer, all working on Windows XP 32bit and with SW 2009 Sp3 freshly installed. I'm coding in VB .NET with Visual Studio 2005. It's occuring with the release version of my add-in, not while debugging.
The issue doesn't have exactly the same behaviour weather I'm running the add-in or the .exe. With the add-in, the part's processing just fails and SW remains open. With the .exe (batch program) though, SW crashes and SW Rx is launch.
The thing is that I need the body tesselation and the fastest way to get it is through the graphic display tesselation with a custom image quality index. I've used the SW Tesselation object before, but it slows down my .exe real bad.
So what could be the problem? My take is that SW API is not that robust, and the COM connexion is somewhat lost for memory or timeout reasons. But since I'm no COM or for that matter SW API expert, I'm reaching to you guys to find a glimpse of light on this cloudy mess.
Thanks a lot!
I have had the same problem some time back and I attributed it to SolidWorks API itself. Later, I found that the problem was in my code itself. This issue occurs when we do some operation on the body such that the faces get refreshed and hence the Face object itself does not point to the correct value. I have the following suggestions: -
- When you traverse faces of a body and generate tesselations, do not perform any operation on the body such that the faces can get refreshed. Instead, you can select the face and perform the operation outside the loop.
- Use safeEntity object to get the corresponding entuty from the face and use this entity to generate back the face object wherever required. This ensures that you have the correct face object even if the body is refreshed.
In addition, you should always call Face2::getTesselationCount() before calling Face2::getTesselations().
Hope this helps!!!
Thanks for the suggestions, but none apply to my issue.
Only once the temporary body is copied and a transformation is applied that I get to each faces to get the tesselation triangles. No operation is applied to the body while going through all of the faces. And getting the tesselation of a temporary body is doable : I've done it before.
And as for getting the tesselation count beforehand, it doesn't change a thing. I feel like I have a real head scratcher here.
I picked one example from SolidWorks help and made it a macro. The macro is attached herewith.
I think it does exactly what you are trying to do. Kindly check this macro.
If you still have the issue, please share your code and I can find the issue.
Hope it helps!!
Antoine.swp.zip 7.8 KB
I'm aware of that example. I can asure you, I went through SW API Help a couple of times now. And I can't post my code on-line: IP issues.
My issue must be a coding issue beyond SW API. I've isolated the faulty code from my addin and have put it in another one to make sure it does just what I need it to do... And everything's fine. Can't blame it on SW API anymore.
For everyone of you out there, is there a limit on the number of pointers SW can safely manage as a COM server before it becomes instable ? I wonder if that's part of my problem...
I had similar issues. Safe Entity makes sure the pointer to the enties is not destroyed when the body is rebuilt/ or solidworks refreshes its references for other reasons.
Using Safe entities was the correct way to go for me.
I'm developing a plug-in for solidworks in c# and I have the same error ("The object invoked has disconnected from its clients").
I have tried to use the safe entity, but it doesn't resolve my problem (i.e. the created entity is always null).
In my case the error occurs when I try to access at the faces of a body resulting from the interference detection.
Below a sample of my code:
var swAssemblydoc = (AssemblyDoc) swModelDoc
var pIntMgr = swAssemblydoc.InterfaceDetectionManager;
var vInts = (object)pIntMgr.GetInterferences();
foreach(var interference in vInts)
var body = (Body2)interference.GetInterferencebody();
if(body != null)
var face = (Face2)body.GetFirstFace();
while (face != null)
var entity = (Entity)face;
var safeEntity = entity.GetSafeEntity();
... here I call a procedure to extract the surface parameters of the face associated with safeEntity but it is null ...
face = face.GetNextFace();
thus my problem is double
- The safeEntity that I get is null while the associated face no.
- Trying to create the safe entity the error "The object invoked has disconnected from its clients" occurs.
Have you any idea what I wrong using the safe entity?
That error is always because the com pointer is pointing to a disposed object, so you need to make sure you have the correct pointer. The line it fails at is usually containing the invalid com pointer, but not always.
This can rarely happen when SolidWorks API fails internally usually due to a bad installation, and you get a RPC_DISCONNECTED error on the SldWorks.SldWorks object itself.
Not much you can do other than make sure you are coding correctly and creating/disposing of the com objects correctly as you go.
I have also faced a similar problem. I have a .exe file which is to be executed. During this process, SolidWorks has to be kept open.
If not an "Automation Error:...." occurs and then the error description states that "The remote server is not available."
If I keep a SolidWorks file open, then my Macro works fine. But when I close the SolidWorks File I get a "Click Ok to Terminate......<Error Description>".
My work is not affecte, but this error occurs.
Can you guide me on this ?
Thanks in advance
If you can provide a little more detail on what you code is doing I can help. Sounds like you are getting the SW objects initially, doing some work on them and changing them, or altering components etc.. and the pointers will change so the errors will occur.
I think your problem is with the fact that as soon as you close solidworks application, the COM pointer pointing to sldWorks::Sldworks does not exist. Hence the error.
If you keep SolidWorks open, the pointer is intact and hence you face no issue.
The best choice you have is that you hide the sldworks application. This can be done using swapp.visible = false.
Hope it helps!!!
In my macro, I retrieve all the SolidWorks Documents present in a Folder. I need to update the Custom Properties to these Files.
I open each file (using the SldWorks.SldWorks Object), update the properties and then close each document (using the same SldWorks.SldWorks object).
I donot Quit/Close the Application Object.
Still the problem persists
Can you please guide me on the same?
If you can share your macro, I shall fix the problem and update you with the same.
Please mail me your macro at rajat[at]avongroups.in
If you use default template your addin is switching modeldoc2 when you change opened doc. So if your module is using same modelDoc2 as addin.Your modelDoc2 will be disconected each time you change active doc. It's only an idea, but you can look on it.
In program nothing is random ;>