Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

games with published geometry...


games with published geometry...


We are having a bit of a discussion with the use of publish geometries
for cores/casting/machining. The discussion centers around whether the
geometry will update without the assembly it was created in, in session.

I just ran a simple test and if I create part1 with a published geometry
at the end, then create part2, and external copy geom the part1
published geometry into part2 WITHOUT an assembly, then if I open part2
from an empty session, it brings part1 into session too, and thus
updates with any changes in part1.

Now if I do this in an assembly, then open part2 from an empty session
it just gives me warnings about the assembly not present and won't let
me edit the copy geometry either...

IS there a option that would force the first behavior for
both situations? What we would like is to not loose that reference,
even if we created things in an assembly and no longer have the

thanks in advance...

Paul Korenkiewicz
FEV , Inc.
4554 Glenmeade
Auburn Hills, MI, 48326-1766

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.

Hi Paul,

For cores/castings/machining, we always use external copy geom's, even
if they all reside somewhere in the same assembly. But I'm surprised
that your part1 is brought into session when you retrieve part2. I've
never noticed this.

Regards, Hugo.

Paul & Co.,

We use inheritance features for our castings. They work quite well and they don't require the base model in session. The only time it's required is when changes are made to the base model and the changes need to be propagated. Using inheritance features also allow more than one base model to be used for creation of a part (fluid manifolds, etc) where you have initial machining on each base model and final machining on the bonded part.


Hi Rich,

The disadvantage of inheritance features compared to copy geoms, is that
models with inheritance feature are significant bigger than with cg's.
At least, as far as we tested. Our biggest casting is over 100MB for
the rough part. The derived part with inheritance is more or less the
same, the derived part with CG is 35% of the original. In case someone
can point me to an option or a procedure to avoid this growth in
modelsize, I would definitly consider to adopt inheritance as well. But
for the time being, my advice is to stick with CG's.

Regards, Hugo.

There's a config option that controls the retrieval of the reference
part in situations like this: retrieve_data_sharing_ref_parts The
default is no, but I don't know if it treats both situations the same or

A standard copy geom relies on the assy for geometry placement, so the
assy is required for complete copy geom definition. Now, a standard
assy based copy geom can be converted to an external. An interesting
test would be to create a standard copy geom, delete the assy from disk
and then try to convert it to an external. Can it be successfully
converted? If so, then you have an out if the assy gets lost.

Doug Schaefer
Doug Schaefer | Experienced Mechanical Design Engineer

I think, even if you don't OPEN the assembly in your "interesting test",
the copy geometry won't let you REDEFINE it... so you're stuck. That's
exactly the situation we find ourselves in... we have a series of
casting/core machining models with external copy geometries created in
an assembly, but the assembly is "lost"... We've decided the best way
to fix is to create NEW external copy geometry features with NO assembly
reference and then redefine the rest of the features to the new one
allowing us to delete the old one. It sounds worse than it is, because
we will only need to redefine the first couple of features. As with
most casting machinings, the first few cuts establish features that the
rest of the cuts are built from...


I don't think an external copy geom can contain assy references. I
suppose there might be a way to create one with an assy dependency, but
an external shouldn't have any refs aside from the source model.

A standard copy geom (simply 'copy geom' in the menu) requires an assy
to place the parts relative to one another. The external does so with a
coordinate system.

Are you sure that you cannot redefine a standard copy geom outside the
assy? I have in the past. The options are limited, but you can at
least set it to 'independent and I thought you can convert it to an
external as well.

Another thing to try is to create a new assy with the name of the
missing one, assemble the source and target models and then redefine the
copy geom. Pro|E should let you redefine it then. It may give you a
warning about the copy geom not being properly placed, but once you
update it, you should be good. Then you could 'externalize' it and be
rid of the assy.

Doug Schaefer
Doug Schaefer | Experienced Mechanical Design Engineer

Pauil and others

In the past Pro/E gave you a choice to make the excopygeom's to be dependant or independant. This is their very confusing way of getting rid of that pick box

Norb Gruman


I'm not sure what you are saying. The dependant/independent choice is
still there. It defines whether the copy geom, external or standard,
remains connected to the source. If set to independent, the copy geom
no longer will update with changes in the source. It's a means to
'lock' the geometry if you no longer want changes to propagate. It has
nothing to do with whether an assy is involved. With an external copy
geom, an assy should never be involved.

BTW - I did my experiment, and unfortunately if the assy is missing, you
cannot change a standard copy geom to an external.

Doug Schaefer
Doug Schaefer | Experienced Mechanical Design Engineer

Yes, Doug is right... a bit of semantics error in my email...

Paul Korenkiewicz
FEV , Inc.
4554 Glenmeade
Auburn Hills, MI, 48326-1766

Attention: Creo 7.0 Customers
Please consider upgrading
End of Life announcement here.

NEW Creo+ Topics: PTC Control Center and Creo+ Portal