Family table headings of varied items from inheritance

[akelly]

TL/DR: If you make a family table of dimensions varied from an inheritance feature, the column headings are funky - how to rename?

Follow me a bit ... Thought I had a brilliant idea.  We have two parts that are kind of similar.  Both of them have family tables.  Not similar enough that I want to throw everything into a single .prt with one big family table. But 90% of what's there is common.  So why not use inheritance to share the common geometries??

So I picked part "A" as the master part.  "A" has a family table.  Created a new "B" part by inheriting "A".  Added Varied items to the inheritance feature so I could suppress "A"'s features not needed in "B" and have some "B" dimensions different from "A".  So far, so good.

"B"'s new dimensions also need to be tabulated, so I added the dimensions to "B"'s family table.

Family table column headings make no sense.  In the inheritance feature's varied items, the dimension name shows as "P" (same as I renamed in "A"), but in the family table, it shows up as "IN_D_298:FID_2441 D298[2441]". Expected result: column heading in the family table editor would display "T1", "T2", "S", "R", "P", "W" like they do in varied items. See pictures.

If I drill into the the inheritance feature and edit dimensions, the dimension names show up as "T1", "T2", "S", "R", "P", "W".  So I can't change the column headings (dimension names) the "normal" way.

Work around is to create parameters in "B" with the right names, then use relations to change the varied items.  I might need to keep the silly column names to actually get the instances to regenerate with the right dimension values.  Surely there's an easier way.

[BenLoosli]

How often will the common features/parameters/dimensions change? If they are mostly static, copy the family table to the other and you eliminate the funky names.

Those funky names do not surprise me as your B part is using the inheritance features, not real features and that funky name is the internal name link to your A part.

[Pettersson]

How about using a comment row to indicate the "true" name of the dimensions? Ideally, you'd want it at the top, but Creo annoyingly doesn't allow a comment row above the generic (which is where I've wanted my comment row 100% of the time I've used the functionality). But you could place one just below the generic and write the real names of the columns.

[BK_9915470]

We have the same issue. I think, the suggested workarounds are known. But nevertheless there must be a reason, why this topic is opened. Sure, we all could use the workarounds, but maybe we do not want to? We all know, what PTC likes: New and fancy features. Boring 2d-drawings are neglected, because it's not sexy enough.

I can't believe, that this requested feature is impossible to program. And if so, PTC could at least explain it.

[sacquarone]

Hello @akelly and @BK_9915470 

The impossibility to rename headers of Family Table columns is a current limitation of Creo Parametric, effective whatever the version used. The headers are always supposed to show the identifiers, and they are populated in an hardcoded way (not drivable by any config.pro option).

Considering above limitation, I can nevertheless try to provide some guidance to gather in the Varied Items table to "good and relevant information" which can be observed later in the column(s headers od the family tables.

=> This can be done essentially thanks to Assoc.Param column, and helpful also the owner column.

I recorded a movie with sound attached to this post to propose guidance in this direction.

Note: I'm perfectly aware that this is not a "perfect solution", but it's nevertheless the only guidance coming into my mind to help you improving ergonomy of our tools to give an answer (probably useful, but far from being perfect) to this business need.

Hope this will help you anyway.

Regards,

Serge

[akelly]

Thanks for the video.  Unfortunately, the weird column headings don't provide mistake-proofing to the user that's maintaining the family table.  And the column headings aren't usable in a 2D repeat region in a drawing (e.g. to make a PDF / print of the tabulation).

[sacquarone]

Hell @akelly 

Regarding "the weird column headings don't provide mistake-proofing to the user that's maintaining the family table", we suggest you to open a case to PTC technical Support with following observation:

In Family Table editor, selection of a column + > Edit >Highlight on Screen:

• is effective in the scope of feature dimensions (ex: d4 in Soruce Part))
• but has unexpectedly no effect when column calls a dimension coming from a feature being part of an inheritance feature (ex:  IN_D_298:FID_2441 D298[2441] in Target part hosting the inheritance feature)

If a case will be reported, and consequently a fix will be prodivded as part of a SPR fixing process, this capability will hopefully help users to mantain such family tables in the future.

Regarding "And the column headings aren't usable in a 2D repeat region in a drawing (e.g. to make a PDF / print of the tabulation)", using simple repeat regions instead of a unique doible one may help, because in this scope (singl repeat regions), the header can be written lmanually and mantianed accordingly in the future.

For further guidance in the way how using multiple single repeat regions to display family table information, refer to article 352288. Or also, probably even better, please take some time to view and listen to the movie attached at the end of article 24968. It explains how to create the repeat regions for Family Table in the 2 different ways (double Repeat Region, or multiple single repeat regions with filters).

Regards,

Serge