ポリゴンで覆われたParasolid

こんにちは。
超不定期投稿ブログになってます。

今日、ポリゴンで覆われたデータに出会いました。
図面ビューを作って、寸法を記入しようとしたら、R寸法が入らない。
どう見ても、円弧部分だと思ったんですが、モデルでよく見たら、円筒面がポリゴン(三角面の集合体)で覆われており、目が点になりました。
"なんじゃこりゃ?"

"もしや、元はICAD/SXか?" と色々と疑ってます。
Parasolidデータをもらえる、といっても安心できないな、と痛感した一日でした。

ではまた。

SolidWorksのVersionUP

こんにちは、前回の投稿から一月以上、空いてしまいました。

今日は、話題を二つ書きます。

@ひとつ目。
今日、3D単独図について調べてたら、あるブログを見つけました。
「SolidWorksユーザMEの こんなのありましたブログ」
SolidWorksだけでなく、3D図面やGD&Tについても、結構、濃い内容が書かれてます。
特に、ASMEやISOの文献をきちんと押さえているところに、感激しました。

私と同じ大阪在住のようなので、いつか、この感激を伝えたいと思っています。

@二つ目。
今年も、次のVersion(2011)のBetaプログラムが開始されてます。
多くの改善点を報告した人には、SolidWorks社(米国)だけでなく、ソリッドワークス・ジャパン社からも表彰され、賞品が出るようです。

建前上は、我々サポートエンジニアも勉強をしないといけません。
ですが、私と周辺のメンバーは、多くのベテランユーザーからの『2010へのVerUP相談』に対応するべく準備を進めています。
(現在、SP4まで出ており、移行する既存ユーザーさんが増えている)

また、昨年から「VersionUP支援サービス」を試行しています。
SolidWorks管理者の負荷を抑え、スムーズに移行し、既知のトラブルを回避できるような支援を目指しています。

この支援に使う資料の一部は、無償提供する予定です。
※九月に西日本で開催するSolidWorks活用研究会で、資料提供する予定です。

最近はこんなことをやってます。
以上

レイアウトスケッチ機能

しばらくぶりの投稿です。
色々、慌ただしくやってるのですが、ひとつショックな発見があったので投稿します。

2008から搭載された、レイアウトスケッチ機能についてです。
スケッチブロックと併用することで、線画で様々な3Dの機構検討が行えるようになってます。2009ではMotion解析も行えるようになってます。

しかしながら、このレイアウトを含むアセンブリを他のアセンブリに挿入した時、『フレキシブル』に設定できないのです！（SW2010でも変わらず…）

折角、機構検討に強いのに、機構が多い装置や設備の設計では、詳細設計までつながるデータとして使えなさそうです。
大きなアセンブリだと機構をサブアセンブリレベルで扱うことも多いので、全体の動きを見せようとすると、上のアセンブリでフレキシブルにすることも多いと思います。
(同じ機構ユニットを複数使う場合など)

私は、リニアモータなどのアセンブリライブラリにも応用できるのでは?と期待していたのですが、一気に構想が崩れてしまいました。
(アセンブリライブラリのファイル管理を楽にできるかも?と期待してたのですが…)

結局、このアセンブリのレイアウト機能は構成部品点数の少ない製品の設計や、動かないユニットの配置（Layout）検討しか想定してないようです。
こうしたことから、装置や設備機械は、従来通り、レイアウト手法(スケッチ、エンベロープ)などを使うのが良いと感じています。

皆さんはどう思われるでしょうか？
色々、ご意見をお聞きしたいです。
では、また。

構想設計？

今日、以前やった構想設計のセミナーのリニューアル版のセミナーをやりました。

2007版頃から、構想設計で役に立ちそうな下記のような機能が追加されたり、改善されたりしてます。
　　・スケッチブロック
　　・3Dスケッチ
　　・仮想構成部品
　　・レイアウト
2008で仮想構成部品が搭載され、ファイル管理上、注意が必要だなぁと思ってました。

今回、再発表するために見直してて、2010ではこの点が改善されていることに気付きました。
通常のファイル保存時の参照情報の更新の仕組みも改善されてます。

この発表のため色々試してて分かったのは、下記です。
　＞小規模なアセンブリの設計や、機構部分の設計では、レイアウト機能は有効
　＞数千点規模のチーム設計を伴う大規模アセンブリの設計では合わない
　＞大規模アセンブリではレイアウトパーツやエンベロープを使ったほうが良さそう

まぁ構想設計といっても、新規性が高いか低いか、詰めたい内容が何か、など各設計者で異なるので、参考程度に御認識ください。

複数企業での設計

つづきです。

ファイル名のユニークさを死守する必要がある、ということで検討を進めた結果、下記のような　"お願い"　を外注設計さんに行おう！ということになりました。

