Аргументы выбора Catia

[MArtmath 0]

Сборки сборками - а как вы чертежи с cgr делаете? (При approximate - половина линий не прорисовывается...)....Хотя для общего представления (как это должно выглядеть в принципе) хватит...

[ExtraRight 1]

Начиная с 14-го релиза (может и раньше) при создании чертежа со сборки в кеш режиме подгружаются только точные солиды (BRep - Boundary Representation) без деревьев создания. Если сборки были созданы в более старых релизах, то есть утилитка по апгрейду оных (в хелпе подробно прописано). В новых сборках всё работает.

Хотя, не скрою, создание сложных чертежей с множеством ассоциативных видов с больших сборок - это есть лимитирующий момент. Я думаю, что проблема будет решаться так - вот вам 64-битное приложение, ставьте оперативку 16Гб, 32 Гб, (может быть, в дальнейшем этот процесс распараллелят на процы), ставьте несколько процев - в общем, другого пути как экстенсивный, я не вижу

[Max KZK 2]

Насчет изящества продуктов Старого и Нового света см. ссылку.

http://fsapr2000.ru/index.php?s=&a...st&p=123409

Разные "слои" в разных файлах - это преимущество а не недостаток.

1) Регулярный файл получается легче. Если не нужно тетраэдральное представление - его и не делаем каждый раз и не храним.

2) Процесс более прозрачени и управляем (хотя, пользователь может cgr-ы и не видеть вовсе, если захочет)

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

4) Воксельные представления весят очень мало (сборка в моем аватаре около 40 метров) Так что дисковое пространство не проблема.

5) Механизм генерации cgr очень хорошо продуман и при грамотном использовании незатратен по поцессорным ресурсам (учитывается даже часовой пояс при распределенной работе)

Блин, завязываю. А то наболтал еще на $600

[ExtraRight 1]

Макс не совсем корректно выразился

40 метров - это сумммарный размер всех автоматически сгенерированных сгр-ов, входящих в его комбайновую сборку, скидывающиеся в одну папку

Если сохранять всю сборку через сейв ас в единый файл сгр - такое тоже возможно, то он будет весить процентов на 20 меньше

[Gringo 0]

Позволю и себе добавить пару слов в пользу выбора Catia V5...

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

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

Колосальные возможности по организации ассоциативных связей также заслуживают уважения.

Да и всего не перечесть... кто работает в Catia v5 меня поймёт.

[Gringo 0]

Аналогично... конечно хватает неприятностей и в кате...

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

Для серьёзных проектов требуется система PDM (PLM). Да это теже стоит денег. Да, для этого нужны знающие люди для настройки. Но извините за такое же сравнение, Запорожец вам настроит и починит Вася Краников из соседнего гаража, а свой любимый Мерин надо волочить в сервис-центр... где знают что к чему...

[*.tmp0020 4]

Вопрос:

Кто работая в кате использует для работы макросы?

Какие и сколько штук?

Изменено 6 октября 2006 пользователем ART

[Gringo 0]

Вопрос:

Кто работая в кате использует для работы макросы?

Какие и сколько штук?

Уточняющий вопрос. Макросы делающие что? С какой целью?

А вообще, в одном из проектов (давно уже) использовали скрипты. Что по сути одно и тоже, при условии что мы понимаем одно и то же под словом "макрос".

[Max KZK 2]

Это в автокаде макросы. А в катьке PowerCopy, Product Knowledge Template и UserFeature.

[Gringo 0]

А если серьёзно, то что делают

в катьке PowerCopy, Product Knowledge Template и UserFeature

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

Только завтра

[Max KZK 2]

2 All правоверным Про-Ешникам и другим. О технологии Knowledge Based Engineering можно почитать здесь: <noindex>http://isicad.ru/2004/presentations/ledas.zip</noindex>

<noindex>http://isicad.ru/2004/presentations/cd_ledas.zip</noindex> (warning! 100 MB)

Тему KBE vs программирование я как-то поднимал на форуме, но похоже остался непонятым.

http://fsapr2000.ru/index.php?showtopic=7815

