Связь структуры сборки в NX и Teamcenter

[NDE 3]

Предисловие: "Или я слишком глубоко копаю и не вижу ответа на поверхности, или тут что-то действительно не так".

Как организована интеграция NX и Teamcenter в части загрузки сборок и хранения информации о компонентах.

Исходные данные: NX10, Teamcenter 11.6, испоьзование SOA из поставки NX, язык C/C++.

Задача: из User Function NX читать атрибуты строк BOM и записывать их.

Как я реализовал это сейчас::

Получаю сессию, открытую NX:

            NXOpen::Session *theSession = NXOpen::Session::GetSession();
            NXOpen::PDM::PdmSession *thePdmSession = theSession->PdmSession();
            connectionHandle = thePdmSession->GetSoaConnectionHandle();
            Teamcenter::Soa::Client::Connection* tcSoaConnection = reinterpret_cast<Teamcenter::Soa::Client::Connection*>(connectionHandle->GetHandle());

Нахожу в базе ревизию сборки:

dmSrev = Teamcenter::Services::Core::DatamanagementService::getService(tcSoaConnection);
std::vector< Teamcenter::Services::Core::_2007_01::Datamanagement::GetItemFromIdInfo > query(1);
Teamcenter::Services::Core::_2007_01::Datamanagement::GetItemFromIdPref pref;
Teamcenter::Soa::Client::Model::ItemRevision *itemRevision;
Teamcenter::Soa::Client::Model::Item *item;
std::vector<  Teamcenter::Soa::Client::ModelObject * > objs(1);
query[0].itemId = object_id.GetUTF8Text();
query[0].revIds.push_back(object_rev.GetUTF8Text());
Teamcenter::Services::Core::DatamanagementService::GetItemFromIdResponse item_bom_response = dmSrev->getItemFromId(query, 1, pref);

Создаю новое окно BOMWindow:

itemRevision = item_bom_response.output[0].itemRevOutput[0].itemRevision;
item = item_bom_response.output[0].item;
bom_info[0].item = item;
bom_info[0].itemRev = itemRevision;
bom_info[0].clientId = "InfoDSERequest";
bom_info[0].bomView = nullptr;
bom_info[0].objectForConfigure = nullptr;
bom_info[0].activeAssemblyArrangement = nullptr;
bom_info[0].revRuleConfigInfo = revRuleConfigInfo;
Teamcenter::Services::Cad::StructuremanagementService *structServ = Teamcenter::Services::Cad::StructuremanagementService::getService(tcSoaConnection);
Teamcenter::Services::Cad::_2007_01::Structuremanagement::CreateBOMWindowsResponse bomWindow = structServ->createBOMWindows(bom_info);
topLine = bomWindow.output[0].bomLine;

Дальше перебираю BOMLine, ищу UG ENTITY HANDLE, совпадающие с хэндлом в NX (с отбрасыванием от хэндла версионной информации, т.е. первые 28 символов):

cur_line = dynamic_cast<Teamcenter::Soa::Client::Model::BOMLine *>(child_lines[i]);
ent_handle = cur_line->get_UG_ENTITY_HANDLE();
UF_TAG_decompose_handle	((char*)ent_handle.c_str(), &file_data, &sub_file_id, &versio);
child_file_data = file_data;
UF_free(file_data);
instance_file_data.resize(28);
child_file_data.resize(28);
if (!instance_file_data.compare(child_file_data) && instance_sub_file_id==sub_file_id) // Сравнение искомого компонента с каждой строкой BOMLine
{
	Чтение атрибутов, например, seq_no = cur_line->get_bl_occ_int_order_no();  
}

 

Считаю что это неэффективно, да и вообще неправильно.

Если посмотреть, что создаёт NX в кэше SOA с помощью

	Teamcenter::Soa::Client::ModelObjectVector all_objs;
	tcSoaConnection->getModelManager()->getObjectsFromStore(all_objs);

То мы увидим там и BOMWindow  и BOMLine и PSOccurrence и PSOccurrenceThread. Т.е. уже всё открыто и по идее надо работать именно с этими объектами. Но я, хоть убей, не могу найти связь между компонентом сборки NX и объектом TC.

