API - Stability and reliability of VBA Macros, Addin and Standalone

Macro
, ,
1

Hello

Being unfortunately very disappointed with the stability/reliability of the MyCADtools tools in a PDM environment on large assemblies with + a lot of external references,

I'm currently developing a Python application supported by a lot of VBA macros that uses the solidworks API.

So I'm coming to you today to get the programmers' feelings on the stability and reliability of these tools.

By this I mean: Does it tend to crash/freeze SW? Does this often cause standalone apps to crash?

When you start a treatment on a large package of parts, is there a chance that some of them will not be taken into account?

Indeed, I don't know how MyCAD tools are programmed, but it is clear that they rarely complete their task, and that when they have reached the end without crashing, some of the parts are often lost.

 

So I started to code a simple marco excel that opens the files one by one whose PATH is in a column.

I notice that I get random behavior there too.

Do you think this is due to a programming problem with my own code, or the SW API is natively unreliable at all??

I'm new to VB and API sw but I already program in many different languages...

Thank you for your answer

The code below:

Sub Ouvrir_un_par_un()
 
'Déclaration des variables :
    Dim nb_de_ligne As Integer    'nombre de lignes du document
    Dim increment As Integer      'incrément de 1 pour effectuer la boucle de recherche ligne par ligne
    Dim myCell As String          'variable pointant sur la cellule en cours
    Dim path_complete As String   'chemin complet de la pièce
    Dim myBool As Boolean
    Dim swApp As ISldWorks
    Dim swModel As ModelDoc2
    Dim nDocType As Integer
    Dim myErrors As Long
    Dim myWarnings As Long
    
'Initialisation de certaines variables:
    nb_de_ligne = Range("A1").End(xlDown).Row - 1
    If MsgBox("Vous vous apprêtez à ouvrir : " & nb_de_ligne & " fichiers à la chaine !" & Chr(13) & "Commencer ?", vbYesNo, "Demande de confirmation") = vbYes Then

'Déduction du type de fichier avec l'exension:
        If swApp Is Nothing Then
           Set swApp = CreateObject("SLDWORKS.application")
           swApp.Visible = True
           MsgBox ("Solidworks n'était pas ouvert, on vient de le lancer, appuyer sur OK quand il à l'air d'être prêt")
        Else
           Set swApp = Application.SldWorks
        End If
       
    'Boucle sur toutes les pièces:
        For increment = 1 To nb_de_ligne
            Set swModel = Nothing
            nDocType = 0
            myCell = "A" & (increment + 1)
            path_complete = Range(myCell).value
            If MsgBox("Voullez vous vérifier le fichier : " & Chr(13) & path_complete, vbYesNo, "Ouvrir ce fichier dans SW ?") = vbYes Then
            
                ' Determine type of SOLIDWORKS file based on file extension
            If InStr(LCase(path_complete), "sldprt") > 0 Then
                nDocType = swDocPART
            ElseIf InStr(LCase(path_complete), "sldasm") > 0 Then
                nDocType = swDocASSEMBLY
            ElseIf InStr(LCase(path_complete), "slddrw") > 0 Then
                nDocType = swDocDRAWING
            Else
                ' Probably not a SOLIDWORKS file
                nDocType = swDocNONE
                ' So cannot open the file
                Exit Sub
            End If
                Set swModel = swApp.OpenDoc6(path_complete, nDocType, 1, "", myErrors, myWarnings)
                ' Comment utiliser OpenDoc7 ??
                'swModel.ViewZoomtofit2 ' Bug souvent, pourquoi ?
            End If
        Next increment
        
    End If
'Set swApp = Nothing
End Sub

 

 

1 Like
2

Hello

I don't have any experience in Python programming, I never use macros in vba but I use a lot of the solidworks API as well as the Epdm API in programs written in C#, some of which were created for mass processing (up to about 50000 files and processing of several hours) and I had very few problems such as than the ones you describe and surely no unprocessed files.

For Solidworks, one point to watch out for is the maximum number of windows you can open in Solidworks (20) and don't be afraid to programmatically close Solidworks and then restart it from time to time.

For Epdm, you already need a good network connection and regularly purge the "AddInSrv" processes.

For mass processing, you regularly have to "kill" the windows "explorer" processes to restart one.

And then a little "Multithreading" in your programs to avoid the annoying "Don't Respond" but you must know that.

Kind regards

3 Likes
3

Hello

Like Daniel ROGER, I do C# with the API for mass processing, but on my side I find a lot of instability problems due to SolidWorks ... I don't miss files because I try several passes (I detect if the first pass didn't work, in this case I try a second one after a kill of the process).

I wanted to make a little up on this, because I tried to make a WatchDog to check that SolidWorks always responds well, but I have the impression that my WatchDog does not work 1 time out of 10 ... Do you have any ideas to improve my WatchDog (use a task, and I make an interrupt in case the counter task finishes earlier than the SolidWorks task).

PS: for the furious among you, I noticed that SolidWorks crashes less if you assign it to a single logical core with high priority, and you run your program on the other cores of the processor.

4

Good evening.

I use Python most often because it's my favorite language and I did some tests to see if it was easily applicable to the Solidworks API.

The result is not perfect, especially for many COM object problems. Joshua Redstone's Blog: Solidworks Macros via Python is a must. Despite this information, some functions resist me (exporting a part in DXF according to a view in particular). So I don't particularly recommend this language first.

I'm attaching my essays in PC if you're interested.


solidworks_python_api.pdf
5

Hello

@yellow : To be able to improve your "WatchDog" it would already be good if you told us how it works. Look at the "Responding" property of the "Process" class, it should allow you to do things.

Kind regards

1 Like
6

Hello

Thank you for your answers. I don't go on the forum every day because it's a side project, I do the macro when I have a little time.

In fact my problem did not come from the WatchDog ... But famous GUI objects... (and as it crashed in the night, I didn't understand right away). To solve this, a small one (7500 because we have to stay below 10000 with Windows):

if (Process.GetProcessById(SWAppPID).HandleCount >= 7500)

or (to be tested, but would seem more accurate):

if(GetGuiResources(Process.GetProcessById(SWAppPID).Handle, 0) >= 7500)

PS for SWAppPID:

SWApp = Activator.CreateInstance(Type.GetTypeFromProgID("SldWorks.Application")) as SldWorks;
SWAppPID = SWApp.GetProcessID();

As for the WatchDog:

internal static void WatchDogDelay()
{
    Thread.Sleep(300000);
}
internal static SldWorks CallAGetApplication()
{
    Thread SWOpen = new Thread(GetApplication);
    Thread Watchdog = new Thread(WatchDogDelay);
    Watchdog.Start();
    SWOpen.Start();
    while (Watchdog.IsAlive && SWOpen.IsAlive) ;
    if (SWOpen.IsAlive)
    {
        SWOpen.Interrupt();
        Dispose();
        return CallAGetApplication();
    }
    return SWApp;
}

Let me know what you think!!

Thank you in advance.

7

@mgauroy, thank you for sharing your notes:)

But damn, I'm not familiar with Python at all ... :'(

8

@d.roger, indeed, thank you for the advice.

I should add the "Responding" test in a few places in addition to the tests I do.