Community Tip - Did you know you can set a signature that will be added to all your posts? Set it here! X
Just move to Creo 4.0 from WF5.0
The assembly being worked on is regenerated (Ctrl-G) and the message bar displays "Automatic regeneration of the parts has been completed." (Sometime I regenerated multiple time to really make sure it is regenerated.)
When the part is being saved, the following error is displayed:
Any thoughts on this dilemma of regenerated or not?
Is there a way to find out what is causing the error during the save? I tried clicking on the error message, but is doesn't have a link. Is there some other files, link, .... to tell me (and the software) what the issue is?
The first thing I'd check for is a circular reference error. If there, find the *.crc file on disk and examine it for what's causing the error. Typically it's an order of operations thing and reordering features or components will fix it.
If that's not it, I'd start narrowing the scope by dragging the insert bar halfway up the tree, regenerating and trying to save. If it saves without the error, your problem is in the second half of the tree, if not it's in the first half. Either way, you move the insert bar to either suppress half or resume half of the problem components. Once you narrow it down to a single component, you may have to open it and do the same there.
I had a situation like this recently. It came down to relations driving a pattern on a single part. The pattern was a curve feature where there was parameter driven text in the curve and the value of the parameter changed based on the pattern instance. Essentially the relations meant that the parameter value was never right since it changed at every regeneration. I set the features to read only and that fixed it.
I dragged the insert bar up & down per the recommendation on this post:
and still have not been able to locate the error. There are no .crc files in the folder. Would something in mass properties cause this issue? (Grabbing at straws here.)
There were (2) holes in the part that the dowels go into. The first dowel was assembled into the part. The second dowel was reference patterned to the 2nd hole.Deleting the pattern removed the error?
Why?
Now it gets really weird. I added the reference pattern back, and there is no error.
Why?
... and to continue on...
That same dowel was used in other spot, but I didn't have to delete and redo that pattern. It worked after the first now worked.
do-do-do-do..... do-do-do-do (to the theme of the Twilight Zone).
So with everything in the assembly suppressed it still throws the error??? Are you using Pro/Program in the assembly?
Moved the insert again. Now it is happening after a dowel insert from a family table of dowels.
Open the dowel. The family table has been verified. Regenerated with now errors.
Tried the assembly just after the dowel and still get the error.
So, insert bar above the dowel it saves without error and insert bar after the dowel it throws the error, correct?
Does the dowel by itself regenerate and save without error?
Any parent child relationships in the assy between this dowel and other parts, aside from placement refs?
Is this the only assy containing this dowel with this problem?
The relations you listed will require a double regen to save without error unless they are in the post regeneration relations area.
It is our standard dowel family table used in many assemblies. We just switched over Tuesday, so I am not sure if this is throwing an error in other parts (I will have to investigate that).
The dowel by itself (verified family table) regenerates and saves without issue.
The dowel was only placed into the assembly, nothing else driving length, diameter, .... except the family table for the dowel.
This thread got me thinking about constraints on cylindrical parts (no more insert but using either coincident or centered):
If I changed the constraint from Coincident to Centered, could that have cause the Pattern to go whack on me?
Do you have a relation that drives a weight parameter in this part? Something like weight=&pro_mp_mass
I remember some time back that when this relation was present, parts would tend to throw errors like this if they were locked (as in PDMLink locked in the workspace).
/*creates MASS and VOLUME using MASS_PROP_1 feature
MASS=MASS:FID_MASS_PROP_1
VOLUME=VOLUME:FID_MASS_PROP_1
(In most but not all parts/assemblies)
@Dale_Rosema wrote:
/*creates MASS and VOLUME using MASS_PROP_1 feature
MASS=MASS:FID_MASS_PROP_1
VOLUME=VOLUME:FID_MASS_PROP_1
(In most but not all parts/assemblies)
I have seen regen issues with things like that. Have fixed in the past with statements like this; tests values before updating them, so file isn't needlessly marked as changed every time relations are evaluated:
if MASS!=MASS:FID_MASS_PROP_1 MASS=MASS:FID_MASS_PROP_1 endif if VOLUME!=VOLUME:FID_MASS_PROP_1 VOLUME=VOLUME:FID_MASS_PROP_1 endif