サポートシェアリングソリューション
OKWAVE Plus
会員登録 （無料）

このQ&Aは役に立ちましたか？

はい
締切済み
すぐに回答を！

3D構成について

2008/07/03 09:39

私は現在2Dから3Dに移行するために先行で配管設計のテストモデル、テスト作業フローを構築しています。現在は、半年ほどかけてテストモデルをほぼ完成させ、初期設計から、モデル化、図面化まで、必要な事ができるようにしたつもりです。
構成の組み方は、それぞれのラインを役割ごとに分けで同時に複数人で作業ができる、設計意図を入れやすい→編集しやすい、新しい名前でコピーすれば、どんなラインでも再設計しやすい→流用性が高い？
作業フローは　ポンプ（サポート付）ASSYなど設計　→　ライン、構成部品設計　→　サポート設計　　の役割ごとのような感じです。

ですが、自分の上司や上の人たちは、　役割などは無視して製造の考えるASSYの構成、リストにしろと言います、例でポンプASSYにライン設計の途中まで、継ぎ手やラインなどをつけろや、パネルに違う役割のラインの構成部品の継ぎ手、違う設計グループの構成部品などをASSYしろなどです。

図面やリストは確かにすっきりしますが、設計そのものが崩壊すると自分は思います、テストモデルがすでにできているから変えたくないというのも、ありますが、非常に悩んでいます。
現在3Dで設計してる方どうかアドバイスをいただけませんかよろしくお願いします。
ちなみに、ソフトはPRO/E　WF3を使用しています。

アドバイスありがとうございました。

＞役割などは無視して製造の考えるASSYの構成、リストにしろと言います、　例でポンプASSYにライン設計の途中まで、継ぎ手やラインなどをつけろ　　や、パネルに違う役割のラインの構成部品の継ぎ手、違う設計グループの　構成部品などをASSYしろなどです。

実際に上のような構成にして、失敗した事がある方
是非、どういう事が起きたか、どう対応したか、どうするべきだったか
などの経験を聞かせていただけませんか？　おねがいします。

逆に成功した経験がある方も是非、話を聞かせてくれませんか？
おねがいします。

通報する

回答 （1件中 1～1件目)

2008/07/03 11:38
回答No.1

>>ポンプ（サポート付）ASSYなど設計　→　ライン、構成部品設計　→　サポート設計　　の役割ごとのような感じです。

良くわかりませんが
モジュール毎　に　分別すること？

上司の基本的に保守派　
今までやってきたことを否定されるみたいなので

ただ説明がへたくそなため、理解されていないだけかもしれません


私も、新しい設計指向を導入しようとしていますがなかなか難しいです
ただ、私の進めている設計方法だと　設計時間は短くなります

現に2時間ぐらい残業して帰る
（定時に上がっても、あまり変わらないんだけどね）

>>2Ｄでやってきた考えかたは、そのままで、3Ｄでも設計の考え方も同じに
しようと

2D時代がどうなっているのかわかりませんが
３Dの場合　現物と同じです


私は２Dの頃から現物（オブジェクト）として設計しているので手法が変わっているわけではないのですが、
現場の人は逝き当たりばったりなので、戸惑っています



>>モジュール内のサブassyの事です

文面から
たぶん私と同様なことを考えているよですが

私はもう一歩先を考えてます
たぶんモジュール化まで　私はオブジェクト化してる


と偉そうに言っても、私が独自に編み出しと方法ではなく
ソフトウエアーの作り方の一つであるOOP（オブジェクト指向）をそのまま当てはめているだけですが



参考
http://iwatam-server.sakura.ne.jp/software/devintro/oo/oo/index.html

ただし、oopは難解であるため、ソフトウエアの世界でもあまり普及していない（正しく理解されているという意味で）　言語がOOPなので、OOP組んでいる感じです
わたしは、20年ぐらい言っていますが（ちなみにOOPの技術は、そうとう古くからある、現在はアスベクト指向に移行しているみたい（私は理解してませんが）
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B9%E3%83%9A%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0




ヒストリー系の３DCADはもろ、
OOPなので
（やってることが　OOPで考えると早いが、モジュールで考えると複雑になる）



OOPで組むと設計時間も短くなり
単純ミスも減ります（大ボケはいつまで立っても大ボケですが）


タダ理解されませんが難解のため
（３DCADをかまうと理解されるんだけどね　OOPだから）

たぶんオブジェクト指向の導入部でハマってる感じです

オブジェクト指向は、プログラムを現物の物として扱って
プログラムしようと言う方法です

良く解説書に　これは犬です　とか分けのわからない解説でてます
オブジェクト指向の持ち主なら、これが真理なんですが
全くわからない人には理解できません

当たり前のこと言っているようにしか聞こえないから

ここで講義するのもなんですが吊られて程度に


例
エアーラインの設計の場合（オブジェクト指向に向いてるから）


工場内すべての配管を（末端まで）理解しようと思ったら大変です
考えただけでおぞましい


オブジェクト指向としての考え方

まず、基線を考えます
コンプレッサーが有り　ドライヤーが有り　リザーバーが有り　

絵で書くとシンプルです


そこに、A　B　C　と　SUBASSYをぶら下げていくのです

Aの中にはいろいろな機能があるが　
親図から見るとポート径ぐらいしか見えない

B　C　と言っても同様です

A　中にはさまざまな機能があるかも知れますが　
基線側からみればポート径と、必要流量　必要圧ぐらいしか必要有りません
ほかの情報は要らないのです　　　　

隠蔽　ブラックボックス化

