API - Stabilność i niezawodność makr VBA, dodatków i autonomicznych

Witam

Niestety, jestem bardzo rozczarowany stabilnością/niezawodnością narzędzi MyCADtools w środowisku PDM na dużych złożeniach z + dużą ilością odniesień zewnętrznych,

Obecnie tworzę aplikację w języku Python obsługiwaną przez wiele makr VBA, która korzysta z interfejsu API solidworks.

Przychodzę więc dzisiaj do Was, aby poznać odczucia programistów na temat stabilności i niezawodności tych narzędzi.

Rozumiem przez to: czy ma tendencję do zawieszania się/zawieszania oprogramowania? Czy często powoduje to awarie samodzielnych aplikacji?

Czy rozpoczynając kurację na dużym pakiecie części, jest szansa, że część z nich nie zostanie uwzględniona?

Rzeczywiście, nie wiem, jak programowane są narzędzia MyCAD, ale jasne jest, że rzadko kończą swoje zadanie, a kiedy dotrą do końca bez awarii, niektóre części są często tracone.

 

Zacząłem więc kodować prosty marco excel, który otwiera pliki jeden po drugim, których ŚCIEŻKA znajduje się w kolumnie.

Zauważyłem, że tam też dostaję przypadkowe zachowanie.

Czy uważasz, że jest to spowodowane problemem programistycznym z moim własnym kodem, czy też API oprogramowania jest w ogóle natywnie zawodne?

Jestem nowy w VB i API sw, ale już programuję w wielu różnych językach...

Dziękuję za odpowiedź

Poniższy kod:

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 polubienie

Witam

Nie mam żadnego doświadczenia w programowaniu w Pythonie, nigdy nie używam makr w vba ale używam dużo solidworks API, a także API Epdm w programach napisanych w C#, z których część została stworzona do masowego przetwarzania (do około 50000 plików i przetwarzanie przez kilka godzin) i miałem bardzo mało problemów takich jak niż te, które opisujesz i na pewno nie ma nieprzetworzonych plików.

W przypadku Solidworks, jednym z punktów, na które należy zwrócić uwagę, jest maksymalna liczba okien, które można otworzyć w Solidworks (20) i nie należy obawiać się programowego zamknięcia Solidworks, a następnie ponownego uruchomienia go od czasu do czasu.

W przypadku Epdm potrzebujesz już dobrego połączenia sieciowego i regularnie czyścisz procesy "AddInSrv".

W przypadku masowego przetwarzania regularnie musisz "zabijać" procesy "eksploratora" systemu Windows, aby ponownie uruchomić jeden.

A potem trochę "wielowątkowości" w swoich programach, aby uniknąć irytującego "Nie odpowiadaj", ale musisz o tym wiedzieć.

Pozdrowienia

3 polubienia

Witam

Podobnie jak Daniel ROGER, zajmuję się C# z API do masowego przetwarzania, ale po swojej stronie znajduję wiele problemów z niestabilnością spowodowanych przez SolidWorks ... Nie tęsknię za plikami, ponieważ próbuję kilku przejść (wykrywam, czy pierwsze przejście nie zadziałało, w tym przypadku próbuję drugiego po zabiciu procesu).

Chciałem trochę nadrobić na tym, bo próbowałem zrobić WatchDoga, żeby sprawdzić, czy SolidWorks zawsze dobrze reaguje, ale mam wrażenie, że mój WatchDog nie działa 1 raz na 10... Czy masz jakieś pomysły na ulepszenie mojego WatchDoga (użyj zadania, a ja robię przerwanie w przypadku, gdy zadanie licznika zakończy się wcześniej niż zadanie SolidWorks).

PS: dla wściekłych wśród was, zauważyłem, że SolidWorks zawiesza się rzadziej, jeśli przypiszesz go do pojedynczego rdzenia logicznego o wysokim priorytecie, a uruchomisz swój program na innych rdzeniach procesora.

Dobry wieczór.

Najczęściej używam Pythona, ponieważ jest to mój ulubiony język i przeprowadziłem kilka testów, aby sprawdzić, czy można go łatwo zastosować do API Solidworks.

Wynik nie jest idealny, szczególnie w przypadku wielu problemów z obiektami COM. Blog Joshuy Redstone'a: Makra SolidWorks za pośrednictwem Pythona jest koniecznością. Pomimo tych informacji, niektóre funkcje mi się sprzeciwiają (w szczególności eksport części w formacie DXF według widoku). Nie polecam więc szczególnie tego języka w pierwszej kolejności.

Załączam moje eseje na PC, jeśli jesteś zainteresowany.


solidworks_python_api.pdf

Witam

@yellow : Aby móc ulepszyć swojego "WatchDoga", dobrze by było, gdybyś powiedział nam, jak to działa. Spójrz na właściwość "Responding" klasy "Process", powinna ona pozwolić ci na robienie różnych rzeczy.

Pozdrowienia

1 polubienie

Witam

Dziękuję za odpowiedzi. Nie zaglądam codziennie na forum, bo to jest projekt poboczny, makro robię, kiedy mam trochę czasu.

W rzeczywistości mój problem nie pochodził z WatchDoga ... Ale słynne obiekty GUI... (a ponieważ rozbił się w nocy, nie zrozumiałem od razu). Aby rozwiązać ten problem, mały (7500, ponieważ musimy pozostać poniżej 10000 w systemie Windows):

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

lub (do przetestowania, ale wydaje się bardziej dokładne):

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

PS dla SWAppPID:

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

Jeśli chodzi o 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;
}

Dajcie znać, co o tym myślicie!!

Z góry dziękuję.

@mgauroy, dziękuję za podzielenie się swoimi notatkami :)

Ale cholera, w ogóle nie znam Pythona... :'(

@d.roger, rzeczywiście, dziękuję za radę.

Powinienem dodać test "Odpowiadanie" w kilku miejscach oprócz testów, które wykonuję.