PLM-forum.ru

Методологией надо решать проблемы больших сборок, а не железом...

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

Был бы рад, но по-моему в моем случае методология не очень поможет: я должен в лоб генерировать новые CATProducts из разних компонентов. С удовольствием послушаю, если есть какие-то идеи по оптимизации.

Идей много.

Например, использовать габаритные сборки при построении иерархии изделия.
Можно также использовать Relation design - этот подход, к сожалению, исключает использование SmarTeam.

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

Еще один подход к сожалению реализован только в компании Боиг - использовать специальные просмоторщики с моделями сборки в cgr для многокритериального поиска и загрузки обстановки в CATIA v5 и использование моделей с опорной геометрией для правильного позиционирования деталей с использованием геометрических связей.


Есть еще более продвинутый подход, но он тоже реализован только в Боинг - создание структурных сборок, испльзуя ENOVIA LCA. В этом подходе создаются псевдо сборки, а информация о входимости хранится в специальном объекте CAtPart.

Делюсь опытом: работаю с CATIA V5, задачи - автоматические генерации + манипуляции CATIA Products из детей + positioning. Начал на IBM Т60, 2GHz, 2GB RAM, 256 видео. Работало медленно. По рекомендации клиента перешел на Dell M90, 64бит, 4GB RAM, 256МБ видео, Win XP 64bit, диск 7200 САТА - самий быстрый из того что было на выбор. Обошлось все это в $3000. Результат: видео иногда тормозит, пока не могу понять - то ли диск, то ли карточка. После того как поменял настройку в BIOS, стало работать быстрее. Вообще, видел что у них для совсем серьезных задач используется Dell XPS с двумя видеокартами - стоит порядка $4000-5000.

IBM Т60, 2GHz, 2GB RAM, 256 видео - судя по опыту, эта машинка при попытке сделать многолистовой чертеж сборки из 600 инстансев начнет тормозить...

linde писал(а):Например, использовать габаритные сборки при построении иерархии изделия.
Можно также использовать Relation design - этот подход, к сожалению, исключает использование SmarTeam.
Еще один подход - использовать интерефейсные модели для разбиения больших сборок на части...

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

linde писал(а):Еще один подход к сожалению реализован только в компании Боиг - использовать специальные просмоторщики с моделями сборки в cgr для многокритериального поиска и загрузки обстановки в CATIA v5 и использование моделей с опорной геометрией для правильного позиционирования деталей с использованием геометрических связей.

Ну, про реализацию в Боинге я слышал и хорошее и плохое... То что описывается выше, очень напоминает продукт фирмы RightHemisphere - рекомендую посмотреть.

linde писал(а):Есть еще более продвинутый подход, но он тоже реализован только в Боинг - создание структурных сборок, испльзуя ENOVIA LCA. В этом подходе создаются псевдо сборки, а информация о входимости хранится в специальном объекте CAtPart.

Это случайно не об Exposed Assemblies? Нет, это нам не подходит в любом случае - нестабильное решение.

