[protoolkit] получить идентификатор объекта

[mannyz 0]

Всем привет!

Я пишу плагинчик на C++ под Creo Parametric. Пользуюсь protoolkit.

Столкнулся с такой проблемой: мне надо получить уникальный идентификатор для объекта типа PART или ASSEMBLY, который будет неизменен между сессиями запуска Creo. Если я ничего не путаю, то в самой документации сказано, что можно получить такой идентификатор через ProModelitem. Но там также сказано, что этот идентификатор остается неизменным только для объектов внутри модели (те что внутри part/assembly), но не для самой модели. И так оно на самом деле получается. Но мне нужен именно идентификатор для part/assembly. Как мне такой заполучить? Подскажите, пожалуйста.

Еще у меня есть вопрос по поводу солидов. Я так понимаю, что в Creo понятия солид как в NX нет. Иными словами, есть ли у меня возможность перебрать отдельные солиды и получить для них осмысленные имена? Потому что пока я сливаю весь part как одно целое.

Есть и еще один вопросик. Пока совсем не приоритетный. Можно ли легко и безболезненно узнать является ли данный элемент/объект вставкой какого-либо прототипа? В NX это довольно просто выясняется.

Но больше всего интересует вопрос про ID для part/assembly.

Заранее спасибо!

[VIKT0R 21]

Может ProMdlIdGet ?

Вообще, несколько сумбурный вопрос.. В разных сессиях ПроЕ модели (детали или сборки) могут иметь разные Session ID, в зависимости от последовательности их загрузки в память.

А что за плагинчик, если не секрет?

[mannyz 0]

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

ProMdlIdGet не катит. Он выдает именно эти самые sessionID, которые могут меняться. В NX-е, например, тоже на поверхности валяются sessionID, но можно добраться и до acrossSessionID. Наверняка ведь как-то можно, раз для объектов, которые входят в состав part/assembly это получается. И зачем они так извратились в Creo?

[VIKT0R 21]

Не меняются между сессиями имена деталей/сборок (файлов) - можно по ним ориентироваться..

А acrossSessionID - это что такое?

[Ruslan 338]

mannyz

Действительно, странно. Хотя если до этого вы работали только в UG , то это вполне объяснимо. Так как базовая идеология и структура файлов отличается в принципе. Сходную организацию, еще имеет T-flex.

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

В ПроЕ нет многотела. Тело всегда одно, может быть только многообъемность (несколько не связанных между собой объемов).

Про прототип не совсем понятно, хотя похоже имеется в виду механизм наследования, когда в деталь втягивается другая ассоциативная (в прямом направлении). Наверняка это можно определить, но на память не скажу...

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

[VIKT0R 21]

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

(извините за небольшое отступление от темы)

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

[mannyz 0]

А acrossSessionID - это что такое?

acrossSessionID - это я так назвал id-шники объектов, которые остаются неизменными между сессиями запуска ProE.

На самом деле я натупил вчера. Чтобы добраться в сборке до подсборок или подпартов, я перебираю feature в PRO_MDL_ASSEMBLY и рассматриваю только фичи с типом PRO_FEAT_COMPONENT, которые как раз таки и представляют из себя либо part, либо assy. А ID такой фичи мне известен, и он остается неизменным между сессиями. Только этот ID-шник уникален в рамках своей родительской модели, а не в рамках top-level модели (или все модели). Поэтому чтобы получить уникальные ID в рамках всей модели, буду склеивать ID-шники всех родителей объекта через точку типа "xx.yyy.zz". Хотелось бы, конечно, чтобы ID выражался одной цифрой, но да ладно.

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

Не меняются между сессиями имена деталей/сборок (файлов) - можно по ним ориентироваться..

Да, но тут есть подводные камни. Например, я могу в сборке из двух одинаковых цилиндров (каждый из которых это PART) только в одном из них сделать дырку. По сути это уже разные PART-ы, но, если смотреть только на имя файла, они будут по-прежнему близнецами. Или цвет поменять у одного из них.

В ПроЕ нет многотела. Тело всегда одно, может быть только многообъемность (несколько не связанных между собой объемов).

Я уже нащупал это (многообъемность). Но насколько я понял, взять и узнать массу каждого объема мы не можем. Или все-таки можем?

Про прототип не совсем понятно, хотя похоже имеется в виду механизм наследования, когда в деталь втягивается другая ассоциативная (в прямом направлении). Наверняка это можно определить, но на память не скажу...

Честно сказать, я не совсем понял, что значит ассоциативная деталь. Дело в том, что я совсем не работаю в ProE. Но могу пояснить, что такое прототип.