１：　各テンプレートファイル、設定ファイル、マクロなどを提供し、できるだけ同じ環境で作業をしてもらう
　　（部品、アセンブリ、図面、シートフォーマット、穴寸法テキストフォーマットファイル、プロパティ入力用マクロ、などなど）

２：　同じファイル名命名ルールでデータ作成してもらう
　　（台帳管理や採番が不要なルールとしたことで可能となった）

３：　ボルト、ナットなど、利用頻度の高い共用データは事前に提供し、利用してもらう
　　（部品表に出力するプロパティ情報を入れた部品を作成しておく。導入初期に集中して整備する。　Toolboxは継続したメンテナンスが困難と判断し、使用禁止とした。）

３：　必要な購入品のモデルがない場合、下記の優先順位で探して入手・作成してもらう
　＞指定ライブラリ製品　（導入していれば…）
　＞提供済みデータ
　＞Web2CAD
　＞メーカーWebサイト
　＞自作　（※）
　　　※ファイル名は、自社品番、または、メーカー型番、とする

だいたいこんな感じです。
できるだけ利用者に負担や手間がかからないように気を付けました。

最後の念押しとして、データ受け入れ時のチェック作業の検討もおこないました。

危険なのは、前回も書きましたが、Webからダウンロードしたアセンブリに含まれる部品のファイル名です。
　→対応の基本方針：　「名前変更」などで、頑張る！
　　　（超人間系です　(^_^;)　）

　　　※共用部品の置き換えなどの作業が、許容量を越えた場合は諦めて、ユニークなファイル名に変更することにしました
　　　（きれいなデータを作るのが目的ではない！、出図作業優先！）

可能であれば、マクロなどでプロパティ入力チェックなどもやりたいところです。
　（タスクスケジューラや、DesignCheckerを使えば多少はできるかも？）

今回、この件を考えてて、みんな同じルールで使えたらいいのに…、などと考えてしまいました。
ではまた。

複数企業での設計

いま、外部の会社で設計を行う場合のデータ管理について検討しています。
今回は、出図図面や設計データの保管などの管理は、元締め企業が行う必要があるので、そこのルールを検討しています。

データ管理となると、やはりファイル名がポイントになるようです。
命名ルールを作るわけですが、いかにルールに乗りやすいルールと環境を作れるか？が成否の鍵かな？とおもってます。

特に厄介なのが購入品データ（特にアセンブリ）です。
Webからダウンロードしやすくなってますから、どんなデータが利用されるか予想がつきません。

※例：　構成部品のファイル名が「プレート」とか「Part1」とかになっているアセンブリ

ファイル名さえユニークであれば、他のデータと入れ替わったりする危険が無くなるので、なんとかここは死守する必要があります。

やはり練習で軽く痛い目を見てもらって、ルールを説明することが必要かもしれません。

つづく…

設計者とリスト

いま仕事で、リスト出力がらみの開発をやってます。私は"あの人"みたいに自分でプログラミングはやらないので、開発担当の人と組んで、進めてます。
プログラミングは、学校行ってたときにゴリゴリやったお陰か、開発の人と会話するのには困らないレベルです。
（私が結構わがまま言って、相手が困ってるかも？）

ソフトはもちろんSolidWorksで、いくつかの条件で「並び」と「グループ」が変化します。
通常、アセンブリ組んで部品表を作成したら、並びはアセンブリの組み方に依存します。それを、ある条件に応じて、変化させよう！ということです。
出力は、Excelでして、どうアセンブリを組んで必要な情報を効率よく取り出すか？、条件により変化する情報をどのようにモデルに含めるか？、がポイントとなってます。

ここで扱う条件なんですが、組立手順や梱包単位などもあります。製品や会社にもよりますが、設計者がそこまで考えてリスト作ってるんです。

こんな風に出力は条件により変化しますが、設計検討を行う「まとまり」は、変化しないんです。
ようは同じ製品であれば、梱包単位がどうあれ、検討する単位は変わらない。
アセンブリ構成は設計検討する単位で構成するべきなので、固定化できるんですね。
（やっぱりそうか、という感じで今回も再認識しました。）

但し、このアセンブリ構成で納得するには、条件により出力を変化させる仕組みを明確にする必要がありました。
今回は、条件毎にプロパティ変数を決め、その時の出力を値に入れることになりそうです。
ひとつのプロパティ変数で同じことをやる方法も見つけましたが、メンテや開発を考慮して不採用としました。

こんな風に、設計者が作ってる「リスト」と「アセンブリ構成」とは変えた方が良い例は結構あると思います。
設計者が現場のニーズを考慮することに慣れすぎてるのかもしれません。

では今日はここまでにします。ではまた。