Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
I am using Creo Parametric - Release 4.0 (connected) 4.0 M140
I have an assembly with two parts (X & Y) part X is used in a family table. Part Y is assembled to X using datum planes in part X that are set to rotate 180° in part X's family table members. The planes and model Y rotate 180° correctly in the assembly but the cutout created in the assembly of X & Y is not rotated in the family member (changes to part Y appear in the cutout but the defined rotation does not happen). This worked very well in previous versions and works in 4.0 IF the cutout was created in an older version. If the cutout is recreated in 4.0 it does not work.
Added zip file with model example of 4.0 behavior.
Solved! Go to Solution.
I have found the resolution to this issue. There is an option within the family table UI to switch external refs to instances. This results in the merge/cut out updating based on the assembly instance as desired.
This results in the following reference graph from the GRV where the cutout is now driven by the assembly instance as desired.
The cutout in the assembly instance.
Have not figured out the root cause yet but there are some indications that the models are not reflecting your design intent. I have not seen any circular reference warnings or .crc files being written which is good.
But...
Creo 4 M150.
Warning message presented at the command line:
•Warning: Part X_INST has reference to generic assembly XY.
This message suggests that the reference to the generic instance of the assembly is why the cut out is not rotating. It appears that the cut out is regenerating using the position of component Y in the generic instance of XY.asm. This is consistent with the state of the models when regenerated but not your design intent. It should reference instance XY_INST.asm to locate the coutout accurately.
Glyph in model tree indicating something, It is similar to failed regen but not an exact match. This is the part with the merge/cutout so it is suspicious. Does anyone know what this X superscript glyph indicates?
The suspicious looking glyph is not a glyph. It is the grater than/less than symbols placed around an instance name. I don't think it is displayed correctly in this case. I renamed the generic model from "X" to "name" and then it becomes clear as seen below.
This is the reference viewer graph (Creo 4 M150) of the merge/cut out feature in the XY_INST.asm. As you can see Creo is showing that the cutout is driven by the generic XY.asm hence the position is not updating. The cutout would have to be driven by the assembly xy instance that has the rotated part Y.prt. The models reflect what is documented by this graph. Can you check the reference graph in Creo 4 of a model set that was created in an earlier version (3-) and compare it to see of the references are different than shown here?
I have found the resolution to this issue. There is an option within the family table UI to switch external refs to instances. This results in the merge/cut out updating based on the assembly instance as desired.
This results in the following reference graph from the GRV where the cutout is now driven by the assembly instance as desired.
The cutout in the assembly instance.
Thank you tbraxton!!!
I have several "master" models, assemblies and drawings that were initially built with ProE 11 (year 1994)?? or there abouts and have been utilized, updated, modified thru most of the iterations since then including Wildfire 1, 2, 3, 4 and Creo 1, 2, 3 and now working in 4. Many of the features have been recreated in one or more of the newer versions without issue. This is one of the few times things to not work nearly as well (as expected to work). This method of cutting out a part using another is a feature that is always present in these "masters" but recently increased complexity of the part used to make the cut has caused the cutout to fail. Remaking the cut in the current version (Creo 4) seems to solve the failure but lead to this failure to rotate the cutout in the instances. Again, thank you so much for the assist!!!
If you can get me an example of one that is not working, I will review it. I of course need to understand the design intent that is not regenerating correctly to help investigate.
I do not see a new model attached to your latest post.
It does not regenerate correctly in Creo 4 M150. I did note that the structure of these models is not identical to the test case you initially posted.
Have you verified that this set of models behaves correctly when retrieved and regenerated in Creo 3 or earlier? I suspect that it may not based on what I am seeing but you should confirm that. It is possible that this is a bug. The first test for that will be to confirm that these models regen correctly in an earlier release of Creo or Pro/E.
The constraints of this model set are not identical to the Creo 4 test case you posted earlier. This may or may not be relevant but introduces additional variables. The clocking angle for Y is controlled by a relation in the generic assembly is only one if the differences I noted. There is also Pro/Program involved in the regen, I don't think it is an issue in this context but does convolute the debugging.
Your parts use matched absolute accuracy (this is good) but the assembly is relative accuracy at the default value. I have seen mismatched accuracy cause problems with external refs features such as merge/cut out. The cut out feature is completed in the assembly the way the models sit now.
When I regenerate this assembly family table with the external ref options active there are several warnings shown when regenerating the instance X1INST.asm. The most relevant in this context is that X1INST.prt has a reference to the generic assembly X1. As long as this is the case it is not going to follow the behavior in your earlier test case.
tbraxton
The attached model is made by stripping down the current master. Setting all accuracies to absolute .00015 and keeping the cutout made using older version that rotates as needed (lower part/cutout). A new cutout has been added using Creo 4.0 that does not rotate as it should (upper part/cutout), this new part/cutout uses the same assembly planes to control rotation. Something odd about the new cutout, the part used to make it when rotated in the instance has a visibility issue of the lug in the isometric view, I do not know why. The lug appears fine in the lower (older version) part when rotated
I have reviewed and tweaked a few things on this latest set of models. It is not working as it should, I strongly suspect that it is a bug. You should open a case with PTC support, Creo 4 is not officially supported at this time, but force them to address this as core functionality requires that legacy models regenerate correctly in newer releases. You can try it in Creo 7 or 8 and if it still fails then that will strengthen the severity of an SPR if one is filed.
There are workarounds but they will require effort on your part to restructure the models.
Hi @MT_WashPA , I don't know how things worked at your company before, but I strongly recommend that your X parts should have the "ref. model" column in their family table. Otherwise, how would Creo know what context to use when regenerating the cut-outs? Anyway, the UI shortcut function pointed out by @tbraxton (switch external references to instances) does not seem to work to "fix" your x1 and x2 parts in the .7z files provided in this thread.
However, using this procedure does make your test drawings look correct (x2_PTC_HELP.7z data used in the example):
1) activate the X2 component in your assembly X2.ASM
2) edit the family table of this component
3) add the "Reference model" column, and specify the X2.ASM as the model
4) specify the correct context for other instances of X2 - for example:
5) accept the changes to the table, regenerate the drawing:
Hi pausob,
Adding the reference model column helps the situation but requires the models to be manually regenerated when drawing is retrieved for the rotation to take effect. Looks like now an "auto regen" function needs to be added for family table instances upon drawing retrieval. I have not seen that option available. Do you know how to accomplish this? I am doing some more searching now for this now.
Thanks for the assist
MT_WashPA
Hi, pausob
Pretty sure I have found the solution.
1) Adding the reference model column per your suggestion solved the non-rotation of cutout created in Creo 4.0
2) Making the assembly family table control the 180° rotation vs. having the assembly relations reference a value from the part instance removed the need to regenerate the drawing/models after drawing retrieval.
Thanks for your assistance.
MT_WashPA
I'm glad you found a working solution. To be honest, figuring out the structure of these models gave me a bit of a headache at first - what is driving what? 😁
I suppose it's always a bit of a detective work to examine other people's models so I do not know whether controlling the component's angle directly in the assembly family table is the way to go. Seems you now have to manage columns in 2 tables. Anyway, maybe doesn't matter much - these parts and assemblies are very intertwined; However, I do wonder if the regeneration is necessary if you verify all the family table instances (assembly and the X part) before saving them and then saving the drawing. That seems to work on my system and the saved drawing (x2.drw) is retrieved without regenerating anything...
(it does take 2 regenerations for everything on the drawing to update if I change the angle d1357 in the family table of x2.prt)
Hi, pausob
Thank you so much for your assistance!!
Fortunately the rotation of the Y2 part will always be 0° or 180°. I looked at using the rotation angle from the planes in assembly to control the part's planes, but the assembly generic and instance have different session id's and I do not know a method to use the same relation but with different session id's in relations. LOL, this may have been all or part of the problem from the get go. The assembly relations used the rotation angle from the part, BUT IT WORKED if the cutout was made in older versions. Oh well, this will fix those issues and should improve function (ie. reduce failure rate of cutout when the Y2 part becomes complicated).
below are the screenshots missing in the previous reply.
*added -a to both the generic and the instance name*
*the assemblies generic name updates in the parts family table but the
instance's name does not.*
below are the screenshots missing in the previous reply.
*added -a to both the generic and the instance name*
*the assemblies generic name updates in the parts family table but the
instance's name does not.*
Yep... not unexpected; though it would be nice if the system would do this renaming for you for family tables of in-session objects.
It's just one of those things one has to consider when using family tables...
I can see how this was a lot simpler with the older cut-out features which do not seem to need the extra column in family table and also regenerate right away after an assembly change.
Hello @MT_WashPA
Even though post is now closed, I took some time to look at it this morning.
The first Cut Out id 32114 of X2.PRT:
=> There was therefore no reason to produce an outcome depending on the way (placement constraints) how Y2.PRT was assembled in the generic assembly
=> This cutout should therefore have produced the same geometry in all instances of the given generic assembly (taking definition ONLY from Y2.PRT, and not on the way how Y2.PRT is assembled in the context of X2.ASM)
The second Cut Out id 225192 of this same part X2.PRT
Additional info: Related to that, if the second Cut Out Feature is redefined, and then switched to External as follows:
=> Dependency in Reference Viewer lists then ONLY Y2.PRT (and not X2.ASM anymore, like the old Cut Out Feature)
=> But this information is now correct, which means that the cut out, in the "external definition context" is now really completely independent from placement constraint & Orientation of Y2.PRT (not what you want in this context, but "Reference Viewer" information is now reliable and correct)
Therefore, in short:
Refer also to those examples here confirming this approach as recommended to be in supported conditions (there is no material for a SPR on the new Cut Out Features behaving now as expected. The old Cut Out features, even though were proposing a solution you were happy with, were nevertheless not consistent nor reliable in term of dependency information in Reference Viewer)
AN evidence tha old cut out feature was incorrect (whereas new one is correct now) can be demonstrated as follows (shown in Old_versus_New_Cut_Out_Feature.mp4 attached movie):
Now if my understanding of your last post is correct, you're looking for a way to avoid:
If my understanding is correct, you may want to drive this with good relations and correlated Pro/PROGRAM definition.
=> Way to do this is hlighted in second attached movie named Alternate_Technique_Without_Assembly_Family_Table.mp4
=> Outcome of this movie was backed up, and uploaded in the third attachment
Hope this helps to have a good understanding of the background, and to propose a solution which may fulfill your business needs without requiring usage of Assembly Family Tables.
Regards,
Serge