Здесь все просто. Мы создали файл с PART-ом в виде цилиндра. Потом создали сборку, в которую поместили два или три экземпляра цилиндра из предыдущего файла. Таким образом, у нас есть файл с цилиндром - это прототип, и файл со сборкой, в которой есть вхождения (или можно назвать ссылки) этого прототипа. В NX-е в этом смысле все просто.

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

[Ruslan 338]

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

Обработка в сборке? У каждого компонента сборки есть идентификатор элемента, уникальный для этой сборки. Однако если имена совпадают, то при открытии модели, геометрия будет одна и таже. То есть отдельно с дыркой и без дырки одну и туже модель иметь нельзя.

Я уже нащупал это (многообъемность). Но насколько я понял, взять и узнать массу каждого объема мы не можем. Или все-таки можем?

Через API маловероятно... В ПроЕ не принято моделировать несколько деталей внутри модели детали, так как нет инструментария. Сборка происходит только в модели сборки (другой файл с другим расширением.

В NX-е в этом смысле все просто

Просто с вашей точки зрения, С нашей же слишком мудрено.

Деталь, есть деталь. Ее можно вставлять в сборку столько раз сколько нужно. Но изменения в детали отразятся везде, на всех компонентах. Если в сборке вам нужны три похожие детали, то нужно создавать исполнения детали (естественно у них будут свои уникальные имена).

Есть еще такое понятие, как шаблон (заготовка), но думаю это не ваш случай...

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

[Ruslan 338]

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

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

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

И при прямой передачи, есть требования по версиям обоих продуктов...

п.к. В справке ПроЕ по ATB, конечно не много информации, но думаю для настройки хватит (About ATB-enabled Unigraphics)...

[mannyz 0]

Еще раз здравствуйте!

Хотел задать еще пару вопросов, но на неделе не срослось.

Обработка в сборке? У каждого компонента сборки есть идентификатор элемента, уникальный для этой сборки. Однако если имена совпадают, то при открытии модели, геометрия будет одна и таже. То есть отдельно с дыркой и без дырки одну и туже модель иметь нельзя.

Может быть, я не правильно выразился, но я имел в виду то, что изображено на приложенном мною рисунке. Есть две вставки сборки SLIDER_CRANK.ASM. Исходно SLIDER_CRANK.ASM представляет из себя некий кривошипный механизм и прилепленный сбоку цилиндр (этот цилиндр входит в состав одной из .PRT-деталей). Далее в самой сборке я делаю дырку в одном из вставленном SLIDER_CRANK.ASM. Далее у другого SLIDER_CRANK.ASM я меняю цвет цилиндра на красный (на самом деле можно поменять цвет не всего тела, а выборочно по граням). Вот, что я понимаю под обработкой в сборке. И это не фотошоп )).

В связи с этим у меня и были вопросы по поводу ссылок, шаблонов, прототипов. В NX-е мы можем различить две подобные ситуации: жесткое изменение с проделыванием дырки - тогда мы уже не можем ссылаться на исходную SLIDER_CRANK.ASM как на прототип и использовать какие-либо ее свойства. Например, фасетную модель или массу; и легкое изменение цвета - фасетная модель таже, но цвет другой.

Есть еще такое понятие, как шаблон (заготовка), но думаю это не ваш случай...

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

Скажите, вот этот механизм наследования похож на то, что имеется в NX? И этот механизм доступен только для файлов типа PRT?

И еще у меня есть куча связанных вопросов.

Function ProPartTessellate

Description

Returns a tessellation (also called a triangulation) of each surface of the specified part. For parts, acts on all surfaces. For assemblies, acts only on surfaces of the assembly, not components.

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

Кажется, все что хотел, спросил. С нетерпением жду ответов, комментариев и т.п.

Всем удачных выходных! Следующих ))

[GOLF_stream 293]

получить фасетную модель для PRT-файла

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

в .ASM-сборках мы можем помимо вставки компонентов создавать какие-либо тела, как если бы это был .PRT файл.

НЕТ Вывод неправильный. В сборке можно создавать сборочные операции, но это или поверхности или ВЫРЕЗЫ (или опорные элементы). Никаких твёрдых тел в самой сборке создавать нельзя. Потому что любое твёрдое тело - это какая-то деталь, и "просто так" в сборке оно существовать не может. Соответственно нужно сделать файл детали и в нём творить твёрдое тело.

Крайне неверно подходить к работе в ПроЕ с представлениями о работе в NX. Это РАЗАНЫЕ системы, у них РАЗНЫЕ методы и зачатую РАЗНАЯ идеология.

[Ruslan 338]

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

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

По умолчанию в дереве сборки элементы не отображаются...

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

И этот механизм доступен только для файлов типа PRT?

Да, только детали, для сборок как бы смысла нет.

И если мы все-таки можем рисовать цилиндры на уровне сборки, то можем ли мы получить их массу отдельно от массы вставленных компонентов?

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

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