Bottom line: Могу прислать кусок из своего кода (C# .NET), если будут хорошие идеи по улучшению, с меня пиво?

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

А что значит "генерируем"? имеется в виду использование скриптов написанных в CAA rade или использование knowledgeware?


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

Основные цели таких подходов - минимизировать количество одновременно открытых CATIA объектов и избежать необходимости проведения update (оттянуть саму процедуру аптейда и перевести ее на этап при котором открыты для редактирования будет меньшее количество объектов), загружать упрощенное представление объектов CATIA v5 для тех моделей, которые не будут подвергаться редактированию в текущей сессии.

Ну, про реализацию в Боинге я слышал и хорошее и плохое... То что описывается выше, очень напоминает продукт фирмы RightHemisphere - рекомендую посмотреть.

http://www.righthemisphere.com/products/deeppub/DeepPub_View/index.html



Продукт "Deep View" - что-то похожее, только есть некоторые принципиальные различия - чтобы работать с большими сборками надо иметь возможность открыть в сессии CATIA v5 именно те объекты, которые необходимо будет редактировать в полном представлении и подгрузить обстановку в упрощенном представлении...


Вот эти задачи, к сожалению, судя по описанию, и не решает этот Deep view...


На практике вы должны найти нужную модель для редактирования - несколько парт инстансов - представление в виде CatPart - например, в том же просмоторщике. (в просмотрощике эти объекты будут хранится в cgr, но вам просто надо найти правильное название инстанс нейм)...

Потом вы должны найти обстановку вокруг объекта - представление в виде cgr - тоже в просмоторщике.

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


На практике это значит, что вы должны раз в сутки делать экспорт моделей проекта из системы PDM на сервер просмоторщика одновременно конвертируя все объекты CatPart PDM в cgr. При этом на сервере просмоторщика должно быть организовано виртуальное пространство, модели должны экспортироваться вместе с некоторыми атрибутами системы PDM и т.д.

Основные цели таких подходов - минимизировать количество одновременно открытых CATIA объектов и избежать необходимости проведения update (оттянуть саму процедуру аптейда и перевести ее на этап при котором открыты для редактирования будет меньшее количество объектов), загружать упрощенное представление объектов CATIA v5 для тех моделей, которые не будут подвергаться редактированию в текущей сессии.

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

Для того, чтобы избежать перекрестные ссылки или для разбиения сборки высших уровней на большие части, или для того, чтобы избежать проблемы совместимости разных CAD, или для описания мест стыковки сборочных комплексов, или для описания мест стыковки связанных с ограничениями системы координат CATIA v5 -интерфейсные модели.

Главное назначение интерфейсных моделей - использовать файловую систему как замок, предотвращающий update.


Для формирования упрощенного представления сборок для вставки в сборки верхнего уровня применяют габаритные модели (методология снизу - вверх)

Ну, скажем так: была assembly в Enovia, ее оттуда выгрузили, построили дерево связей, потом взяли и это дерево начали загружать в SMARTEAM. Поскольку в Enovia имеем Exposed Assemblies, то какие-то objects нужно строить самим. Поэтому, довольно-таки в лоб, идем снизу вверх, и по уровням загружаем детей. Потом, как доходим до Exposed Assembly (а их может быть много), начинаем ее строить, просто загружая этих детей в цикле с помощью функции Product.Position.SetComponent().

Каждый "ребенок" добавляется напрямую из файла - AddComponentFromFile.

Как я уже, кажется, писал, испольуем C# .NET, никаких CAA, берем все то, что CATIA позволяет, в особенности: knowledgeware и productstructure.

Вот... К критике готов.

Цитата:
Ну, скажем так: была assembly в Enovia, ее оттуда выгрузили, построили дерево связей, потом взяли и это дерево начали загружать в SMARTEAM. Поскольку в Enovia имеем Exposed Assemblies, то какие-то objects нужно строить самим. Поэтому, довольно-таки в лоб, идем снизу вверх, и по уровням загружаем детей. Потом, как доходим до Exposed Assembly (а их может быть много), начинаем ее строить, просто загружая этих детей в цикле с помощью функции Product.Position.SetComponent().

Каждый "ребенок" добавляется напрямую из файла - AddComponentFromFile.

Как я уже, кажется, писал, испольуем C# .NET, никаких CAA, берем все то, что CATIA позволяет, в особенности: knowledgeware и productstructure.

Вот... К критике готов.

Все хорошо, но ведь SmarTeam не работает с инстансами CatPart объектов...

А ENOVIA LCA четко различает связку Instance-Reference-File. Более того, в ENOVIA для каждого Instance объекта есть своя карточка атрибутов.

Информация об объекте Instance просто теряется? А ведь это огромный кусок модели данных ENOVIA, который имеет механизм редактирования на основе права владения, Инстансы релизятся, в них вносят инженерные изменения и т.д.

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

Ну, скажем так: была assembly в Enovia, ее оттуда выгрузили, построили дерево связей, потом взяли и это дерево начали загружать в SMARTEAM. Поскольку в Enovia имеем Exposed Assemblies, то какие-то objects нужно строить самим. Поэтому, довольно-таки в лоб, идем снизу вверх, и по уровням загружаем детей. Потом, как доходим до Exposed Assembly (а их может быть много), начинаем ее строить, просто загружая этих детей в цикле с помощью функции Product.Position.SetComponent().

Честно говоря не очень понятно.

Если речь идет о структурных сборках - то о какой assembly в Enovia идет речь?

Assembly подразумевает наличие связи "входимость" между объектом CatAssy и CatPart. Информация о входимости - иерархия изделия в виде сборок и подсборок отражает технологическую последователь изготовления или монтажа, особенности применения оснастки или технологических процессов...

В системе PDM все объекты сохраняются как объекты CatAssy и CatPart с наличием связи "входимость".
В некоторых кастомизациях в SmarTeam есть дерево проекта - в котором эта иерархия входимости отражена...



Если речь идет о структурных сборках - то иерархия изделия, описываемая связями "входимость" отсутствует. Все изделия описывается только объектами CatPart.

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

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


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

Но информацию о последовательности сборки и технологии изготовления теряется. Поэтому и придумали использовать вспомогательные модели CatPart – которые бы хранили информацию о входимости, этакие псевдосборки.

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


При конвертации данных в идеале необходимо эту информацию из псевдосборок CatPart как-то перенести во вновь созданные объекты CatAssy.
Фактически это значит перенос информации из модуля FT&A в другой модуль (не помню как точно называется, что вроде этого: Product Tolerancing and annotation)

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

А при конвертации надо сделать из этих несколько объектов псевдо сборок один объектов CatAssy.

Если речь идет о структурных сборках - то о какой assembly в Enovia идет речь?

Видимо речь шла о комбинированном подходе?

Ну, скажем так: была assembly в Enovia, ее оттуда выгрузили, построили дерево связей, потом взяли и это дерево начали загружать в SMARTEAM. Поскольку в Enovia имеем Exposed Assemblies, то какие-то objects нужно строить самим. Поэтому, довольно-таки в лоб, идем снизу вверх, и по уровням загружаем детей. Потом, как доходим до Exposed Assembly (а их может быть много), начинаем ее строить, просто загружая этих детей в цикле с помощью функции Product.Position.SetComponent().

Каждый "ребенок" добавляется напрямую из файла - AddComponentFromFile.

Как я уже, кажется, писал, испольуем C# .NET, никаких CAA, берем все то, что CATIA позволяет, в особенности: knowledgeware и productstructure.

Вот... К критике готов.

При этой методологии необходимо как-то конвертировать информацию о конфигурациях изделия...

, как доходим до Exposed Assembly (а их может быть много),

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

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

Да и самое главное...

Если просто начать строить иерархию изделия в виде сборок и подсборок, конвертируя данные снизу-вверх, то, к сожалению, никакое железо не выдержит.

Слабое звено не только рабочая станция, но и пропускная способность сети на участке от рабочей станции к серверу SmarTeam, сам сервер SmarTeam и т.д.


Просто взять и конвертировать одно представление в другое - это плохое решение...

Как вариант - можно создавать габаритные модели. После того, как создана традиционная сборка - есть объект CatAssy на основе структурной сборки, необходимо создать новый объект CatPart, который и будет габаритной моделью для этой сборки, скопировать все объекты CatPart из этой сборки и вставить во вновь созданный объект CatPart, сохранив ассоциативную связь.

Когда возникнет необходимость строить сборку более высокого уровня, куда как подсборка должна была входить исходная сборка необходимо вместо объекта CatAssy сборки вставлять CatPart объект габаритной модели.

Опять возникает вопрос в конвертации информации об оформлении модели средствами модулей FT&A для объектов CatAssy и CatPart. Необходимо конвертировать данные из одного модуля в другой...

Видимо есть смысл конвертировать всю информацию из структурных сборок сразу в габаритные модели и тогда информацию из модуля FT&A править не придется...

И еще не очень понятно.

О какой технологии вообще идет речь?
О бумажной или о безбумажной?

Идей много.

Например, использовать габаритные сборки при построении иерархии изделия.
Можно также использовать Relation design - этот подход, к сожалению, исключает использование SmarTeam.

Если цифровой макет изделия хранился в ENOVIA и использовались структурные сборки...

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

Значит во Flowchat SmarTeam должна собираться информация о целом пакете объектов и этот пакет должен релизиться одновременно как единое целое...