PLM-forum.ru

Все предприятия, внедряющие CATIA, рано или поздно сталкиваются со следующей проблемой:

Система не позволяет эффективно управлять конфигурациями деталей в сборке. То есть, в одно время в одной сборке не может быть несколько исполнений детали с отличающейся геометрией. В разное время - пожалуйста. А одновременно - только в разных файлах.
При том, что эта задача достаточно удобно решена во вражеских SW и (по слухам) ProE, часто бывает трудно переубедить конструкторов работать в CATIA.

Лично мне известно два работающих варианта решения задачи:
1) В сборку вставляются отдельные файлы для каждого геометрического представления. Если геометрия парта изменяется уже в сборке (обработка в сборке), то в сборку вставляется отдельный файл для каждого экземпляра детали. Все вопросы с формированием спецификаций решаются при этом на уровне PDM.

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

Может ли кто нибудь что-то добавить к этим методам?

Да, в это ограничение упираются многие и практически сразу. Но всё-таки, я думаю, это не фатально.

Да, следует разделить эту проблему на три подслучая:

1. В сборке нам удобно иметь параметрическую модель с управлением её исполнениями по таблице (Design Table). Например, удобно иногда когда номер исполнения (строки в Design Table) - есть результат одной из специальных функций (см. раздел Design Tables в окне f(x)).
Решение проблемы: имя файла не участвует в спецификации (оно может быть каким угодно, но лучше чтобы несло смысловую нагрузку), а в спецификацию попадают значения идентификационных параметров из свойств компонента (например, Nomenclature как Обозначение (но не PartNumber) и Definition (или Description) как Наименование), которые управляются таблицей.

2. Деталь "гибкая", и деформируется после сборки. Решение практически тоже самое, но есть нюанс: модель детали в свободном состоянии необходима для создания рабочего чертежа, то есть она должна существовать. И для каждой вставки в сборке мы должны создавать свой файл, но (NB) идентификационные параметры у всех реинкарнаций "гибкой" детали должны быть одинаковы.

3. Деталь "обрабатывается после сборки". Решение тоже похожее: из файла, где геометрия в состоянии до обработки, копируется тело (Partbody) со связью (Result with Link) в новый файл, но с теми же значениями идентификационных параметров.

Отсюда следует , что если Вы используете PDM, то (всё, что сейчас будет сказано, успешно применяется на ОАО Криогенмаш) на один компонент с уникальным значением идентификационного параметра может существовать несколько моделей. В этом случае необходимо вводить параметр "Тип модели" и обеспечивать уникальное соответствие компонент-модель только той модели, у которой в "типе модели" указан тот тип, с которой делается рабочий чертёж детали. Моделей со значением "Изменённая в сборке" в параметре "Тип модели" может быть сколько угодно. Так же и других типов моделей, например "габариток" или "упрощенных".

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

То есть Вы хотите сказать, что CATIA как CAD не может управлять конфигурацией сборочных единиц?

Удалено автором.

Атан писал(а):Они хотят сказать, что у CATIA большие проблемы с PDM, PLM (это моё мнение).

Умилительно однозначный вывод

Атан писал(а):И если не будет решена проблема "обработка в сборе", то не будет и CATIA

Напишите об этом в Dassault - правда они скорее всего ответят (не в первой), что их методика хорошо работает и найдут кучу преимуществ, даже с точки зрения PDM, не говоря уже о PLM

D_Voron писал(а):То есть Вы хотите сказать, что CATIA как CAD не может управлять конфигурацией сборочных единиц?

Управление конфигурациями не есть задача CAD системы.

Напишите об этом в Dassault - правда они скорее всего ответят (не в первой), что их методика хорошо работает и найдут кучу преимуществ, даже с точки зрения PDM, не говоря уже о PLM

Вообще-то, одно преимущество есть. Деталь (после обработки в сборке) имеет тот вид, который она реально имеет в жизни (после разборки сборки). В идеале при входе в сборку должно быть четыре кнопки (переключателя).
1. Полностью неассоциативная сборка.
2. Полностью ассоциативная сборка (то, что в CATIA).
3. Прямая ассоциативная сборка (так, как в других САПР).
4. Обратная ассоциативная сборка (изменения в деталях не отображаются в сборке).

если использовать PDM, то вопроса такого быть не должно (у нас не катия, но тоже тяжелый кад) PDM управляет структурой/составом, а CAD подчиняется.

То есть Вы хотите сказать, что CATIA как CAD не может управлять конфигурацией сборочных единиц?

Собственно вопрос возник, т.к. в ЕСКД есть ГОСТ 2.113, позволяющий описывать одним групповым документом несколько изделий. Модель в CAD тоже является докуентом или нет? Что может предложить CATIA для реализации этой идеологии на уровне сборочных единиц?

PDM вещь конечно полезная, но как она может помочь в этой ситуации я не совсем понимаю.

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

В том то и дело, что методы решения данной проблемы в других CAD-ах мне известны, а в CATIA 17 релиза ничего сделать не удалось Вот и решил спросить у знающих людей.

