Search causing incomplete regeneration?

[KenFarley]

I have a large assembly I am working on that consists of parts and sub-assemblies that are distributed within a number of sub-directories. Whenever I work on this particular assembly, I have a "local" set of config.pro and search.pro files I load in, after I've loaded in my default config.pro and search.pro. The local config.pro contains one statement:

search_path_file locsrch.pro

where "locsrch.pro" is a list of directories, each a full path, to search for components. Creo is fine with finding all the different component models that are needed for the assembly, as long as they are in either my default search paths or in the "local" ones. The individual part models retrieved are all correct.

The problem I have is one of the sub-assemblies. This assembly is a family table part, and when it is regenerated during assembly retrieval, all the proper parts are there, but their locations are incorrect. They appear to be located in the positions dictated by the generic assembly. They are not correct for the particular instance being retrieved. If I "edit definition" any of the offending parts in the incorrect sub-assembly, then do nothing but hit the green "okay" button, the assembly regenerates again and all is correct.

Has anyone else seen this kind of behavior with a family table assembly? Is there something I'm doing wrong with my search technique of "appending" a local search path onto my general "default" one? Is Creo particularly bad at its sequence of regenerations?

I'm wondering if I am doing something wrong, or if I need to somehow build a case to present to the Creo developers for investigation.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[spete]

The one time I saw something like that was in a nested family table subassembly. It sounds like its just not regenerating a nested assembly at first.

In my situation, I flattened the family table to one level and the issue disappeared.

[KenFarley]

I never use nested family tables, because:

(1) They make design intent very difficult to understand. You've got instances of instances and it's not obvious to someone looking at the top level generic that those sub-instances even exist.

(2) They are a really lazy way to create specific design variations. The equivalent of the "GOTO" in programming code. A convenient solution at the moment, but lacking in forethought as to part structure.

(3) The aforementioned regeneration difficulties.

My regeneration problems in the present situation result from something which I find unavoidable. I've got a top level assembly that has different versions. The versions are defined by the replacement of key components with pertinent instances. Something like:

Version 1 Top-level Assembly -> contains Version 1 of Component A and Version 1 of Component B

Version 1 Component A -> contains Version 1 of Sub-Component (a)

Version 1 Component B -> contains Version 1 of Sub-Component (b)

...with maybe two or three further sub-levels.

It's a complicated setup, but still relatively straightforward. The correct components are included in the assemblies and sub-assemblies, it's just their positions are not correctly updated in the initial regeneration.

[dschenken]

A more correct analogy for nested family tables is creating functions instead of using in-line code.

It isn't lazy - it's compact and representative of the structure. If there are cases where a function isn't called correctly, that is a compiler or interpreter error, not laziness on the part of the programmer.

If nesting isn't working then that's probably a case the PTC developers need to fix. The concept isn't complicated and it isn't new. The model interpreter puts the current level of interpretation on hold, just like when it finds a subassembly, then evaluates the next level, and then continues with the level it paused.

The main family table implementation problem (on PTC's side) is that it has silent fail. If a feature is suppressed in the family table and another feature/component that depends on it is not specifically in the table, PTC will silently suppress that as well, leading to features and components that are missing in the model without notice and without explicitly being controlled in the family table.

The silent fail is what causes family table users the most trouble. Problems should show up when the table is verified, but it is still silent there as well. I suspect it is a response to user complaints and marketing response to those complaints that the tables failed all the time. Rather than making users responsible for ensuring models are built to represent what they explicitly called for, they made it easier to be wrong un-noticed.

In software development, it's the equivalent of calling a function that does not exist and having the compiler skip it.

I wonder if the problem with this assembly is that the family table wasn't verified before it was last saved. Not verifying also leads to a bunch of hard to explain problems. Search paths will have nothing to do with retrieval problems unless the parts that are being retrieved are not the parts the assembly was originally built with, such as from having copies of X in two different folders, with X1 having been explicitly retrieved for the initial assembly by digging through folders and X2 being found by the search path.

This is another silent fail - PTC does not (didn't use to) save the path to the parts, so is unable to tell the user a different part with the same name has been substituted. This also leads to unhappy people saying 'it worked yesterday, but not today.'