Reference pattern quirk

[lfox]

Creo 2.0, Windchill 10.0

I have a flange with an 8-bolt pattern. The flange is part of a family table. The generic has only four holes (pattern quantity is a family table column). I constrain a nut/bolt to a hole on the 8-hole flange, do a reference pattern, and everything works fine. I get 8 nuts/bolts.

I save all work, check in the assembly, remove everything from workspace. I then pull the assembly back into my workspace, and open it up. The patterns referencing the 8-hole pattern now only have 4 nuts/bolts. It still follows the holes correctly, but only goes half way around. It can only be fixed in each affected assembly by checking it out (every time) and editing the definition of one of the bad patterns - no changes needed, just edit definition and confirm and it goes back to 8 nuts/bolts. Any other bad patterns referencing the flange in that assembly then self-correct.

This is not acceptable because if one needs to update a drawing and does not see the bad pattern (no reason to suspect it), the hardware totals turn out incorrect in the bill of materials on the drawing.

My only guess is that it is somehow referencing the original (4-hole) pattern quantity on the generic. But why?

I know I could probably make it work by creating each different hole pattern as a different feature, and just include/exclude features in the family table, but this is the way it was set up and I'd rather not ruin thousands of constraints in various other assemblies if it can be avoided. This is a recently manifested issue and I cannot figure out why.

Pictures attached for clarity. Any guidance would be appreciated.

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.

[dgschaefer]

Does the assy have a family table too?  I would assume that you'd have a family table driven part and a family table driven assy.  I would create the generic assy with the generic part and reference pattern the hardware.  I'd then create the family table of the assy, substituting the generic flange part for the appropriate instances.  I'd then expect the hardware quantity to update accordingly in each (but, frankly, not be surprised if it failed).

Is that what you're doing? 

Regardless, a stand alone assy with an instance of the flange & ref. patterned hardware should work reliably too.

[lfox]

Doug - Thanks for the reply. This assembly is not part of a family table. It is a large piping assembly with dozens of components. The picture I sent is just of one of the ends. We put the hardware in last on piping because different length bolts are required in different places depending on the components being attached. The lap flanges are part of a family table for convenience, just as nuts or bolts would be.

I agree fully with your last statement, which is why I'm so confused and frustrated with this problem.

[TomD.inPDX]

Your version of Creo 2 matters.  I have M040 and reported many pattering issues.  Many were reported to be fixed in later releases but posts were still popping up with issues for a long time after.  Reference patterns were a particular problem where an axis rotation pattern would work wonders.  PTC has a deep code problem regarding patterns from what I can tell.

I'm still waiting for Brian to tell us what Creo version NASA has decided to settle on.

[lfox]

Thank you for your reply. The version we have is M160. And yes, I agree that there are deep rooted problems with patterns in Creo. Trying to put patterns in groups creates a lot of problems, for example. This makes no sense, but it is not particularly debilitating. I stick to directional and axis patterns as much as possible, but that would not be anywhere near efficient with flange bolting.

[dschenken]

Just an outside chance, but this is what I think would happen if the table for the flange wasn't verified before saving. Creo tries to economize on regeneration and may be skipping areas that it expects to already be regened as part of verification. Perhaps in the past this check wasn't skipped, so it appeared to be OK, but someone cleaned up the code and fixed that bug and produced a different one.

Or maybe it's just a bug that is fixed in a different software release.

[dgschaefer]

I'd report it to PTC.  This should work, period.

[lfox]

I just might do that. Thanks for your input.