Создавать правила, управляющие набором фичеров и их параметрами в зависимости от таких-то условий пробовали? Деактивировать отверстия, активировать припуски и поменять диаметры/глубину в зависимости от параметра "исполнение" очень легко.

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

А макрос, по заданию активирующий/деактивирующий все сборочные фичи (для устранения оных последствий в деталях для выдачи чертежей деталей) не решит проблему?

Для того, чтобы реализовать ваше желание, в сборке должен храниться ассоциированный клон всей геометрии (а не только описание сборочного фичера), которую вы в сборке пилите. Интересно, какой САПР умеет это?

Касаемо оного решения в Кате - ради интереса я попробовал решить вашу задачу.

Вот что получилось:

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

2. Создана автоматом сборка (детали можно переобозвать, создать иную структуру сборки, соединить произвольно констрейнтами), в которой "клоны" всех деталей сборки из п.1. Далее можно достраивать, дырявить и т.п. эти клоны. Оригиналы остаются неизменны.

3. Изменение же оригиналов наследуются клонами. Даже дополнительные построения в оригиналах появляются в клонах. Правда, тут в определенных случаях могут возникнуть ошибки в клонах, придется их править (в Кате отличный отладчик!!!). Так что думаем сразу об алгоритмах и параметризации, чтоб потом не возиться. Впрочем, исправить достаточно легко.

4. Сборка клонов не имеет (!) лишних элементов, требующих своего исключения из видимости и спецухи. Спецуха будет нормальная.

Если это то, что ищется, то оно нашлось. Причем неожиданно просто. Копи-паст никакой не юзался, сборки в ассоциированные многотельные детали не преобразовывались.

Катя рулит, как обычно. Без шуток. Просто алгоритм... Заранее извиняюсь, что метод подробно описан не будет. Возможно, чуть позже выложу демку, доказывающую работоспособность. Скорость создания сборки клонов равна скорости вставки клонов в сборку, при одноуровневой сборке - мгновенно (тока как комп зальет детальки в вашу сборку). Создание клонов деталей еще быстрее...

P.S. При дальнейшем тестировании выяснилось, что с клонов можно делать еще клоны, все цепочки связей снизу вверх сохраняются, сверху вниз - нет. И даже в сборке с оригиналами можно вставлять любые версии клонов любого поколения. Изменения наследуются все так же. Тестирование продолжается...

zerganalizer, я так понял что самое главное из Вами изложеного это то "....Копи-паст никакой не юзался, сборки в ассоциированные многотельные детали не преобразовывались"....
Кажется это Утилиты - DownwardCompatibility - понижаем версию и сохраняем связи разных файлов...

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

(тему не туда перенесли).

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

Samir писал(а):Все эти сборки из клонов - костыли. Потом задолбаетесь помнить, что есть две разные сборки, одна нормальная, другая клонированная, и оперировать с ней, т.е. делать что-то новое на этой базе и т.п. Сборка должна быть одна, имхо, иначе народ (деталировщики) вас не поймет, да и сами через пару месяцев - тоже.

Извините, что встреваю в разговор, но в мировой практике часто оперируют двумя (как минимум) типами CAD моделей - один тип для процесса разработки узлов и сборок, другой тип - для использования в DMU. Как раз последние обычно и создаются в виде "клонов" со связью. Конечно с этим проще управляться с помощью PDM.

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

zerganalizer писал(а):Не понял про понижение версии.

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

Samir писал(а):Все эти сборки из клонов - костыли. Потом задолбаетесь помнить, что есть две разные сборки, одна нормальная, другая клонированная, и оперировать с ней, т.е. делать что-то новое на этой базе и т.п. Сборка должна быть одна, имхо, иначе народ (деталировщики) вас не поймет, да и сами через пару месяцев - тоже.

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

Придумал вот какую методику для обработки в сборке нескольких исполнений детали.
Хорошо подходит для большого количества деталей небольшого ассортимента.
1) Для каждого типа деталей создается UDF (можно с таблицей, для разных типоразмеров)
2) В сборке, для каждого типа деталей создается своя деталь.
3) В эту деталь вставляем UDF в любом количестве.
4) Поскольку деталь всего одна, резать и сверлить ее можно как угодно. При этом сохраняется возможность менять типоразмеры по таблице.
5) Для того, чтобы посчитать и передать в PDM количество деталей применяется счетчик UDF.

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

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

Кстати, сразу видится два направления развития этой идеи:
1) Сделать каталог крепежа, который также вгонял бы всё в одну деталь, при этом интеллектуально формируя сразу пакеты - болт-шайба-шайба-гайка нужной толщины.
2) Для более общего случая сделать программу, которая формирует одну деталь из нескольких вхождений других деталей в идеале, через CCP-линки. Хотя, вроде, такая функция в 20 катьке есть.

Почему-то никто не упомянул CATShape?

deNSe писал(а):Почему-то никто не упомянул CATShape?

CATShape долгое время даже родным дассошным Смартимом не поддерживался, да и глюки с ними связанные всплывали часто. Кстати, CATShapes возможно использовать только если имеются лицензии типа Equipment & Systems.
А как теперь это работает, проблем или минусов не замечаете, ув. deNSe?