【SolidWorks自動化】スライド機構のストローク解析を極める：距離合致をプログラムで制御する堅牢なアーキテクチャ
SolidWorks APIを触り始めたエンジニアの多くが、最初の壁として突き当たるのが「合致（Mate）の制御」だ。特にスライド機構のような可動範囲を検証する際、手動で値を入力して再構築（Rebuild）を繰り返すのは、エンジニアの仕事ではない。
今回は、距離合致の値をプログラムから動的に制御し、干渉チェックまでを自動化する「実務レベルのコード」を伝授する。単に動くコードを書くのではない。「なぜ、その実装でなければならないのか」を理解してほしい。
—
1. なぜ「力技のループ」ではいけないのか
多くの初学者は、`MateFeature.Name` を指定して、力技で `Dimension` オブジェクトを書き換えようとする。しかし、大規模アセンブリやコンフィギュレーションが絡む現場では、それはバグの温床だ。
堅牢な自動化のために、以下の「3つの鉄則」を遵守せよ。
- 名前への依存を避ける: 合致名はユーザーが変更可能である。`Name` ではなく、合致の定義（Feature）のポインタを直接捕捉せよ。
- 再構築（Rebuild）のタイミングを制御する: 毎回 `ModelDoc2.ForceRebuild3` を呼ぶのは重すぎる。変更が必要な最小単位で制御せよ。
- 例外処理とクリーンアップ: 異常終了時にプログラムで変更した値が残ると、設計意図と異なる状態で保存されるリスクがある。必ず `Try-Catch` 的な構造で初期値復元を組み込むこと。
—
2. 実装コード：スライド可動範囲検証ツール
以下は、選択した距離合致の値を動的に変化させ、検証を行うためのテンプレートである。保守性を高めるため、処理を関数（Sub）に分割している。
Option Explicit
‘ 伝説的なエンジニアの設計：必要な情報を構造体や定数で管理し、責務を分離する
Sub Main()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swMate As SldWorks.Feature
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ 1. 現在選択されている距離合致を取得
Set swMate = swModel.SelectionManager.GetSelectedObject6(1, -1)
If swMate Is Nothing Or swMate.GetTypeName2 <> “Mate” Then
MsgBox “距離合致を選択してください。”, vbCritical
Exit Sub
End If
‘ 2. 可動範囲の検証（例：0mmから100mmまで10mm刻みで移動）
Call ExecuteStrokeTest(swModel, swMate, 0, 100, 10)
End Sub
Sub ExecuteStrokeTest(swModel As SldWorks.ModelDoc2, swMate As SldWorks.Feature, _
startVal As Double, endVal As Double, step As Double)
Dim swDim As SldWorks.Dimension
Dim i As Double
‘ 合致の寸法（D1@距離合致など）を捕捉
Set swDim = swMate.GetDimension2(“D1”)
On Error GoTo ErrorHandler
For i = startVal To endVal Step step
‘ メートル単位系への変換を忘れないこと (SolidWorks APIはメートル固定)
swDim.SystemValue = i / 1000
‘ 再構築と干渉チェック
swModel.ForceRebuild3 False
‘ ここで干渉チェックAPIを呼び出すか、スクリーンショットを保存する処理を入れる
Debug.Print “Current Offset: ” & i & “mm”
DoEvents ‘ UIのフリーズを防ぐ
Next i
Exit Sub
ErrorHandler:
MsgBox “エラー発生: ” & Err.Description, vbCritical
End Sub
—
3. プロダクション環境へ向けての深掘り
データベース連携の注意点
検証結果をExcelやCSVに書き出す際、「合致名と検証日時、その時の干渉有無」をペアでログに残せ。アセンブリファイルは「いつ時点の検証か」が不明瞭になりがちだ。ファイル名にタイムスタンプを付与する習慣をつけるだけで、後から設計意図を追跡するコストが激減する。
なぜ `SystemValue` なのか
`Value` プロパティではなく `SystemValue` を使う理由は、単位系の混乱を避けるためだ。APIは常にメートル法（m）で動作する。ミリメートル（mm）の感覚で `Value` に数値を突っ込むと、1000倍の誤差が生じる。この「単位の落とし穴」を回避するのが、プロのエンジニアの流儀である。
パフォーマンスの最適化
アセンブリの干渉チェックは重い。検証中に画面描画を停止させる `swModel.ViewZoomtofit2` などを多用すると、処理速度が劇的に落ちる。`swApp.Visible = False`（必要に応じて）や、画面更新の抑制を検討せよ。
—
最後に：自動化は「設計の質」を上げるためにある
自動化ツールを作ることが目的になってはいけない。このスクリプトの真の価値は、「これまで手動で検証を躊躇していた境界条件を、プログラムが数秒で洗い出してくれる」という点にある。
人間は思考し、機械は反復する。その分業を明確にせよ。君たちのコードが、明日からの設計現場を少しでも「エンジニアらしい創造的な場所」に変えることを願っている。
質問があればいつでもコメントしてほしい。更なる高みを目指すなら、次は「合致エラーを捕捉して自動的にサプレッションを解除する」ロジックの構築に挑戦してみるといい。
