ACCEPTED SOLUTION
Accepted Solutions
James,
Yes the whole replace routine would be a very long and confusing video.
I hope a series of snapshots will describe this confusing process.
Below is the starting model.
Which gets fitted in the below part model.
The quandary develops when I have to retain the naming of the base model; otherwise I can't replace out the needed model. (Nothing will show up in the replacement box)
See below.
Below is the blocker models inserted into the gutter model.
Below shows gutter models inserted in the die.
Notice that there still is an issue of matching up part model names.
These pictures illustrate the progression of the tedious name changing as explained in my original post.
Hopefully this shows the unnecessary struggle that needs to be followed in order to carry new changes through our dies.
Even more hopefully there is a way around this, or it might be changed in a future Creo release.
Make it easier to replace out imported merge/inheritance models
Hello Paul,
As you already know, It's not possible to replace the model in Merge/Ineritance feature, other than with a family table instance, which is pretty odd.
I suggest building the structure such that you don't have to replace the model inside the Merge/Inheritance feature. It'd be easier if you could redefine a Copy feature made of All Solid Surfaces inside a dummy model that is then being inherited or merged into the die. This copy feature can handle getting geometry from different model each time, it can serve as a middle man. Well, if you are ok with getting only the geometry from the reference models, and not all the features, including datum axes, etc.
If you've got everything in session the renaming should work without any problem, even in your case without when you have models linked with merge/inheritance features. So, I still don't see renaming as a problem there, anyway.
When working in assembly, under Model tab --> Component dropdown --> there is Component Operations command, which lets you use Merge/Inheritance in the context of an assembly, if you choose the Merge option in Menu Manager that pops up. All this takes is to read the Message Log carefully.
That can help you do all of your work on assembly level, so you don't have to open each part separately.
The solution isn't very elegant, but should work as long as everything is in one assembly. I can try to explain it using some examples if you want me to. Btw, have you got Flexible Modeling Extension?
James: I watched your video and I think I understand what you were doing. It is interesting to see how some one else would do things in Creo; you used different selections that I haven't even tried yet. Not that this has any bearing on the ultimate result I see that you used Copy Geom with Assembly instead of External. Perhaps you just wanted to build the structure completely in Assembly instead of having outlying part model files.
I've been doing a lot of experimentation with Copy Geom with some of the new jobs I've been working on.
As far as methodology with Copy Geom is concerned, you still end up with disconnects downstream if you were to change the name of the model file that gets inserted into another model (due to a revision) and if in Session Management you "erase not displayed". (That would replicate more of the real world change conditions as you likely would have the upstream model already completed already out of the session prior to a real world change.) (Of course you could do all of your downstream changes without dropping the session you were working on, but this is a harder to pull off so I'm going to assume Copy Geom can't parametrically flow downstream with an upstream name change.) The following is the message that you get when you work through the downstream change and the upstream file name was changed.
I've seen that this fails parametrically after an upstream name change.
STILL: I am finding that I prefer the work flow using Copy Geom in die models using part model files for the top and bottom dies, and an assembly model file with top and bottom assembled in position. This to me is preferable in our situation to directly using Pro-Mold. I see several advantages here even without the clear-cut parametrics downstream.
1) Less model files are generated and are in need of change. (There is no work-piece file, there are no files for the internal reference models. Typically 7 less models!)
2) There are less gymnastics required to prepare the models for use in the dies. (You don't have to butcher the reference models inside the Pro-Mold file for end shape)
3) There are less transition nightmares where the die will not split into 2 pieces
4) The work is easier to see
5) Changes are easier to make inside the die without consequences to the opposite die
6) There is an actual option to use undo if you've made a mistake
7) Curves that are copy geom into the die actually don't disappear in the die.
😎 Assembly is a much better interface to work with than the strangely pieced together Pro-Mold
etc...
In short I am thinking this will help me work much faster with less possible mistakes by missing something when tying everything together in the name changing gymnastics.
For some users the Pro-Mold interface would work perfectly fine, but in our application it was a big miss and it had us looking at Solidworks or other CAD software just to do the die work. Yes; we won't fully utilize the Pro-Mold package, but Copy Geom appears to be a suitable alternative.
Ok, I see. 7 less models sounds reasonable.
7 more models sounds more like a life of a butcherer. 
On most of the points I agree with you on Pro/Mold or as they call it Tool Design Option (TDO). It's still way too canned, and gives too little freedom. I mean not all molds are for thermoplastic parts, right? That's why i don't use this module either.
If you or your users do this process often. Think about introducing a host of well described mapkeys that have a lot of pauses with comments that guide the user through the whole process. Alot of what you describe can propably be automated, at least partly, and if you decide to go on the route of a butcherer alot can be automated there as well.
You can even put the mapkeys to the ribbon, if you don't prefer remembering key sequences.
