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

Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X

Save as part parameter

CS_10428158
8-Gravel

Save as part parameter

I would like to create a parameter that stores the previous part number or name of the part that the part was saved from.  


For example if I have a part "Gear1.prt" and I save as to a new part "Gear2.prt" I want to store a parameter when doing a save-as that says "Gear1".  That way users that perform a save as automatically have a history of where this design was made from.  It can be useful when going through a parts history.   I don't want to make it a type in parameter because users would forget to add this information.

 

Does anybody have any insights into how this could be done?  

1 ACCEPTED SOLUTION

Accepted Solutions

Thought about it a bit more. I think the crux of the problem is that you need to detect and respond to a change of model name. So, you need some way to know it has changed. Thus, I'd define two parameters:

currentModel  -> A String parameter, will store the current model name

pastModel -> A String parameter, will store the previous model name

 

The "trick" is to use the relation function rel_model_name(), which provides an ALL CAPS string of the current model name, or name of the current file without the .prt, .asm, etc. The relations I'd add to the model to use the above parameters would be:

IF currentModel <> rel_model_name()
  pastModel = currentModel
ENDIF
currentModel = rel_model_name()

Thus if you copy a file to another file, via "Save As" or whatever, when you open that file, this relation will find that the file name is not what it was, and via the "IF" clause, set the past model name to what it was before, then update the current model name to the current file name.

Some possible problems with this approach:

(1) I don't know how it will work with family table parts. Parameter will probably change for every instance and not in a good way.

(2) You have to live with the relation being executed every time you regenerate your model. It's not a lot, but still...

(3) You have to put the relations and parameters in every file you want them in.

View solution in original post

5 REPLIES 5

Can't think of a method to do what you want with relations and such. It's an unecessary exercise, anyway. Creo already stores this information for you.

(1) Try copying a file to another file via a "Save As" operation.

(2) Open the copied file.

(3) Access the file history via Tools->Investigate->File History

 

You'll see the first entry in the table will be something like "The model was copied from..." and it will list the name of the file you copied from.

I use this all the time to figure out who messed up one of my models. Or what part/assembly template I started with.

Thought about it a bit more. I think the crux of the problem is that you need to detect and respond to a change of model name. So, you need some way to know it has changed. Thus, I'd define two parameters:

currentModel  -> A String parameter, will store the current model name

pastModel -> A String parameter, will store the previous model name

 

The "trick" is to use the relation function rel_model_name(), which provides an ALL CAPS string of the current model name, or name of the current file without the .prt, .asm, etc. The relations I'd add to the model to use the above parameters would be:

IF currentModel <> rel_model_name()
  pastModel = currentModel
ENDIF
currentModel = rel_model_name()

Thus if you copy a file to another file, via "Save As" or whatever, when you open that file, this relation will find that the file name is not what it was, and via the "IF" clause, set the past model name to what it was before, then update the current model name to the current file name.

Some possible problems with this approach:

(1) I don't know how it will work with family table parts. Parameter will probably change for every instance and not in a good way.

(2) You have to live with the relation being executed every time you regenerate your model. It's not a lot, but still...

(3) You have to put the relations and parameters in every file you want them in.

AndrewK
Community Manager
(To:KenFarley)

Hi @CS_10428158,


I wanted to follow up with you on your post to see if your question has been answered. If so, please mark KenFarley's reply as the Accepted Solution for the benefit of other members who may have the same question.

Of course, if you have more to share on your issue, please let the Community know.

 

Thanks!

If I were to include this parameter in every part I'm concerned this could have an impact on regeneration of large assemblies.  Would this be a problem if the parts are locked or does this only affect items that are un-regenerated?

 

I've tested this and it seems to work.

 

Is the "<>" operator the same as "!="?  Is there any difference?

Near as I can find from searching and such, <> and != are equivalent in this case.

Don't know if you'll have noticeable regeneration effects. Calculations always cost something, I don't know how many milliseconds this bit of code takes to execute.

I think regeneration only affects those parts and assemblies that need it. Biggest "hit" would be when opening up stuff for the first time in  a session, but that's always how it goes.

Top Tags