Сборочная единица, JT на геометрию в истории построения этой СЕ и "потеря отслеживаемости" JT

[NeedMoreLODs 81]

Teamcenter 9.

NX8.5.

Флажок сохранения JT установлен (через настройки по умолчанию).

 

Ситуация примерно следующая.

Cоздали сборку, набросали пару компонент, в истории построения сборки сделали box, сохранили сборку.

Появляется JT на сборку.

Удаляем box.

Снова сохраняем сборку.

JT на сборку не удаляется, остаётся на месте (хотя геометрии box'а то уже нет).

Для проверки удаляем эту JT вручную.

Снова сохраняем сборку (напомню, на этот момент box'а уже нет).

И JT не создаётся.

Получается, что после первого сохранения актуальность JT не отслеживается, NX и Teamcenter просто "забывают" про неё.

 

Для конструктора, работающего со сборкой, это может выглядеть так.

1. Создал сборку, поработал с ней какое-то время, несколько раз сохранил (причём на момент одного из промежуточных сохранений в истории построения была обычная геометрия, которую затем удалили или объединили с геометрией переноса (в этом случае геометрия сборки уйдёт в геометрию контекстной JT того компонента, с которого делали перенос тела), а затем снова сохранили сборку).

2. Как итог - получаем в ревизии Item'а какую-то левую JT, которая вроде бы и связана с ревизией и c UGMASTER экземплярами ImanRelation(IMAN_Rendering), но в то же время к текущей ситуации никакого отношения не имеет. На эту JT очень легко вообще не обратить внимания, особенно если история построения сложная (состоит из кучи переносов или деформаций). А если даже и обратить внимание, то сделать вывод о её актуальности может быть  достаточно непросто, т.к. для этого надо анализировать историю построения СЕ.

 

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

Особенно весело будет коллеге, который в дальнейшем будет разрабатывать ЭТД или работать в визуализаторе с такими сборками.

 

То, что JT не удаляется, это нормально, так и должно быть?

Или это какой-то баг?

Или может дело в каких-нибудь настройках?

И вообще кто тут виноват - NX, Teamcenter или настройки (читай - кривые руки)?

[Krusty 194]

JT генерируется в случае наличия геометрии, если геометрия изменеятся то и перегенерируется JT - всегда актуален

Если на уровне башки сборки (узла) нет геометрических построений, то и JT небудет, если из головы сборки вы выкините геометрическое построение, то JT не удалится

В вашей методике работы вы имеете построения на уровне сборки?

Изменено 7 апреля 2016 пользователем Krusty

[NeedMoreLODs 81]

Сейчас перечитал, я очень сумбурно изложил.

Я проверил, на самом деле дело не в сборке, в обычных Item'ах то же самое.

 

1. Создаём в Teamcenter в приложении "Мой Teamcenter" самый обычный Item с произвольный item id и наименованием.

2. Открываем Item в NX.

3. В Моделировании создаём сферу.

4. В NX жамкаем "Сохранить".

5. Проверяем, что JT набор данных создался (можно этот шаг пропустить).

6. В Моделировании удаляем сферу (таким образом история построения детали теперь пустая).

7. Снова жамкаем "Сохранить".

8. В NX закрываем всё, затем закрываем сам NX (для чистоты эксперимента, чтобы не сбивал с толку блокировками и т.д.).

9. В "Мой Teamcenter" смотрим итоговую ревизию Item'а и набор данных JT в ней. Видим, что JT набор мало того, что на месте, так и содержит геометрию. Странно.

10. На всякий случай снова открываем набор данных NX, ну мало ли. Нет, история построения пустая. Но JT при этом есть и не пустая.

11. На всякий случай смотрим именованные ссылки для набора данных JT. Нет, ссылки на месте.

[NeedMoreLODs 81]

Или другой вариант, уже со сборкой.

 

1. Создаём произвольный Item.

2. Открываем его в NX.

3. В этом Item'е добавляем компонент.

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

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

4. После добавления компонента в истории построения сборки создаём куб.

А на конус компонента делаем операцию "перенос тела".

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

5. В этот момент сохраняем сборку в NX.

Создаётся две JT - одна обычная, содержащая в себе куб, и скрепляется эта JT, как обычно, с ItemRevision и с набором данных NX через IMAN_Rendering.

И создаётся вторая JT на перенос, контекстная, содержащая в себе конус, которая напрямую с ревизией не связывается, а связывается с ней косвенно - через экземпляр AbsOccData (там дальше длинная цепочка с разветвлением к PSBomViewRevision и MEAppearancePathRoot, но не суть.) и т.д.

Такую вторую JT в приложении "Мой Teamcenter" видно не будет (по крайней мере при стандартных настройках, про остальные случаи ничего сказать не могу).

Но её можно будет увидеть, например, во "Вложениях" в Менеджере структуры.

6. В истории построении сборки делаем объединение двух тел, т.е. обычного куба и конуса, полученного переносом.

7. Сохраняем в NX сборку.

Общая геометрия объединения при этом уйдёт в контекстную JT.

Но в тоже время останется и обычная JT на сборку, в которой будет куб.

А в контекстной JT будет общее тело, состоящее из куба и конуса.

В визуализаторе при работе с такой сборкой уже получаем наползание тел.

 

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

 

Никакие настройки в меню NX, влияющие на JT, я не менял, кроме опции сохранения.

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

Может кто сталкивался с подобным и может как-то прокомментировать?

 

P.S.: Или ещё, как гипотетический вариант. Конструктор может работать со сборкой. И в какой-то момент использовал линковку, для того чтобы скопировать геометрию одного из компонент для, например, дальнейшей обработки в сборке (например надо отверстия в фланцах просверлить). Сохранил сборку в NX. Потом передумал, удалил линковку, и вместо линкования сделал перенос. Но уже поздно, JT на сборку есть и никуда не делась и конструктор об это может и не подозревать, он то работает с общей картиной в NX, а там всё корректно, а до визуализатора ему может и  дела нет, он в нём не работает, по крайней мере на данном этапе.

 

P.S.: Возможно надо пояснить, что для "обычной" геометрии истории построения сборки (например для линковки или для геометрии наподобие куба и прочих фичеров) создаётся JT на сборку, а для операций переноса тела или деформации компонента создаются контекстные JT, которые связываются контекстно в структуре сборки с самими компонентами.

Изменено 8 апреля 2016 пользователем Ленивый

[uGRAF.exe 7]

JT генерируется в случае наличия геометрии, если геометрия изменеятся то и перегенерируется JT - всегда актуален Если на уровне башки сборки (узла) нет геометрических построений, то и JT небудет

 

 

Ежели в tessUG.config написать:

mergeSheets = false
mergeSolids = false
mergeAll = false

То JT будет генерироваться (и перегенироваться) просто по факту сохранения, никаких твердых тел ей не будет нужно.

[Krusty 194]

 

 

Ежели в tessUG.config написать:

mergeSheets = false
mergeSolids = false
mergeAll = false

То JT будет генерироваться (и перегенироваться) просто по факту сохранения, никаких твердых тел ей не будет нужно.

 

 

будет пустышка, просто пространство?

[NeedMoreLODs 81]

Насколько я вижу tessUG.config это "текстовое" отображение обычных в NX "Настойки->JT...".

И если источники данных для mergeSheets и mergeSolid я в GUI вижу (см. приложенный скриншот), то вот что в графическом интерфейсе отвечает за mergeAll?

 

mergeSheets и mergeSolids у меня в false установлены.

mergeAll просто нет как параметра.

 

mergeAll может как-то повлиять?

Завтра попробую вручную прописать, может окажет какое-то влияние.

 

P.S.: В идеале хотелось бы, что бы JT при отсутствии геометрии в NX либо исчезала, либо хотя бы становилась пустой. Ситуация вообще не очень хорошая, потому как такие случаи могут встречаться довольно часто.

Изменено 20 апреля 2016 пользователем Ленивый

[uGRAF.exe 7]

будет пустышка, просто пространство?

 

Ну да. Просто пространство. Если будет PMI в воздухе (например буква), то пространство с PMI.

 

 

 

mergeAll может как-то повлиять? Завтра попробую вручную прописать, может окажет какое-то влияние.

Совсем забыл, еще нужно установить переменную среды UGII_GENERATE_MULTI_CAD_JT=1 

 

 

Изменено 20 апреля 2016 пользователем uGRAF.exe

[ra99 2]

переменную среды UGII_GENERATE_MULTI_CAD_JT=1

для какой версии актуально? в NX10 явно не наблюдаю   

[uGRAF.exe 7]

ля какой версии актуально? в NX10 явно не наблюдаю   

 

Для любой. Введите её руками.  

[NeedMoreLODs 81]

Совсем забыл, еще нужно установить переменную среды UGII_GENERATE_MULTI_CAD_JT=1 

 

 

Сделал как Вы сказали.

И поэкспериментировал немного.

 

Странно что для того, чтобы установка переменной имела эффект - надо перезапустить Teamcenter (без перезапуска эффекта не было).

То есть переменная не только связана c NX но и с Teamcenter.

Или тут модуль интеграции NX и Teamcenter вмешивается.

Ну или я что-то не так делал.

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

 

А так да - после установки этой переменной JT остаётся, но "пространство" её становится пустым.

И размер JT с 26 килобайт меняется на 1.5 килобайта.

 

Сделал пару/тройку циклов - установил переменную - перезапустил tce (и NX) - убрал переменную - перезапустил tce (и NX).

Эффект повторяется, т.е. в случае удаления переменной JT снова перестаёт отслеживаться.

 

"mergeAll = false" устанавливать не стал, переменная "сработала" и без этого.

 

Я так понимаю Вы с этим вопросом про JT уже сталкивались, и, возможно, не раз. 

Может поясните, как переменная влияет на данный случай, а то похоже на косвенное влияние? 

Изменено 21 апреля 2016 пользователем Ленивый

[lexx174 373]

Странно что для того, чтобы установка переменной имела эффект - надо перезапустить Teamcenter (без перезапуска эффекта не было).

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

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

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

Изменено 21 апреля 2016 пользователем lexx174

[NeedMoreLODs 81]

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

 

 

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

Вообще с виндой работать приходилось несколько лет назад на системном уровне.

Да и когда всех учили Паскалю, я изучал ассемблер по Рудакову/Финегенову под 386/486.

И простейшие драйверы (ещё под XP) писать приходилось (да-да-да, я знаю что такое IRQL_NOT_LESS_OR_EQUAL и почему именно оно возникает).

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

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

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

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

Но это пока.

Сегодня выходит новая LTSка Убунты, которая наконец то на моём железе будет работать стабильно (не дружит линукс с некоторыми ATIшными картами, хотя это скорее вина ATI).

Вот и bash изучу заодно.

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

 

Я то пытался спросить про то, почему эта переменная для Teamcenter, в то время как её название говорит о том, что она скорее для UG.

И почему именно она влияет на JT таким образом в конкретной ситуации.

Грубо говоря - если вы это внимательнее прочитаете,  то поймёте.

То что вы написали - я и так прекрасно понимаю.

Но всё равно спасибо за пояснение.

 

P.S.: А с другой стороны - в своё время много нервов было потрачено, прежде чем в документации была найдена переменная UGII_UGMGR_ALLOW_PFM_IMPORT_EXPORT. Так что названия не удивляют. Но тут то хотя бы UGMGR упоминается.

Изменено 21 апреля 2016 пользователем Ленивый

[Krusty 194]

Ленивый,

при запуске Rich Client, он всасывает переменные из Windows, NX стартуемый из под Rich Client всасывает переменные проинициализированные сессией Rich Client-а

данная переменная не имеет прямой связи с Teamcenter, точнее вообще не имеет.

[NeedMoreLODs 81]

при запуске Rich Client, он всасывает переменные из Windows, NX стартуемый из под Rich Client всасывает переменные проинициализированные сессией Rich Client-а

 

Спасибо большое, картинка сложилась! 

[NeedMoreLODs 81]

Кстати, давно хотел предупредить, но чего-то забыл.

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

 

Установка

UGII_GENERATE_MULTI_CAD_JT=1

приведёт к генерации вместо многофайловых многослойных JT к генерации однофайловых многослойных JT.

 

Если у вас на предприятии используется многослойка "старого" варианта, то имейте это ввиду.

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

А если используется дефолтная однослойка, то, вроде бы, без разницы.

Изменено 28 июля 2016 пользователем Ленивый