【SolidWorks VBA極意】ボス・スイープで迷子にならない！「参照」を掌握してエラーをゼロにする技術
こんにちは。SolidWorksの世界で自動化という名の魔法を操る皆さん、今日も設計の自動化を楽しんでいますか？
マクロの記録機能でコードを吐き出させ、「よし、動いた！」と喜ぶのは最初の一歩です。しかし、少し複雑な形状を生成しようとすると、途端に`BossSwept2`が機嫌を損ねて「スイープに失敗しました」とエラーを吐く……そんな経験はありませんか？
特にスイープは、「輪郭」と「パス」という二つの異なるオブジェクトが、正しいタイミングでSolidWorksに認識されているかがすべてです。今日は、エラーで泣かないための「参照管理」の極意を伝授します。
—
1. なぜ「マクロの記録」だけでは不安定なのか？
マクロの記録で生成されるコードは、往々にして「選択状態」に依存しています。
‘ マクロの記録でよく見る「選択」ベースのコード
swModel.Extension.SelectByID2 “Sketch1”, “SKETCH”, …
swModel.Extension.SelectByID2 “Sketch2”, “SKETCH”, …
swModel.FeatureManager.InsertSwept2 …
このやり方の最大の問題点は、「もしSketch1やSketch2という名前が変わったら？」「もし他の要素が選択されていたら？」という点にあります。SolidWorksは、ユーザーが画面上で選んでいる「選択セット」を非常に不安定な情報として扱います。
真のエンジニアは、「名前」や「選択」ではなく、「オブジェクト（メモリ上の実体）」を直接掴むのです。
—
2. スイープ成功の鉄則：オブジェクトを「明示的に」握り込む
ボス・スイープを成功させるための秘訣は、「フィーチャの生成前に、輪郭とパスのFeatureオブジェクトを正しく取得すること」に尽きます。
以下のコードは、スイープを「選択」に頼らず、プログラム的に実行するためのスマートな設計です。
実践：堅牢なスイープ生成コード
Public Sub CreateSmartSweep()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Dim swFeatMgr As SldWorks.FeatureManager
Dim swProfileSketch As SldWorks.Feature
Dim swPathSketch As SldWorks.Feature
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swFeatMgr = swModel.FeatureManager
‘ 1. 名前でフィーチャを取得（これが一番確実）
‘ ※事前にスケッチ名を明示的に付けておくことが運用上のコツです
Set swProfileSketch = swModel.FeatureByName(“ProfileSketch”)
Set swPathSketch = swModel.FeatureByName(“PathSketch”)
‘ 2. 選択クリア（重要：予期せぬ選択がエラーを招く）
swModel.ClearSelection2 True
‘ 3. 輪郭とパスを個別に選択（Select2メソッドの引数に注目）
‘ Append=True で複数選択状態を維持
swProfileSketch.Select2 False, 0
swPathSketch.Select2 True, 0
‘ 4. フィーチャ生成
‘ 引数の意味：(閉じた輪郭か, 平滑化か, ガイド曲線使用か, 等)
Dim swFeat As SldWorks.Feature
Set swFeat = swFeatMgr.InsertSwept2(False, False, 0, False, False, 0, 0, False, 0, 0, False, True, True, True, 0)
If swFeat Is Nothing Then
MsgBox “スイープの構築に失敗しました。スケッチの交差を確認してください。”
End If
End Sub
—
3. なぜこの書き方が「最強」なのか？
このコードがマクロの記録と一線を画す理由は3つあります。
1. `ClearSelection2 True` の徹底:
「何が選ばれているか分からない」状態は、スイープエラーの最大の原因です。実行直前に必ず画面上の選択をリセットすることで、計算ミスを未然に防ぎます。
2. Featureオブジェクトの保持:
文字列（名前）で直接操作するのではなく、`Feature`オブジェクトとしてメモリ上に保持することで、モデルツリーの構成が変わっても、SolidWorks内部のポインタが正しく追従します。
3. エラーハンドリングの予兆:
`Set swFeat = …` の戻り値が `Nothing` かどうかをチェックすることで、生成失敗時に即座に処理を止める、あるいはログを残すといった「プロ仕様」の制御が可能になります。
—
4. 最後に：エンジニアとしてのマインドセット
SolidWorks APIを扱う際、常に自分に問いかけてください。
「今、私は画面上の名前を操作しているのか？ それとも、メモリ上のジオメトリを操作しているのか？」
もし、スケッチのトポロジーが変わっても壊れないコードを目指すなら、スケッチ内の「エッジ」や「頂点」を `SelectByID2` で取得するのではなく、今日紹介したように「フィーチャ単位」で扱い、SolidWorksに「どのスケッチをどう使うか」を明確に指示すること。
これが、泥沼のデバッグ地獄から抜け出し、安定した自動化環境を構築する唯一の道です。
さあ、あなたのコードを一つ上のステージへ引き上げましょう。また次回、より深い階層でお会いしましょう。