Описывать катийный функционал я без $300 не буду. Ув. Gringo может быть уговорится, но не уверен.

Макросы в кате тоже есть, но очень мало кто использует, неудобно сделаны,

Макросы ИМХО вообще не очень удобная штука. И в катьке тоже. Только ои там по большому счету не нужны. По-моему их там сделали по принципу "шоб було".

[ART 511]

Все что не относится напрямую к Катие вырезано! У кого есть притензии - читаем правила!

Здесь впредь будут обсуждаться только достоинства и недостатки Катия!

Весь остальной флуд будет резаться и нещадно наказываться!

Добрый модератор ART

[GSU 0]

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

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

[Gringo 0]

Меры борьбы с этим известны - сохранение в разных файлах копий модели такой детали по числу разных способов обработки.

К этому нечего добавить. Надо привыкнуть работать корректно. Каждая деталь имеет уникальную геометрию. Это намного удобнее чем один файл детали и куча исполнений.

З.Ы.

Да ещё может быть полезной Paste Special With Link, чтоб все копии редактировались с одного родителя. Но пользоваться этим надо тоже аккуратно.

Изменено 6 октября 2006 пользователем Gringo

[SVB 188]

Gringo, а если разница в исполнениях деталей копеечная, а детали сами по себе сложные?

Всё равно — копируй файл? И что значит намного удобнее? Можно тезис подробней развернуть?

[Gringo 0]

Gringo, а если разница в исполнениях деталей копеечная, а детали сами по себе сложные?

Всё равно — копируй файл?

А в чем тут у вас проблемы? Вам места на винте мало? Или не менее копеечная операция копирования напрягает?

И что значит намного удобнее? Можно тезис подробней развернуть?

С точки зрения управления данными.

Если быть дотошным, то последнее надо было вынести в отдельную тему, так как к вопросу "Аргументы выбора Catia" это не имеет отношения.

[*.tmp0020 4]

(например, выполнение отверстия в пакете деталей) все результаты операции сохраняются в моделях этих деталей

-""Катя, мне не надо на деталях""

-""А тебя никто не спрашивает, ПАЛУЧАЙ!""

Занятная фича. Мне понравилось, гы гы...

А в чем тут у вас проблемы? Вам места на винте мало?

Действительно! Если уж 3 гига на инсталяцию голой кати(без фалов справки)

вбухали, то места на винте у вас никак не мало должно быть! гы гы...

Ведь как вы помните, она нежирная и непрожорливая...

(рекомендуемая оперативка 4гига)

[SVB 188]

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

Судя по жизненному опыту — отличающий одну деталь от другой объём исполнения врятли будет превышать остальную часть детали. Как раз с точки зрения управления данными лучше, чтобы в оперативке была загружена одна детали, и, по мере необходимости, дополнялись ТОЛЬКО отличия её в других исполнениях. Меньше загрузка железа, меньше надо шарить головкам HDD по пластинам, чтобы считывать КАЖДУЮ деталь. Разумеется, всё это ИМХО.

Вырезано

[ExtraRight 1]

Действительно самый пральный способ - это использование Paste with Link. Мы это использовали в случаях, когда деталь после сборки обрабаотывается в составе сборки, причём одна и та же деталь могла обрабатываться на нескольких уровнях сборок (до 5-того).

То есть: модель детали в виде до первой сборки - с неё создаётся рабочий чертёж. Далее создаётся новый парт, туда копируется Paste with Link тело, этот парт учавствует в сборке, и в него сохраняется изменение геометрии в составе сборки. И так на нескольких уровнях.

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

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

[Gringo 0]

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

Судя по жизненному опыту — отличающий одну деталь от другой объём исполнения врятли будет превышать остальную часть детали. Как раз с точки зрения управления данными лучше, чтобы в оперативке была загружена одна детали, и, по мере необходимости, дополнялись ТОЛЬКО отличия её в других исполнениях. Меньше загрузка железа, меньше надо шарить головкам HDD по пластинам, чтобы считывать КАЖДУЮ деталь

Очень спорное утверждение.

Вырезано

-------

Сытый голодного не понимает.

Изменено 8 октября 2006 пользователем ART