многотельность

[Sxela 15]

Вполне возможно у Вас была ограниченная лицензия. Функционал от этого сильно зависит. Есть ограничения на сборочные операции над деталями, в ПроЕ нет виртуальных компонентов, то есть материал вы добавить не можете. Редактирование же детали на уровне сборки не вопрос.

Sxela

Так как Вы расписали, ни в первом ни во втором случае никто не делает. Крайние случаи на то и крайние.

Многотельную же сборку нужно обязательно распускать, потому как делать деталировку на основе сборки, это...

Так я и не говорил, что делать нужно только так и не иначе. Просто наверное неудачный пример привел :( .

По поводу второго замечания, по "роспуску" сборки - все зависит от особенностей системы. Скорее всего вы меня не так поняли.

В TF есть понятие внутренний фрагмент - геометрия детали не обязательно должна "выгружаться" из сборки в отдельный, внешний файл.

Геометрия детали может храниться в файле сборки, и это будет геометрия только этой детали (как отдельный блок),

при этом возможны различные варианты взаимодействия между сборкой и данной геометрией.

Внутренний фрагмент это самостоятельная деталь, на нее можно делать отдельную КД, кстати она также будет храниться в файле сборки.

Т.е. в данном случае в одном файле храниться сборка, детали и КД на них.

При необходимости для отдельных (или всех) деталей можно выполнить "роспуск" во внешние файлы в виде независимой копии,

и (или) зависимой от конфигурации сборки копии, и (или) заменой на внешний фрагмент (геометрия полностью выгружается из сборки и возвращается обратно но у же в виде внешней детали). Вместе с геометрией будет "выгружена" и вся КД на деталь.

Копии таких деталей вместе с КД могут быть использованы в других сборках как заимствованные.

[Ruslan 266]

Sxela

Вообще хотелось бы несколько разделить понятия. Хоть это и трудно - Многотельность размытое понятие. Более важно как в программе реализованы взаимосвязи элементов и насколько они удобны пользователю в конкретном случае.

Безусловно что одна модель и чертеж на нее в некоторых удобно держать в одном файле. Но много разных не есть хорошо. Я вспоминаю времена работы на Гос. предприятии, когда работники использующие Автокад держали в одном файле все изделие, вместе с аннулированными чертежами, это было что то...

п.к. Разбирать плюсы и минусы многотельности и альтернативный функционал на основе t-flex и UG не совсем получится. В этих программах это базовая основа, без нее от них толку не будет. Скорее лучше рассматривать SW как представителя двух подходов, где-то по середине между ПроЕ и T-flex.

[Sxela 15]

Sxela

Более важно как в программе реализованы взаимосвязи элементов и насколько они удобны пользователю в конкретном случае.

Во многом удобство - это дело привычки.

Многое со стороны кажется не удобным пока серьезно не попробуешь.

На мой взгляд, хорошо если программа дает пользователю ряд возможностей

из которых можно выбрать лучший под конкретные обстоятельства.

Хуже когда выбор ограничен...

Труднее тем, кому при смене места работы, приходится осваивать "новый" CAD. Всякого наслушаешься.

Но со временем привыкают, находят плюсы в том. что раньше считали ненужным...

[Гость aleank]

1. первый

- подумал, прикинул, может быть наброски сделал, состав определил (деталей под 100);

- сел делать трехмерку деталей;

- походу создания деталей начинаю компоновать их в сборке, естественно вылезают "косяки" по размерам, форме, исполнению;

- многократно редактирую детали, трудоемкость возрастает по мере увеличения их количества - процесс сводится к итерационному.

Sxela

А что мешает работать сразу в сборке(сверху вниз)? все косяки видно - редактировать удобно, еще можно сразу использовать анализ и оптимизацию.

[ART 511]

Атан

По Вашему, многофункциональный файл - это недостаток?

При работе с повторяющимися типовыми элементами, это несомненое достоинство. Недостатком такого файла является его размер, и любой сбой внутри такого файла может привести к потере большого количества важной информации (при раздельном проектировании сбой в файле модели например не убьет намертво файл с расчетами или чертежами). Мало того наличие большого количества таких "распухших" файлов могут значительно тормозить работу проекта.

А в конечном итоге имеем: файл сборки, файл детали... Так есть разделение (как оно организовано, пользователю не важно) или нет?

В конечном итоге у вас есть один файл в котором хранится все что угодно и пока вы этот файл не откроете вы не знаете, что там хранится и не важно с каким шаблоном вы этот файл создали. Можете пользоваться одним единственным шаблоном Blank, результат будет один и тот же. Так что физического разделения никакого нет. Все разделение зависит от пользователя, "что хочу, то ворочу".

Физическое разделение это когда у вас есть файл с расширением .dft и вы точно знаете что в нем хранится чертеж и ничего большего и засунуть большее вам не дано программой.

Недостатки многотельности:

1. Наличие построительного ошибочного "мусора" не относящегося к детали. Это всевозможные "обрезки" висящие неизвестно где при булевых операциях или отсечениях одного тела об другое, а так же стенки с нулевой с толщиной, которые появляются при этих же операциях.

2. Длинное дерево построения, и соответственно долгая регенерация при изменениях. Соответственно сложность в понимании процесса создания модели, другим человеком. Редки те случаи когда тот кто строит многотельную модель, структурирует (компонует) дерево построения.

3. Никак не контролируемые кросс линки. Если в сборках еще можно "убить" линк между деталями, то в многотельной детали, таких инструментов в нет.

4. Сложности с трансляцией. Как правило в файл перед трансляцией нужно очищать (скрывать) от мусора. Не редки случаи когда из-за наличия такого мусора производится брак.

5. Сложность с визуализацией сборок, когда вместо нужного тела видны другие тела присутствующие в многотельной детали. Всегда нужно заботится чтобы нужное тело или имело соответствующий аттрибут или было расположенно на отдельном слое.

6. Сложнось с созданием чертежей. Нужно всегда заботиться чтобы именно та деталь была на чертеже и именно ее аттрибуты находятся в таблицах.

7. Сложность в управлении проектом. Нужно всегда держать открытым многотельный файл, чтобы менять параметры или перевязывать параметры в сборке. Если не дай бог сглючит или будет утерян многотельный файл то вообще можно получить мертвый не редактируемый проект.

[Атан 460]

Недостатком такого файла является его размер, и любой сбой внутри такого файла может привести к потере большого количества важной информации... Мало того наличие большого количества таких "распухших" файлов могут значительно тормозить работу проекта.

Неубедительно. Пользователь сам определяет структуру и объём файла.

В конечном итоге у вас есть один файл в котором хранится все что угодно и пока вы этот файл не откроете вы не знаете, что там хранится и не важно с каким шаблоном вы этот файл создали... Все разделение зависит от пользователя, "что хочу, то ворочу".

А что мешает класть сборки в одну папку, детали в другую, чертежи в третью? Я именно так и делаю , независимо от расширения файла (dwg). И в SW тоже.

Недостатки многотельности:

1. Наличие построительного ошибочного "мусора" не относящегося к детали. Это всевозможные "обрезки" висящие неизвестно где при булевых операциях или отсечениях одного тела об другое, а так же стенки с нулевой с толщиной, которые появляются при этих же операциях.

2. Длинное дерево построения, и соответственно долгая регенерация при изменениях. Соответственно сложность в понимании процесса создания модели, другим человеком. Редки те случаи когда тот кто строит многотельную модель, структурирует (компонует) дерево построения.

3. Никак не контролируемые кросс линки. Если в сборках еще можно "убить" линк между деталями, то в многотельной детали, таких инструментов в нет.

4. Сложности с трансляцией. Как правило в файл перед трансляцией нужно очищать (скрывать) от мусора. Не редки случаи когда из-за наличия такого мусора производится брак.

5. Сложность с визуализацией сборок, когда вместо нужного тела видны другие тела присутствующие в многотельной детали. Всегда нужно заботится чтобы нужное тело или имело соответствующий аттрибут или было расположенно на отдельном слое.

6. Сложнось с созданием чертежей. Нужно всегда заботиться чтобы именно та деталь была на чертеже и именно ее аттрибуты находятся в таблицах.

7. Сложность в управлении проектом. Нужно всегда держать открытым многотельный файл, чтобы менять параметры или перевязывать параметры в сборке. Если не дай бог сглючит или будет утерян многотельный файл то вообще можно получить мертвый не редактируемый проект.

1. Многотельность тут ни при чём. Это есть везде.

2. Не согласен, особенно для NX.

3. А зачем убивать линки в многотельной детали (просто не знаю)? И как убить то, чего нет?

4. Многотельность тут ни при чём. Это есть везде.

5. Есть такое (в NX).

6. 7. Это в большей степени относится к методике работы в той или иной системе.

[ART 511]

Атан

Неубедительно. Пользователь сам определяет структуру и объём файла.

Убедительно будет когда вы попробуйте поработать в удаленке в большом проекте.

А что мешает класть сборки в одну папку, детали в другую, чертежи в третью. Я именно так и делаю , независимо от расширения файла (dwg). И в SW тоже.

Можете класть их куда хотите, можете вообще пользоваться PDM. Суть от этого не меняется. В NX нет физического разделения на среды. Вся информация хранится в одном файле, вне зависимости в каком шаблоне его открыли.

Это есть везде

Никогда не говорите "есть везде" если вы об этом "везде" не знаете.

1. Многотельность тут ни при чём. Это есть везде.

В SE этого нет, система не дает делать булевые операции если результатом таковой будет не связанные между собой куски тел. Или стенка с нулевой толщиной.

2. Не согласен, особенно для NX.

Оторвитесь от NX с его ST где вообще можно забыть о дереве и попробуйте поработать в других системах например в Cimatron-e где нет намека на структурирование дерева. И ваше несогласие быстро перерастет в согласие. Мало того регенерация в Cimatron-е многотельной детали с длинным деревом может быть убийственна как по времени так и по результату.

3. А зачем убивать линки (просто не знаю)?

Затем что иногда некоторые вумные товарищи умудряются делать в многотельных моделях перекрестные ссылки, т.е строят 2 твердых тела и сначала отнимают от первого второе, а после в забытьи отнимают от второго первое. После этого они плачут почему программа ругается и файл не открывается. В сборках такую перекрестную ссылку можно заморозить или удалить, а в детали не выйдет, нет инструмента. В SE таких проблем нет потому что отнять или прибавить можно только к одному твердому телу.

4. Многотельность тут ни при чём. Это есть везде.

Этого нет в SE потому что по умолчанию в транслируемый файл попадет только один единственный твердый объект. Если же вам нужно чтобы попал "мусор" тогда нужно лезть в настройки транслятора.

6. 7. Это в большей степени относится к методике работы в той или иной системе.

В SE в чертеж также попадает только один твердый объект, а мусор попадает только по желанию пользователя.

[Ruslan 266]

В SE этого нет, система не дает делать булевые операции если результатом таковой будет не связанные между собой куски тел.

То есть в SE в модели не может быть несколько не связанных твердотельных объема?

Хотя согласно справке SW это считается многотелом, я не считаю это многотелом.

[ART 511]

Ruslan

То есть в SE в модели не может быть несколько не связанных твердотельных объема?

Хотя согласно справке SW это считается многотелом, я не считаю это многотелом.

Может. Но масса расчитывается как будто это одно тело. Кстати, сейчас проверил эта сцука научилась делать булеан, оставляя бессвязные куски в воздухе. Но масса этих бесвязных кусков все равно считается как для одного тела, и высвечивается как одно тело. Короче, убрали наполовину защиту от "дурака".

[Атан 460]

Можете класть их куда хотите, можете вообще пользоваться PDM. Суть от этого не меняется. В NX нет физического разделения на среды. Вся информация хранится в одном файле, вне зависимости в каком шаблоне его открыли.

Разве я отрицал наличие многофункционального файла?

...В SE этого нет, система не дает делать булевые операции если результатом таковой будет не связанные между собой куски тел. Или стенка с нулевой толщиной.

Оторвитесь от NX с его ST где вообще можно забыть о дереве и попробуйте поработать в других системах например в Cimatron-e где нет намека на структурирование дерева. И ваше несогласие быстро перерастет в согласие. Мало того регенерация в Cimatron-е многотельной детали с длинным деревом может быть убийственна как по времени так и по результату.

Затем что иногда некоторые вумные товарищи умудряются делать в многотельных моделях перекрестные ссылки, т.е строят 2 твердых тела и сначала отнимают от первого второе, а после в забытьи отнимают от второго первое. После этого они плачут почему программа ругается и файл не открывается. В сборках такую перекрестную ссылку можно заморозить или удалить, а в детали не выйдет, нет инструмента. В SE таких проблем нет потому что отнять или прибавить можно только к одному твердому телу.

Этого нет в SE потому что по умолчанию в транслируемый файл попадет только один единственный твердый объект. Если же вам нужно чтобы попал "мусор" тогда нужно лезть в настройки транслятора.

В SE в чертеж также попадает только один твердый объект, а мусор попадает только по желанию пользователя.

Ваше сообщение только подтверждает, что это в большей степени относится к методике работы (можно и лом вставить в монитор) в той или иной системе и к самой системе, а не к многотельности.

...Хотя согласно справке SW это считается многотелом, я не считаю это многотелом.

Посмотрите в дерево построения (папка Тела).

[Ruslan 266]

Посмотрите в дерево построения (папка Тела).

Я еще раз прошу давайте разбирать цели, а не отображение. То что оно отображается в дереве, еще ничего не значит. В справке в этом разделе и слова об этом нет.

Многотел в моем понимании это два или более твердотельных объемов, не объединенных булевыми операциями (даже при пересечении) и которым можно назначить различные материальные свойства.

Пример справки Обзор многотельных объектов:

Используя многотельные детали, можно создать обод и ось, а затем создать спицу для соединения с этими телами.

В том же ПроЕ, как и в других программах строится без всякого многотела, точно также.

Связывание - часто используемый способ в многотельной среде. При связывании создается твердое тело, состоящее из нескольких связанных между собой твердых тел. Этот способ полезен, когда сначала создаются части модели, а затем связывающая геометрия.

То же самое.

Местные операции используются, когда необходимо выполнить операцию не со всеми частями многотельной модели, а только с определенными ее частями. Например, спроектировать двойную мерную чашку. Необходимо создать оболочку для двух чашек и скруглить их.

То же самое, многотела здесь тоже не нужно. Операция оболочки позволяет исключить не нужное. Хотя при большом количестве под оболочку, выбрать тело проще, но в системах с деревом построения это не проблема. Здесь многотел выигрывает, хотя если рассматривать конкретный пример, то многотела для него не нужно вообще.

Симметричное моделирование упрощает создание деталей, имеющих оси симметрии, а также повышает скорость обработки для этих типов деталей. При таком подходе сначала создается одно симметричное тело, затем массив

То же не понял примера, зачем здесь многотельность.

Используйте моделирование тел инструментов для создания сложных многотельных инструментов, чтобы удалить материал из твердого тела, или для добавления сложных форм в геометрию

Согласен это уже многотельность... Но данная возможность есть в ПроЕ, хотя многотела нет.

Для способа пересечения многотельных тел используется элемент Соединить и его параметр Общий.

Нет только пересечения объемов созданных на уровне детали, втянутые и на уровне сборки можно. Данный функционал в ПроЕ реализован через поверхностное моделирование.

п.к. не объединенных булевыми операциями (даже при пересечении) к своему сожалению, мне удалось создать подобный глюк в ПроЕ..., если совместить не пересекавшиеся объемы (и не изменившейся массой).

[ART 511]

Атан

Разве я отрицал наличие многофункционального файла?

Причем здесь отрицание многофункционального файла, читайте то что вам пишут внимательно. Вы писали...

Там есть физическое деление на сборки и детали. Даже при открытии нового файла выпадает окно, где на выбор предлагается открыть файл нужного типа (так же есть шаблоны: детали и сборки) .

Я вам отвечаю:

В NX нет физического разделения на среды. Вся информация хранится в одном файле, вне зависимости в каком шаблоне его открыли.

Ваше сообщение только подтверждает, что это в большей степени относится к методике работы (можно и лом вставить в монитор) в той или иной системе и к самой системе, а не к многотельности.

Мой пост подтверждает не методики работы в той или иной системе, а недостатки многотельного моделирования, которые напрочь отсутствуют у систем не имеющих функционала многотельности. В разных системах эти недостатки прикрывают различным функционалом, который вы выдаете за некие методики.

[Атан 460]

Я еще раз прошу давайте разбирать цели, а не отображение. То что оно отображается в дереве, еще ничего не значит. В справке в этом разделе и слова об этом нет.

Многотел в моем понимании это два или более твердотельных объемов, не объединенных булевыми операциями (даже при пересечении) и которым можно назначить различные материальные свойства.

Если в дереве отображаются разные тела, значит им "можно назначить различные материальные свойства".

Пример справки Обзор многотельных объектов:

Используя многотельные детали, можно создать обод и ось, а затем создать спицу для соединения с этими телами.

В том же ПроЕ, как и в других программах строится без всякого многотела, точно также.

Только материалы у деталей разные ( в ПроЕ - одинаковые).

То же самое, многотела здесь тоже не нужно. Операция оболочки позволяет исключить не нужное. Хотя при большом количестве под оболочку, выбрать тело проще, но в системах с деревом построения это не проблема.

Нет только пересечения объемов созданных на уровне детали, втянутые и на уровне сборки можно. Данный функционал в ПроЕ реализован через поверхностное моделирование.

Т.е. для достижения желаемого результата, нужны дополнительные действия.

[Атан 460]

Причем здесь отрицание многофункционального файла, читайте то что вам пишут внимательно. Вы писали...

Там есть физическое деление на сборки и детали. Даже при открытии нового файла выпадает окно, где на выбор предлагается открыть файл нужного типа (так же есть шаблоны: детали и сборки).

Вы придираетесь к словам. Из верхнего текста я убераю слово физическое. Так пойдёт?

Мой пост подтверждает не методики работы в той или иной системе, а недостатки многотельного моделирования, которые напрочь отсутствуют у систем не имеющих функционала многотельности. В разных системах эти недостатки прикрывают различным функционалом, который вы выдаете за некие методики.

Если есть какой-либо функционал, то появляются и методики для работы с этим функционалом. Но это не есть недостатки. Вот отсутствие многотельности - это недостаток.

Ходить пешком на большие расстояния как-то неудобно, поэтому придумали машины. Но они ломаются, это недостаток. Если следовать такой логике , то многотельность - это недостаток.

[Ruslan 266]

Т.е. для достижения желаемого результата, нужны дополнительные действия.

Не больше чем просто при построении тел а затем их объединении. Да поверхности нужно объединять для реализации того или иного способа, в сложных случаях. В некоторых же ситуациях действий нужно проделать наоборот меньше.

Только материалы у деталей разные ( в ПроЕ - одинаковые).

Да это так. А что литой диск состоит из нескольких материалов? Пример неудачный.

Вот пластмассовый флакон с двухкомпонентным литьем это удачный пример. И в ПроЕ для вычисления массы будут нужны дополнительные действия.

Если в дереве отображаются разные тела, значит им "можно назначить различные материальные свойства".

это не так. В том же SW эта возможность появилась позже чем тела в дереве...

[Атан 460]

это не так. В том же SW эта возможность появилась позже чем тела в дереве...

Это только подтверждает плюсы многотельности, т.е. функционал можно совершенствовать.

[Ruslan 266]

многотельности, т.е. функционал можно совершенствовать.

Не можно, а нужно. И это не плюсы, а недостатки до тех пор пока они не устранены. А недостатки есть...

[Атан 460]

Не можно, а нужно. И это не плюсы, а недостатки до тех пор пока они не устранены. А недостатки есть...

Благодаря многотельности появилась возможность присваивать элементам модели разные физические свойства. Именно это я имел ввиду. А Вы приписываете это к недостатку. Просто удивительно.

[Ruslan 266]

Атан

Не удивительно. Я про А, вы про Б. Что сейчас можно присваивать разные материальные свойства я и так знаю...

Я не умоляю плюсов многотельности, и где ее удобно применять я писал.

Отсутствие многотельности в программе, не означает что в ней нельзя работать эффективно. Ее отсутствие не мешает...

п.к. Разговор на общие темы ничего хорошего не даст. Пока не начнем разбирать конкретные цели. Для общей пользы всех форумчан...

[BSV1 1 724]

Вот пример <noindex>http://fsapr2000.ru/index.php?s=&showt...st&p=435635</noindex> где многотельность позволяет очень просто получить нужный результат