Максимум, что я накопал штатными средствами:

Можно получить хэндл в БД для PendingComponents (естественно, NX Component для них ещё отсутствует). Хэндл имеет следующий вид: "wCpJ4WwyhfM7oB 0WhJ4WwyhfM7oB 2tpdxbGAhfM7oB". Это 3 UIds в Teamcenter. Первый - это UId айтема/ревизии, второй - PSBOMView, третий PSOccurrenceThread.

Не штатными средствами, если импортировать функцию UGMGR_NX_ask_db_comp_handle_uids из LIBUGMR.DLL, можно получить такой же набор UIds для любого компонента NX или только PSOccurrenceThread  с помощью UGMGR_NX_ask_occ_thread_of_instance:

HINSTANCE  lib = nullptr;
typedef int(__cdecl *INT_TAG_CHAR_PROC)(tag_t, char **);
typedef int(__cdecl *INT_TAG_CHAR3_PROC)(tag_t, char **,char ** ,char **);
INT_TAG_CHAR3_PROC UGMGR_NX_ask_db_comp_handle_uids;
INT_TAG_CHAR_PROC UGMGR_NX_ask_occ_thread_of_instance;
lib = LoadLibraryA("LIBUGMR.DLL");
UGMGR_NX_ask_db_comp_handle_uids = (INT_TAG_CHAR3_PROC)GetProcAddress(lib, "?UGMGR_NX_ask_db_comp_handle_uids@@YAHIPEAPEAD00@Z");
UGMGR_NX_ask_occ_thread_of_instance =  (INT_TAG_CHAR_PROC)GetProcAddress(lib, "?UGMGR_NX_ask_occ_thread_of_instance@@YAHIPEAPEAD@Z");

tag_t inst_tag = UF_ASSEM_ask_inst_of_part_occ(pComponent->Tag());
UGMGR_NX_ask_db_comp_handle_uids(inst_tag, &buf, &buf1, &buf2);
UGMGR_NX_ask_occ_thread_of_instance(inst_tag, &buf);

 

Эти функции написаны на C без использования ООП, поэтому мне удалось их использовать. Аналогичных функций в UGOpen я не нашёл. В принципе в LIBUGMR.DLL имеются функции для работы с BOM, но они уже на C++  с использованием классов, а лезть в это без исходной документации не лучшая идея. Да и противоречит лицензионной политике .

 

И вот собственно вопросы.

1. Как перейти от PSOccurrenceThread к PSOccurrence или BOMLine? (Для этого нужно знать, в каком BOMWindow искать).

2. Как найти нужный BOMWindow?

 

Примечания:

1. Может быть есть штатные функции получения хэндла в БД на основе instance или occurrence в NX?

2. NX создаёт BOMWindow в следующих случаях: при первом открытии сборки. отдельные BOMWindow для подсборок не создаются. Но если сначала открыть подсборку, а потом вышестоящую сборку, то в системе будет создано 2 BOMwindow.

3. NX не закрывает созданные BOMWindow до конца сессии (видимо поэтому и память потребляет как не в себя). Например, если открыть сборку, потом закрыть её и снова открыть, NX создаст 2 BOMWindow.

[IgP 124]

Ни hrena не понял ...

Задачу бы лучше с технической/материалистичной стороны описали ...
 

[NDE 3]

Собственно доработка ПО, различные утилиты DLL (User functions), написанные с помощью UGOpen. Из NX необходимо читать (и по возможности записывать) атрибуты в BOM Teamcenter.  Ограничение версии NX - 10. А он, как известно, не умеет работать с атрибутами BOM line, с типами, отличающимися от строковых.

 

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

Edited December 5, 2024 by NDE

[butulec 5]

05.12.2024 в 06:05, NDE сказал:

Собственно доработка ПО, различные утилиты DLL (User functions), написанные с помощью UGOpen. Из NX необходимо читать (и по возможности записывать) атрибуты в BOM Teamcenter.  Ограничение версии NX - 10. А он, как известно, не умеет работать с атрибутами BOM line, с типами, отличающимися от строковых.

 

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

