現場で差がつく！SolidWorks VBA「再構築エラー」を完全解剖するデバッグ術
こんにちは。現場で「なぜかマクロが止まる」「再構築失敗でモデルが真っ赤になる」といったトラブルに頭を抱えたことはありませんか？
マクロの記録で生成されたコードを並べるだけの段階から、「プロフェッショナルな自動化エンジニア」へと脱皮するために避けて通れないのが「エラーハンドリング」です。今日は、SolidWorksが吐き出す「再構築エラー」をAPIレベルで叩き出し、ログとして克明に記録する極限の手法を伝授します。
—
なぜ、普通の「エラー処理」では足りないのか？
VBAの `On Error GoTo` だけでは、SolidWorks内部で起きる「ジオメトリの破綻」までは拾えません。
フィーチャに赤い×印がつくあの状態は、API的には「正常に命令は受け付けたが、計算結果が不正」という扱いだからです。
ここで使うのが、`ModelDocExtension.GetEvaluationErrors` です。これを使うと、再構築時に発生した具体的なエラーメッセージや、どのフィーチャが戦犯なのかをプログラム側で特定できるようになります。
—
実装の設計図：ログ生成のメカニズム
今回作成するロジックは以下の3段構えです。
1. Rebuildの実行: `ForceRebuild3` メソッドでモデルを更新。
2. エラーの捕捉: `GetEvaluationErrors` でエラー情報を配列として取得。
3. ログ出力: `FileSystemObject (FSO)` を使い、タイムスタンプ付きのテキストファイルへ書き出し。
—
実践コード：エラー解析ロジック
このコードを標準モジュールに貼り付けてください。
Option Explicit
‘ エラー内容をテキストログに吐き出すプロシージャ
Public Sub ExportRebuildErrors()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swModelExt As SldWorks.ModelDocExtension
Dim errors As Variant, warnings As Long
Dim logPath As String
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swModelExt = swModel.Extension
‘ 1. モデルの強制再構築
‘ Falseは「すべての構成部品を含める」設定
If Not swModelExt.ForceRebuild3(False) Then
‘ 2. エラー情報の取得
‘ GetEvaluationErrorsはエラーが存在する場合のみデータを返す
swModelExt.GetEvaluationErrors errors
‘ 3. FSOによるログ出力
WriteToLog “Rebuild Error Detected: ” & swModel.GetTitle, errors
MsgBox “再構築エラーを検知しました。ログを確認してください。”, vbCritical
Else
MsgBox “再構築成功！”
End If
End Sub
Private Sub WriteToLog(header As String, errData As Variant)
Dim fso As Object
Dim ts As Object
Dim i As Long
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ デスクトップにログを出力
logPath = Environ(“USERPROFILE”) & “\Desktop\SW_ErrorLog.txt”
Set ts = fso.OpenTextFile(logPath, 8, True) ‘ 8: ForAppending
ts.WriteLine “— ” & Now & ” —”
ts.WriteLine header
‘ エラー詳細をループで書き出し
If Not IsEmpty(errData) Then
For i = LBound(errData) To UBound(errData)
ts.WriteLine “Error Code: ” & errData(i)
Next i
End If
ts.WriteLine “—————————” & vbCrLf
ts.Close
End Sub
—
コードの解説とポイント
- `ForceRebuild3` の選択:
`Rebuild` メソッドは「変更がある箇所だけ」を更新するため、エラーをスルーしてしまうことがあります。自動化において確実性を期すなら、重くても `ForceRebuild3` を使いましょう。
- `GetEvaluationErrors` の仕組み:
このメソッドは、引数に渡した配列の中に、その時点で存在しているエラーIDを格納します。このIDはSolidWorksのAPIヘルプにある「swErrorType」に対応しています。
- FSO (FileSystemObject):
VBA標準の `Open #1` よりも直感的で管理がしやすいため、エンジニアの現場ではこちらが標準です。「追記モード(8)」を使うことで、過去の履歴を消さずにログを蓄積できます。
—
初学者が陥りやすい罠：これだけは覚えておこう
1. 「とりあえずOn Error Resume Next」は禁物:
エラーを隠蔽すると、後続の計算が全てデタラメな数値になり、取り返しのつかない設計ミスに繋がります。「エラーが出たら、止めて、記録する」が鉄則です。
2. タイムスタンプの重要性:
ログファイルに「いつ」発生したかを必ず書き込んでください。後から「昨日のあのデータ、何で失敗したんだ？」と聞かれたときに、このタイムスタンプがあなたのエンジニアとしての信頼を守ってくれます。
まとめ：ここをクリアすれば「脱・初心者」
このコードを自分のマクロに組み込むことで、あなたは「動くだけのコード」から「運用に耐えうる堅牢なシステム」を作れるようになります。
SolidWorks VBAの真髄は、APIをいかに使いこなして「設計者の意図しないエラーを可視化するか」にあります。ぜひ、このデバッグ手法を武器に、誰にも負けない自動化スクリプトを構築してください。
次は、このエラーログをSlackやTeamsに飛ばす仕組みに挑戦してみるのも面白いかもしれませんね。応援しています！
