cancel
Showing results for 
Search instead for 
Did you mean: 

RoutingPartLibrary node missing table in NX 9 but UF_EPLIB_part_lib_view_node_t::table valid in NX 6

Valued Contributor
Valued Contributor

In brief:

NX 9 is not finding a table definition in a certain node in a RoutingPartLibrary, but NX 6 is.

However, I'm not sure whether the "table definition" type in NXOpen C++ is functionally equivalent to UF_EPLIB_part_table_t, so maybe I'm barking up the wrong tree.

 

In detail:

The following logic works in NX 6:

 

1) get a UF_EPLIB_part_library_view_t* named "plv":

 

UF_ROUTE_application_view_t* apv = UF_ROUTE_ask_current_app_view();

UF_EPLIB_part_library_view_t* plv;

UF_ROUTE_ask_app_view_plib_view(apv, &plv);

 

2) recursively search the tree of plv->top for a UF_EPLIB_part_lib_view_node_t* "node" such that node->identifier matches a given string.

3) Do a bunch of stuff with the UF_EPLIB_part_table_t* at node->table (after verifying that node->table is not NULL).

 

I am now porting this to NX 9. I've been informed by a Siemens rep that UF_ROUTE_ask_app_view_plib_view is "obsolete" in NX 9, and indeed this method sets "plv" to NULL when I call it. So I am reimplementing my logic using the NX Open C++ API. My code does this:

 

auto plv = NXOpen::

Session::GetSession()->Preferences()->RoutingApplicationView()->PartPreferences()->PartLibrary();

auto tableDef = plv->GetTableDefinition(name);

 

(where "name" is the same string used in NX 6 to find the "node". As far as I know, all the data and inputs are the same, although perhaps someone can tell me whether the following behavior indicates this assumption is incorrect.)

 

This is failing (GetTableDefinition is throwing). I find that plv->GetNodeType(name) returns NXOpen:: Preferences::RoutingPartLibrary::NodeTypeNormal , but GetTableDefinition requires NodeTypeTable . So NX 6 is finding a table here, but NX 9 is not.

 

However, I'm not sure whether the "table definition" type in NXOpen C++ is functionally equivalent to UF_EPLIB_part_table_t, so maybe I'm barking up the wrong tree. What I need to do is the equivalent of iterating over the data array at UF_EPLIB_part_table_t::data , but I don't see anything that looks like "data" in the "table definition" structure returned by RoutingPartLibrary::GetTableDefinition.

2 REPLIES

Re: RoutingPartLibrary node missing table in NX 9 but UF_EPLIB_part_lib_view_node_t::table valid in

Valued Contributor
Valued Contributor
I called GTAC, and was told that there is a bug in Routing in NX 9, and that the engineer I spoke to "would not be surprised" if it was causing other things like this. My PR on that other bug has a small description right now, but once it is fixed it may have some additional info -- number is 7223454 .

Re: RoutingPartLibrary node missing table in NX 9 but UF_EPLIB_part_lib_view_node_t::table valid in

Valued Contributor
Valued Contributor

Spoke with GTAC again, and found out the following:

 

1) There was a config error on my end -- my environment variables were still pointing to the NX 6 part table files, and the file names and formats are different in NX 9.

 

2) There is a bug in RoutingPartLibrary->GetChildren(NXString) wherein, if a client calls this method upon the name of a node that is not of type NodeTypeNormal, the internal state of NX gets corrupted. (The documentation on this method was missing a notice about this constraint.) Manifestations of this include access violations when calling GetPartDefinition, or subsequent calls to GetChildren throwing spurious exceptions with messages about the given node name not being found. (I'm not sure if this was also causing my failure in GetTableDefinition, because I fixed both this problem and problem 1 at the same time.)

 

PR:722427

 

https://webtac.industrysoftware.automation.siemens.com/qtac/index.php5?goto=q&call_id=7224274

 

https://solutions.industrysoftware.automation.siemens.com/view.php?sort=desc&p=1&q=GetChildrenNodes&...