Тоже интересовался этим вопросом 2 года назад, ответа не получил, НО знаю что это реализовано на одном из предприятий. Если узнаете как в NX получить/вывести хоть как то получится добраться до порядкового номера вхождения ТС, ПНИТЕ!!!

Edited December 6, 2024 by butulec

[esergey 74]

05.12.2024 в 06:05, NDE сказал:

Собственно доработка ПО, различные утилиты DLL (User functions), написанные с помощью UGOpen. Из NX необходимо читать (и по возможности записывать) атрибуты в BOM Teamcenter. 

 

точно не могу вспомнить , но вроде NX поддерживает написание макросов , vb или vba  - не помню конкретно , но с помощью макроса можно вызвать код в какой нибудь написанной для этого dll или отдельной программулины , для извлечения данных напрямую из БД ТС с помощью ODBC
если нужный вам параметр есть в базе данных - вы его получите или сможете добавить или изменить 

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

Если у вас в ТС используется MS SQL  - то примеров на learn microsoft описание ODBS -  куча 
Да, сложновато работать с этой ODBS, но описание всех методов есть на обучалке микрософта ... 

Да и дрова ODBS уже установлены в винде , нужно их только использовать ...

 

Edited December 7, 2024 by esergey
добавил текст про утилиты

[esergey 74]

вспомнил  -  Qt 563 я собирал и там есть живые примеры написания длл или екзе с использованием доступа к MS SQL с помощью ODBC
если нужны исходник Qt и как собирать - тоже где то у меня есть , и не только 563 и более поздние 5 версии , помоему до 5 12 , которая позволяет собирать Qt без имени пользователя и пароля зарегенного у них на сайте пользователя ...

Функции для работы с данными

Edited December 7, 2024 by esergey

[NDE 3]

Цитата

точно не могу вспомнить , но вроде NX поддерживает написание макросов , vb или vba  - не помню конкретно , но с помощью макроса можно вызвать код в какой нибудь написанной для этого dll или отдельной программулины , для извлечения данных напрямую из БД ТС с помощью ODBC
если нужный вам параметр есть в базе данных - вы его получите или сможете добавить или изменить 

Лезть напрямую в БД не является хорошим тоном. Все атрибуты читаются и пишутся штатными средствами SOA. Проблема именно в установлении соответствия runtime объектов SOA (BOMWindow и BOMLine), загруженных в NX с компонентами NX. Для чтения атрибутов, я могу создать новое окно BOMWindow, установить необходимую сборку в качестве TopLine, и идентифицировать компоненты со строками BOM через UG_ENTITY_HANDLE.  Но если я попытаюсь перезаписать атрибуты и сохранить BOMWindow  - произойдёт переопределение атрибутов. Я не знаю как на это отреагирует NX, скорее всего выдаст ошибку при сохранении сборки, что структура имеет более позднее сохранение и не даст её сохранить. Пока не пробовал, надо провести эксперимент . Но, если есть объекты, с которыми уже работает NX, по хорошему надо менять именно их.

[lexx174 375]

а в чем проблема прочитать соответствующим TC SOA API свойство BOMLine? Или я не понял верно вопрос?

Выглядит вышеописанное непонятным до конца 

 

Если надо работать в обе стороны с TC BOM - для этого есть TC SOA API и возможность использовать это из NX OPEN API, что вы и делали выше.

 

Может разберем для начала какой-то частный простой пример, что нужно прочитать/записать?

Edited January 14 by lexx174

[NDE 3]

Проблем читать/писать свойства объектов - нет. Проблема в идентификации. В сессии NX уже загружена сборка с компонентами. Соответственно созданы Runtime объекты BOMLine. Как определить, какой BOMLine соответствует конкретному компоненту. Дело в том, что если создавать новый BOMWindow, то его придётся сохранять после записи, это приведёт к тому что будет невозможно сохранить сборку. Если менять свойства в соответствующих PSOccurrence - то при сохранении сборки NX перезапишет свойства из BOMLine.

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