Regenerated or Not Regenerated.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Regenerated or Not Regenerated.....
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?
- Labels:
-
General
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Now it gets really weird. I added the reference pattern back, and there is no error.
Why?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
... 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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
So with everything in the assembly suppressed it still throws the error??? Are you using Pro/Program in the assembly?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
/*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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
@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
