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

Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X

Naming features using &model_name

GregMerz
1-Newbie

Naming features using &model_name

Guru's

We want to name the default datums starting with the model name (i.e."modelname"_top, "modelname"_cycs_def).

Is there a way to use the system parameter, "&model_name" to do this?

Thanks

17 REPLIES 17
Patriot_1776
22-Sapphire II
(To:GregMerz)

&model_name is a parameter used in dwgs, I haven't found a way to use it in a model. Also, the feature name seems like it cannot contain the "&" anyways.

Hi Greg...

There's almost always a way to do something in Pro/E... the problem is determining whether or not your SHOULD. Frank's right, there's certainly no easy way.

In the model you can use rel_model_name() to have the system return the name of the current model. For example, you can set a relation that says:

current_name = rel_model_name()

That relation will set the name of the current model to the variable "current_name". But this isn't what you asked.

You can ALMOST do what you're trying to do with a mapkey. The problem occurs when you try to use a variable while renaming your datums. The system doesn't want to let you input a variable for the new name. It actively resists this. This means you have to build the name of the datum plane WITHOUT entering a variable name.

How in the world do you do this? You'd need to create a small trail file and re-run it using a mapkey. Most people use trail files in an attempt to recover lost work after a crash. This is virtually useless except for a few rare cases. However, trail files are great if you want to run a whole slew of commands at once and you don't (or can't) build them all into a mapkey.

Start Pro/E completely fresh. (Restart from a blank session). Start a brand new file (from a start part). Immediately edit the datum names. Input anything you want for the names... ie "test_front", "test_side", "test_top", etc. When you're done, save the file and exit Pro/E. Now go find the trail file created from that simple session you just ran. Open the file and look carefully for the lines where the names of the datums are added. Check specifically for "test_front", "test_side", and "test_top". These THREE lines are the important ones.

Also... there's a line in there somewhere when you NAMED your new file. That line will contain your model name. So now you have all information you need.

Here's the rub. You have a perfectly good file... all you need to do is substitute a new model name a few places and you'd be golden. BUT... you want to use this file over and over using a different model name each time. The easiest way to do this is with some type of script. It can be DOS, some kind of shell, or my favorite- PERL. If you have the patience to learn a quick bit of Perl, you can write a 10 line script which will replace the model name into the appropriate lines in your trail file.

In practice, you'd start a new part or assembly, give it a name... and then hit a button or mapkey. The mapkey would fire off the PERL script. The script would take your trail file and edit in the appropriate new model name and save it. Once the script executes, control goes back to the mapkey... which then opens the trail file and executes it.

All of this should happen in a fraction of a second... and all your datums would be renamed. Voila!

If you want me to help you create this system, I'd be happy to do it. I can help you with the scripting too if that would help. It's not EASY... but it is possible. You just have to have a little MacGyver in you!

Have a great holiday!!

-Brian

"rel_model_name()", That's an interesting parameter. Where did you find it Brian? Thanks!

Hi Frank...

I'm not sure where I first saw it... probably from one of the old PTC Fundamentals books (back when they used to produce actual soft-cover books). I honestly can't recall... but it works!

We use a relation in our start part that sets a variable to the current model name. The relation says:

part_number = rel_model_name()

Then in our drawing BOM, we use &asm.mbr.part_number in the "Part Number" column. If our model is called "foobar" then part_number is set to "foobar" and that's what shows up in the drawing BOM. The benefit comes in if we need to override the current model name. Let's say we have an oddball part number with spaces... or two users have modeled different versions of the part. In those cases, we delete the relation. This abandons the part_number parameter and turns it into a manually editable parameter. We can add spaces to the parameter if we wish. Also, we can have several different models that all show the same part number in the BOM field using this override technique.

There are other ways to achieve this kind of override... but that's the way we've done it.

Best regards,

-Brian

Brian,

Thanks for the reply and great explanation! I understand what you are talking about but I don’t know anything about writing scripts. If you are willing, I would like to take you up on your offer to help. Not sure it is worth all the work but, sounds like fun just to see it work plus I might learn something.

Let me know and Thanks again

Hi Greg...

I'd be happy to help. Hopefully I haven't missed anything that will complicate the issue but I feel pretty confident we can knock this out in a few hours. Do you have a start part you could post? That way I'll have your actual model to work with and I'll know the correct names of your default datums, etc. If not, maybe a screen shot of the model tree for a new part would be enough.

Also... what version of Wildfire are you using? I'm hoping you're still somewhere between 2 and 5. I haven't tried any scripting with Creo 1.0 yet... and frankly I'm dragging my feet. I don't want to jump into Creo 1.0 too much until its been used and tested by the community for several more builds.

We'll get started as soon as I have your feedback.

Thanks!

-Brian

Brian,

Here is a pic.

Thanks for your willingness to help, greatly appreciated!

Untitled.jpg

Hi Greg....

These are already renamed.... but I can assume your start part calls those fikrst 3 datums "Side", "Top" and "Front", correct?

That is correct

Hi Greg...

From your screenshot it looks like you're using Wildfire 3, is that correct... or is this 4?

Thanks!

-Brian

SORRY FORGOT WF4

Hi Greg...

I successfully created the trail file needed to perform the rename. I'll work on the PERL scripting portions this evening. We'll be ready for a test later tonight or perhaps tomorrow. I have to work on this off hours due for obvious reasons but I'm confident I'm on the right track.

Thanks!

-Brian

Hi Greg...

We've hit PAYDIRT. One mapkey renames everything in less than 1 second.

There are several preparations which must be made before the process will work. I have done almost all of these for you:

  • Open a new blank start part and rename the 3 default datums and coordinate system by hand. Exit Pro/ENGINEER and find the trail file from that session. Edit out everything but the portions of the trail file that actually rename the datums. Save this file as something easy to remember. I called it "rename_template.txt"
  • Install PERL on your system. If I'm not mistaken, PERL is actually included with every Pro/ENGINEER installation down inside the loadpoint in the <loadpoint>/mech/perl folder. However, I'm not sure if you can access it and run PERL scripts just because you have Pro/E. It's been awhile since I had an employer who would not let me install PERL on my system. Your best bet is to install PERL from the link here: www.perl.org It's free and very safe.
  • Download the zip file attached to this message. It will contain the perl script tree_parser.pl and the other files necessary for the process to work. Unpack the zip file into your starting directory (whatever your "Current Directory" is set to when you first log into Pro/E).
    • If you have security concerns or cannot download the files as a ZIP, I can send them as individual files OR I can copy/paste the text of the files here. You can re-create them on your end to alleviate any potential security issues. Some employers are strict about this but we can work around it easily.

Here's how it works:

  • First, we create a mapkey which saves the current model tree out to a file. The file is always called "treetool.txt" by default. The file is always written in your current working directory (not your workspace per se but your "Working Directory"). If you're working within Pro/INTRALINK or Windchill, you usually don't mess with your working directory which is a good thing. If you are always setting and resetting your current working directory, we'll have to make some simple modifications to the mapkeys.
  • Second, we create a mapkey to run the perl script
  • Third, we create a mapkey to run the trail file which renames the default datum planes and coordinate systems
  • Finally, we create a mapkey to run all of the first 3 mapkeys in sequence (thus bringing the whole process down to one mapkey)
  • Alternately we can create an icon for the Pro/E menus which will execute the mapkey bringing the whole process down to one mapkey. I didn't do this but it's simple enough.

Creating the mapkeys is a bit tricky. I've pre-created them and I'm attaching them to this message. We'll need to EDIT them before they will work for you. I've left some blank spaces in the mapkeys so we can add your specific workstation pathnames. This is the only tricky bit... we have to customize the mapkeys to each users' directory structure. This isn't difficult though.

Download the files, unzip them, and then write back. I'll walk you through the rest of the process and we'll be ready to TEST!

Thanks!

-Brian

Here's a brief video (~20 secs) showing the mapkeys and script in action.

Not sure where the video goes but hopefully it attaches itself to this message.

Hi Greg...

Did you get a chance to check this out? I tried to upload a video of the script in progress but it doesn't seem to load correctly. I tried it again just now but so far no luck.

Do you still want to work on this? It's pretty much ready to run, we just need to tackle a few steps on your end to make it work. I can't do these for you because they'll be specific to your system.

Thanks!

-Brian

Sorry to get back so late. Got busy at work and have not had the time to take this any further. I still want to pursue this and will keep you posted.

Thanks again

Hi Greg...

No problem at all. I have had to take a bit of a break myself. Between work and trying to complete some screenshots and tutorials for people, I'm swamped, too.

I'll save all the work we did and we'll pick up the topic when you have time. It's useful for the entire community to understand how to develop and use simple perl scripts as a way to extend Pro/E functionality. So when we finally pick it back up, I'm sure someone will find it helpful.

Thanks!

-Brian

Announcements
Business Continuity with Creo: Learn more about it here.

Top Tags