人によっては見ようとするかもしれませんが
それは
Aと言う図面を持ってこさせて見ればいいのです

B
C　も　同様

こうすることによってどんな複雑なものでも　理解できます


>>供給箇所（スタート）からポンプ（ゴール）までを一つのASSY内で設計するのが、間違えだと思えないんですよ。

これは、設計者側から見た意見であって
使う側からすれば　その端末意外しか知らなくてもいいんですよ
まあ、見るときは



まあみても基線位でしょう
隣がどうなっていようが知る必要なないのです
（何があるのかぐらいは知る必要があるかもしれませんが）

お礼

ひととおり読ませていただきました。
受け取りかたで自分のほうが肯定されてるような否定されてるような
でした。（プログラムはよくわかりませんが。）
＞　5. オブジェクトの意味
　　内包
　　　犬とはどんなものかを定義する

　外延
　　どれが犬かを定義する

　機能
　　犬にはどんなことができるかを定義する
＞　6. まとめ
　　　オブジェクトは「機能のまとまり」ではありません。「概念のまとま　　り」なのです。「機能」はとりあえず忘れよう、というのが合言葉であ　　ることを忘れてはいけません。

　　オブジェクト指向に限らず、システムはシンプルイズベストです。問題　を領域に分け、その領域の中で必要かつ十分な定義をします。慣れてくる　と実世界をより精密にモデリングしようとたくさんのオブジェクトを含ん　だ図を書いてしまいがちですが、それが対象領域(ドメイン)にとって本当　に必要なのかを取捨選択しなければなりません。たくさんオブジェクトを　定義して複雑なモデルを作るより、少ないオブジェクトでシンプルな定義　をする方がずっと有用なのです。

この文章を見て自分は間違えていないと、思えるのですが、
やはり、役割やグループが違うオブジェクトをモジュール化（ASSY化）
していくのが正しいのでしょうか？
たとえばエアーラインを設計していく時、供給箇所（スタート）から
ポンプ（ゴール）までを一つのASSY内で設計するのが、間違えだと思えないんですよ。
しつこくてすいませんが、アドバイスの方をどうかおねがいします。　

わかりました、ありがとうございます。
初めての投稿でしたので満足度3なんかにしてすいませんでした。
非常に助かりました。

＞ポンプASSYにライン設計の途中まで、継ぎ手やラインなどをつけろや、 パネルに違う役割のラインの構成部品の継ぎ手、違う設計グループの構成部品などをASSYしろなどです。

現在自分のプロジェクトと別に上の様にしようとしているプロジェクトがあり、それに無理やり合わされる可能性があるといった状態でした、
ですが、今回の回答おかげでで、討論してオブジェクト指向よりになるように、がんばってみようと思います。
本当にありがとうございました。

2008/07/03 17:06

補足

返答ありがとうございます。

2Ｄでやってきた考えかたは、そのままで、3Ｄでも設計の考え方も同じに
しようと、思いやってきました。

はははさんはツールを変えたら、設計の考えかたそのものも変える考えでやっているのですか？

>>ポンプ（サポート付）ASSYなど設計　→　ライン、構成部品設計　→　サポート設計　　の役割ごとのような感じです。
>>良くわかりませんが
モジュール毎　に　分別すること？

モジュール内のサブassyの事です　（こちらでは、モジュール単位を架台数という考えでやっています。）

>>ただ説明がへたくそなため、理解されていないだけかもしれません
説明は確かに下手です。
わかりにくくてすいません。

>まず、基線を考えます
コンプレッサーが有り　ドライヤーが有り　リザーバーが有り　

絵で書くとシンプルです


そこに、A　B　C　と　SUBASSYをぶら下げていくのです

Aの中にはいろいろな機能があるが　
親図から見るとポート径ぐらいしか見えない

B　C　と言っても同様です

A　中にはさまざまな機能があるかも知れますが　
基線側からみればポート径と、必要流量　必要圧ぐらいしか必要有りません
ほかの情報は要らないのです　　　　

つまり大きい所はそのままで、

TOPストーリー（基線図）
　　ポンプへつなぐラインを作ろう
　　レギュレーター、メータ、電磁弁、継ぎ手が必要だな
　　それらをつなぐ必要があるな。だったらそれらをA,B,Cに分けて

　SUBストーリーA　レギュレーターとメーターと継ぎ手を仲間に
　　　　　（単体）　　　　　　　
　SUBストーリーB　電磁弁と継ぎ手、ほかで設計したポンプを情報で持って　　　　　（単体）くる。　
　SUBストーリーC　それらをつなぐライン。
　　　　　（単体）　　　
TOPを隠蔽して（ポート径と、必要流量　必要圧以外）ABCを見て作ってもらう。
こんなイメージでいいですか？

2008/07/03 11:58

このQ&Aは役に立ちましたか？

はい（0）

この質問は投稿から一年以上経過しています。
解決しない場合、新しい質問の投稿をおすすめします。

質問する

関連するQ&A

お礼をおくりました

さらに、この回答をベストアンサーに選びますか？

ベストアンサーを選ぶと質問が締切られます。
なおベストアンサーを選びなおすことはできません。

サポートシェアリングソリューション 企業・団体・テーマ

Powered by OKWAVE

OKWAVE Plusは、OKWAVEを利用したご利用中の製品・サービスの疑問をみんなで解決するQ&Aコミュニティです。

企業のみなさまへ 金融機関のみなさまへ 自治体のみなさまへ

© 2023 OKWAVE, Inc. 

okwave.co.jp