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?
&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.
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!!
"rel_model_name()", That's an interesting parameter. Where did you find it Brian? Thanks!
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.
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
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.
Here is a pic.
Thanks for your willingness to help, greatly appreciated!
These are already renamed.... but I can assume your start part calls those fikrst 3 datums "Side", "Top" and "Front", correct?
That is correct
From your screenshot it looks like you're using Wildfire 3, is that correct... or is this 4?
SORRY FORGOT WF4
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.
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:
Here's how it works:
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!
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.
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.
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.
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.