【テクニカル・上級編】【形状検証・検査】IMeasure.RayIntersectionを用いた指定方向への干渉・レイキャスト判定自動化マクロ – SolidWorks VBA解析バイブル

スポンサーリンク

SolidWorks APIの深淵:IMeasure.RayIntersectionによる空間幾何解析の自動化

設計現場において、「目視確認」ほど不確実でコストのかかる工程はない。特に複雑な射出成形品や鋳造品の肉厚チェック、あるいは精密機器におけるクリアランスの干渉判定を人間がCAD上で行うのは、もはや時代遅れだ。

本稿では、SolidWorks APIの隠された強力なツールである `IMeasure.RayIntersection` を駆使し、任意のベクトル上で物理的な交差を瞬時に判定する「レイキャスト検査システム」の構築術を伝授する。

1. なぜ「IMeasure」なのか:幾何学的思考の重要性

多くのエンジニアは、干渉チェックのために「干渉検知機能(Interference Detection)」をUIから動かそうとする。しかし、それは動的な検証には向かない。我々が求めるのは、「特定の座標から、特定の方向へ、どれだけの距離で何にぶつかるか」という純粋な幾何学的データだ。

`IMeasure.RayIntersection` は、SolidWorksのカーネル(Parasolid)に直接、仮想的な「光線」を投射する。これにより、メッシュ生成や重いアセンブリ干渉解析を待つことなく、単一パーツ内での肉厚不足や、クリアランス違反を数学的に算出できる。

2. 実装の極意:メモリ管理とCOMオブジェクトの行方

VBAでSolidWorks APIを扱う際、最も多くのエンジニアが犯す過ちが「オブジェクトの放置」だ。`SelectionMgr` や `ModelDoc2` を不用意にキャッシュし続けると、メモリリークが発生し、特に `RayIntersection` のような高頻度で実行されるメソッドは、ガベージコレクションが追いつかずSolidWorksをクラッシュさせる。

推奨される設計指針

  • 明示的な解放: `Set obj = Nothing` を徹底する。
  • スコープの最小化: ループ内でオブジェクトを生成せず、可能な限り外部でインスタンス化して再利用する。
  • Windows APIの併用: 計算負荷の高い処理を行う際は、`QueryPerformanceCounter` を使用してミリ秒単位で処理時間を計測し、アルゴリズムの収束性を監視せよ。

3. 実装サンプル:レイキャストによる肉厚・クリアランス検証

以下のコードは、指定した点から法線方向にレイを飛ばし、最初の交点までの距離を測定するコアロジックである。

‘ 伝説的なチーフアーキテクトによるレイキャスト判定ルーチン
Public Sub PerformRayCheck(swModel As SldWorks.ModelDoc2)
Dim swPart As SldWorks.PartDoc
Dim swMeasure As SldWorks.Measure
Dim vRayOrigin As Variant
Dim vRayDirection As Variant
Dim dRayLength As Double
Dim bResult As Boolean

Set swPart = swModel
Set swMeasure = swModel.Extension.CreateMeasure

‘ レイの原点(X, Y, Z)と方向ベクトル(I, J, K)
vRayOrigin = Array(0#, 0#, 0#)
vRayDirection = Array(0#, 0#, 1#)
dRayLength = 100# ‘ 検査する最大範囲(mm)

‘ RayIntersectionの実行
‘ 第1引数: 原点, 第2引数: 方向, 第3引数: 長さ
bResult = swMeasure.RayIntersection(vRayOrigin, vRayDirection, dRayLength)

If bResult Then
‘ 交差した場合、距離を取得
Debug.Print “交差距離: ” & swMeasure.Distance
Else
Debug.Print “交差なし:クリアランス違反の可能性、または空間が空いています。”
End If

‘ メモリ最適化:COMの残骸を残さない
Set swMeasure = Nothing
Set swPart = Nothing
End Sub

4. シニアエンジニアへの提言:保守性と拡張性

このロジックを実務で運用する際、以下の3点を考慮せよ。

1. データ構造の抽象化: 検査ポイントを配列ではなく、`Collection` クラスや `Scripting.Dictionary` を用いて構造化せよ。検査項目が増えた際、拡張が容易になる。
2. ログの外部出力: `Debug.Print` は開発用だ。実運用では `Scripting.FileSystemObject` を使い、JSONまたはCSV形式で検査結果を吐き出せ。これにより、後工程のBIツール(PowerBI等)との連携が可能になる。
3. レガシー環境の罠: Windows 10/11環境では、VBAの参照設定が消失するトラブルが頻発する。`CreateObject` を用いた「遅延バインディング」を推奨するが、パフォーマンス低下を避けるため、頻繁に叩くAPIは事前バインディングを維持し、例外処理を徹底すること。

最後に:自動化は「手段」であり「目的」ではない

このレイキャスト手法は、設計者の「直感」を数学的な「事実」に置き換えるためのものだ。数千の検査点を一瞬で計算し、異常値だけを設計者に突きつける。これこそが、我々エンジニアが本来向き合うべき「知的生産性の向上」である。

君たちのコードが、単なる自動化ツールから、組織を支える「インテリジェントな検証エンジン」へと昇華することを願っている。技術に妥協するな。それが、伝説を作るための唯一の道だ。

タイトルとURLをコピーしました