cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Allow a repeat region to be fixed when using a cparam in the table/relation

Allow a repeat region to be fixed when using a cparam in the table/relation

Starting Creo 3 M130 and Creo 4 M020, PTC is not allowing repeat region drawing tables that use cparam within the table or it's relation to have a row fixed. According to them, any previous allowance was just an oversight as cparam is not a decent identifier for their repeat region code. We use cparam to help include bulk items in a bom table. For instance, the  unit will says OZ and the QTY will say 9. The cparam is the value of a parameter which is unique within a given assembly. In this case, the bulk item parameter UNIT can be different in each assembly it is in. The table then reads that info.

6-14-2017 3-26-25 PM.jpg

We would like PTC to allow for the usage of cparam and allow the table to be fixed. If anyone has any good ideas how we can work bulk items in the table without cparam, until this is implemented, I am very interested.

4 Comments
Regular Member

My apologies for having disallowed it.  The trouble is that repeat region records getting fix index or the like need stable identifiers (so we can continue to fix the index of 'that record' when updating the tables) and records driven by cparam don't have that capability (as you can see in previous builds if the cparam is used directly in the table).  I can at least give you a vote, and ... hmm ...

1) I presume you've already considered making a pair of bulk items CHXX-1 and CHXX-1_DROPS, and having the variant unit in a parameter?  (and possibly a 'bom_model_name' param by which CHXX-1_DROPS can say that it wants to be called out as CHXX-1 in the region)  That could work OK if there are only a couple of units for any particular item.

2) If you only had one flavor of unit for any particular bulk item (in a given assembly, it would either by present with drops or by oz, say), then you could give the value in ounces, or /1000 if in drops, and use a relation to figure out which one it is, and report it accordingly.  That wouldn't be able to make the table shown above -- to decide that these two uses of the same bulk item are separate is the core of the issue.

Alexandrite

Matthew, where would the value be stored if we only use drops? Say we use 30 drops. Where would the 30 value be stored if it can be 30 for one case and 7 in another?

Regular Member

(Taking the conversation part to messages, as a Product Idea's comments is not well-suited to conversation)

Gravel

You also should consider allowing Flat/Rec Item in combination with asm.mbr.cparam!

 

We are currently moving our BOMs from the drawing to Windchill.  But some departments still need equivalent informations on drawings. There the functionality of Flat/Rec Item an Assmebly is absolutly necessary.