API - Stabiliteit en betrouwbaarheid van VBA Macro's, Addin en Standalone

Hallo

Helaas erg teleurgesteld zijn over de stabiliteit/betrouwbaarheid van de MyCADtools-tools tools in een PDM-omgeving op grote assemblages met + veel externe referenties,

Ik ben momenteel bezig met het ontwikkelen van een Python-applicatie die wordt ondersteund door veel VBA-macro's en die gebruik maakt van de solidworks API.

Dus ik kom vandaag naar jullie toe om de gevoelens van de programmeurs te horen over de stabiliteit en betrouwbaarheid van deze tools.

Hiermee bedoel ik: Heeft het de neiging om te crashen / bevriezen SW? Zorgt dit er vaak voor dat zelfstandige apps crashen?

Wanneer je een behandeling start op een groot pakket onderdelen, bestaat dan de kans dat er met een aantal daarvan geen rekening wordt gehouden?

Ik weet inderdaad niet hoe MyCAD-tools zijn geprogrammeerd, maar het is duidelijk dat ze hun taak zelden voltooien en dat wanneer ze het einde hebben bereikt zonder te crashen, sommige onderdelen vaak verloren gaan.

 

Dus begon ik met het coderen van een eenvoudige Marco Excel die de bestanden één voor één opent waarvan het PAD in een kolom staat.

Ik merk dat ik ook daar willekeurig gedrag krijg.

Denk je dat dit te wijten is aan een programmeerprobleem met mijn eigen code, of dat de SW API helemaal onbetrouwbaar is??

Ik ben nieuw bij VB en API sw, maar ik programmeer al in veel verschillende talen...

Dank u voor uw antwoord

De code hieronder:

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

Hallo

Ik heb geen ervaring met Python-programmering, ik gebruik nooit macro's in vba, maar ik gebruik veel van de solidworks API en de Epdm API in programma's die in C# zijn geschreven, waarvan sommige zijn gemaakt voor massaverwerking (tot ongeveer 50000 bestanden en verwerking van enkele uren) en ik had heel weinig problemen zoals dan degene die je beschrijft en zeker geen onbewerkte bestanden.

Voor Solidworks is een punt om op te letten het maximale aantal vensters dat u in Solidworks kunt openen (20) en wees niet bang om Solidworks programmatisch te sluiten en vervolgens van tijd tot tijd opnieuw op te starten.

Voor Epdm heb je al een goede netwerkverbinding nodig en schroot je regelmatig de "AddInSrv"-processen.

Voor massaverwerking moet u regelmatig de Windows "verkenner" -processen "doden" om er een opnieuw te starten.

En dan een beetje "Multithreading" in je programma's om het vervelende "Niet reageren" te vermijden, maar dat moet je weten.

Vriendelijke groeten

3 likes

Hallo

Net als Daniel Roger doe ik C# met de API voor massaverwerking, maar aan mijn kant vind ik veel instabiliteitsproblemen als gevolg van SolidWorks ... Ik mis geen bestanden omdat ik meerdere passen probeer (ik detecteer of de eerste doorgang niet werkte, in dit geval probeer ik een tweede na een kill van het proces).

Ik wilde dit een beetje goedmaken, omdat ik heb geprobeerd een WatchDog te maken om te controleren of SolidWorks altijd goed reageert, maar ik heb de indruk dat mijn WatchDog 1 van de 10 keer niet werkt ... Heb je ideeën om mijn WatchDog te verbeteren (gebruik een taak, en ik maak een onderbreking voor het geval de tellertaak eerder klaar is dan de SolidWorks-taak).

PS: voor de woedende onder jullie, ik heb gemerkt dat SolidWorks minder crasht als je het toewijst aan een enkele logische kern met hoge prioriteit, en je draait je programma op de andere kernen van de processor.

Goedenavond.

Ik gebruik Python het vaakst omdat het mijn favoriete taal is en ik heb wat tests gedaan om te zien of het gemakkelijk toepasbaar was op de Solidworks API.

Het resultaat is niet perfect, vooral niet voor veel COM-objectproblemen. Joshua Redstone's Blog: Solidworks Macros via Python is een must. Ondanks deze informatie weerstaan sommige functies me (het exporteren van een onderdeel in DXF volgens een weergave in het bijzonder). Dus ik raad deze taal niet echt als eerste aan.

Ik voeg mijn essays toe op pc als je geïnteresseerd bent.


solidworks_python_api.pdf

Hallo

@geel : Om je "WatchDog" te kunnen verbeteren zou het al goed zijn als je ons vertelt hoe het werkt. Kijk naar de eigenschap "Reagerend" van de klasse "Verwerken", deze zou je in staat moeten stellen om dingen te doen.

Vriendelijke groeten

1 like

Hallo

Dank u voor uw antwoorden. Ik ga niet elke dag op het forum omdat het een zijproject is, ik doe de macro als ik wat tijd heb.

In feite kwam mijn probleem niet van de WatchDog ... Maar beroemde GUI-objecten... (en toen het 's nachts neerstortte, begreep ik het niet meteen). Om dit op te lossen een kleine (7500 omdat we bij Windows onder de 10000 moeten blijven):

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

of (te testen, maar lijkt nauwkeuriger):

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

PS voor SWAppPID:

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

Wat betreft de 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;
}

Laat me weten wat je ervan vindt!!

Bij voorbaat dank.

@mgauroy, bedankt voor het delen van je notities:)

Maar verdomme, ik ben helemaal niet bekend met Python ... :'(

@D.Roger, inderdaad, bedankt voor het advies.

Ik zou de "Responding" -test op een paar plaatsen moeten toevoegen naast de tests die ik doe.