【SolidWorks API】設計変更の「見えない綻び」を排除する：重心・表面積のリアルタイム検証メカニズム
設計変更のたびに「質量特性」ウィンドウを開き、電卓を叩いてエクセルに転記する……そんな原始的な作業は今日で終わりにしよう。
我々のような自動化エンジニアにとって、設計変更は単なる形状の更新ではない。「質量・体積・表面積」という幾何学的アイデンティティが、許容範囲内に収まっているかを即座に検証するフェーズである。
本稿では、SolidWorks APIを叩き、設計の整合性を守るための「堅牢な検証エンジン」の構築手法を伝授する。
—
1. なぜ「単純な更新」ではバグが生まれるのか
多くのエンジニアが陥る罠は、`swModel.ForceRebuild3` を呼び出した直後に `IMassProperty` を取得しようとすることだ。
SolidWorksの再構築（Rebuild）は非同期的な要素を含んでおり、特に複雑なアセンブリや外部参照を持つパーツでは、再構築完了前にプロパティの取得処理が走り、「前回の計算結果」を掴んでしまうケースが多発する。
これを防ぐための鉄則は以下の3点だ。
1. Rebuildの完了を待機する: `ForceRebuild3` の戻り値を必ず確認する。
2. オブジェクトの解放: `IMassProperty` や `IMeasure` はCOMリファレンスを掴み続けるため、ループ内での生成はメモリリークを招く。明示的に `Nothing` を代入せよ。
3. 妥当性の検証: 計算値が 0 になっている場合は再構築失敗と見なし、例外を投げるべきだ。
—
2. 実装：堅牢な設計検証マクロ
このコードは、アクティブなパーツの質量特性を抽出し、設計要件と比較する「検知器」のコアロジックである。
Option Explicit
‘ 設計許容値（定数として管理）
Const TARGET_MASS As Double = 1.50 ‘ kg
Const TOLERANCE As Double = 0.05 ‘ 5%の許容誤差
Sub ValidatePartGeometry()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swMass As SldWorks.MassProperty
Dim swModelDocExt As SldWorks.ModelDocExtension
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then Exit Sub
If swModel.GetType <> swDocPART Then MsgBox “パーツファイルを開いてください”: Exit Sub
‘ 1. 完全な再構築を実行
swModel.ForceRebuild3 False
‘ 2. 質量特性オブジェクトの生成
Set swModelDocExt = swModel.Extension
Set swMass = swModelDocExt.CreateMassProperty
‘ 3. 計算の実行と検証
If swMass.UseSystemUnits = False Then swMass.UseSystemUnits = True
Dim currentMass As Double
currentMass = swMass.Mass
‘ 結果の判定とフィードバック
If Abs(currentMass – TARGET_MASS) / TARGET_MASS <= TOLERANCE Then
Debug.Print "検証OK: 質量 " & Round(currentMass, 3) & " kg"
Else
MsgBox "【警告】設計許容範囲外です！" & vbCrLf & _
"現在値: " & currentMass & " kg", vbCritical
End If
' メモリ解放の徹底（重要）
Set swMass = Nothing
Set swModelDocExt = Nothing
End Sub
---
3. 現場で生き残るための「設計上の注意点」
データベース連携の罠
取得した値をCSVやSQL Serverへ飛ばす際、必ず「単位系」を固定すること。`swMass.UseSystemUnits = True` は便利だが、ファイル設定次第で「g」になったり「kg」になったりする。APIを通す際は、必ず `swMass.Mass` を取得した後に `swMass.GetMass` 等で値を固定し、単位をプログラム内で正規化して記録するのがプロの流儀だ。
パフォーマンスを最適化する
もしこれが「100個のパーツを順次開いて検証する」ようなバッチ処理であれば、`swModel.Visible = False` でバックグラウンド処理を行うこと。GUIの描画コストを省くだけで、処理速度は数倍向上する。
ログの残し方
エラーが発生した際、単に「エラーです」と出すのは素人だ。
- どのフィーチャが失敗しているか
- 最後に成功した計算値はいくらか
- タイムスタンプ
これらをテキストファイル（ログ）に出力し、トレーサビリティを確保せよ。
—
最後に：エンジニアとしての心構え
自動化ツールは「書いたら終わり」ではない。モデルのフィーチャツリーが複雑化すれば、計算負荷は増大する。
今回紹介したコードは、あくまで「検証の基盤」だ。今後は、このロジックをクラスモジュールにカプセル化し、`PartAnalyzer` クラスとしてライブラリ化することをお勧めする。そうすることで、他のプロジェクトでも「検証エンジン」をプラグアンドプレイで使い回せるようになるからだ。
泥臭い手作業を自動化の力で絶滅させ、我々エンジニアは「本来考えるべき設計の本質」に集中しよう。それが、このコードを託す最大の理由だ。
