Mechanism and Family Tables

[bobmann]

Okay, here's something that makes no sense to me. I have an assembly which contains two instances. To simplify, the assembly has one part on a hinge (Part B) that rotates with respect to another part (Part A). There are two sizes of Part B, and thus the Family Table for the assembly has one instance that includes one size of Part B, and the other includes the other size of Part B. No problems so far.


Then I created a Mechanism in order to create some snapshots, showing the assembly in various hinge states (fully open, fully closed, partially open, etc). Still no problems. But now, as soon as I go back to Standard and re-verify the Family Table, both instances Fail. I tried to redefine things in various ways, but they always Failed.


Finally I checked PTC.com for help, and I found a TPI that says the following:
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">


Description
<DIV =indent10>


Current Pro/ENGINEER Assembly functionality allows users to create an assembly family table where one of the variable columns is the instance of the part assembled. If this part is assembled using Mechanism connections, then assembly instances that do not use the generic part will fail regeneration and will fail when attempting to verify them.</DIV>


Resolution
<DIV =indent10>


This is the current functionality of Pro/ENGINEER. If switching part instances in a Mechanism assembly becomes necessary, assemble the generic part and all its instances using Mechanism connections in the generic assembly. Then, in the assembly family table, control which part is used by the suppress/resume options.</DIV></BLOCKQUOTE>
Okay, this really stinks. I REALLY hate adding multiple instances of the same thing to a generic. A guy I works with swears he has seen this problem before, and that there is some kind of workaround, but he can't remember what it is. Does anyone know of anything else that I can do here? Thanks...

 

[bobmann]

I should have added this info before...


I am using WF 2.0, Build M190.

 

[pjw]

bobmann - I would say to you: Ignore what the verification of the table is telling you. It is not to be trusted. We have the same problem with assembly instances whichhave cuts using silhouette edges as references. Verification can often show a failure in this scenario so our workaroundis to make a datum point on (3 surface ref type) and use this as a ref instead of the sil' edge. Even though the verification showed a failure the instance would open up fine (using the silhoutte edge method). I suspect this is similar in fashion to what you are experiencing.


If you are using data managent software and need to do a verification in order to check in your instance to the database - don't bother verifying. Instead, open up the instance and explicitly save it. It will then be recognised. Your generic will be saved at the same time (it doesn't normally matter whether you save your generic or your instance - they are one and the same file).


I'm pretty sure that this will solve your problem.


Phil

 

[pjw]

bobmann - I presume that the instance opensup fine: it just doesn't succeed on verification of the generic's family table?


Phil

 

[bobmann]

Well, the instance does open, but it does not open correctly.


Okay, here's a simplified explanation of what's happening. Continuing my example from above, PartB.prt has two instances: PartB_Inst1 and PartB_Inst2. My assembly, Assy.asm also has two instances: Assy_Inst1 and Assy_Inst2. As you can probably guess, PartB is in the Family Table, and Assy_Inst1 is directed to use PartB_Inst1, and Assy_Inst2 is to use PartB_Inst2.


When PartB is fully defined in the assembly, the Family Table verifies just fine. But when PartB is partially defined (to allow for movement in Mechanism), the Family Table instances fail. I get the message: "Failed to replace member PARTB (M3992)". If I then try to open up, say, Assy_Inst1, it opens but it does not open correctly. Instead of having PartB_Inst1, is has the generic PartB.prt. And the only change was the removal of one constraint that gave me the neccessary degree of freedom for the movement I wanted.


In other words, it seems as though the Family Table doesn't want to allow me to have component PartB partially constrained. Which seems to me to mean that I can either have a Family Table or a Mechanism, but not both...

 

[pjw]

bobmann - I set up a family table in the way that you've described and used connections to assemble a hinge arm to a bracket. Made instances of the sub-parts and called these in to an instance made in the generic assembly. Component rightly shows as 'packaged' in the model tree. Instance verifies fineand opens up as it should do.


This is on Wildfire 3 M020. It may be a version specific problem you are experiencing.


Phil





View attachment 3040

 

[CaptnPea]

Strange, In WF 2 M170


I have an family assembly that is RH & LH constrained with mechanism constraints. I have not had any problems. It goes something like this.


Assy_generic.asm has Sub-Assy_generic.asm which contains base.prt that has the refferences for installing next_sub.asm too. Then Assy_RH.asm has Sub-Assy_RH.asm with mech constraints to next_sub.asm. And Assy_LH has Sub-Assy_LH.asm, that re-locates base.prt (with standard constraints), then installs next_sub.asm.


I think I avoid your problem by having the part_base always the same (as it is used to define the joint in both assys RH and LH), it is not a component being swapped out, but, instead I am swapping out sub-assys. So this gets me thinking that if you used datum planes, points, axis, and the like that are defined in you generic andregenerate in both of your instances would this help? Or even a really stupid work around would be to create sub-assy's of your parts, then swap them out?