Parameter Syntax - digging deeper

[SolidPerks]

I suspect like many users, we have a Weight parameter set up to reference the mass properties. I discovered a syntax issue & I want to dig a little deeper, just because... I found it by trying to copy-paste the parameter callout from the note editor in one drawing to another drawing of a different model. The callout sytax was "&WEIGHT:5[.2] LB."

I understand that "&WEIGHT" calls the mass properties, "[.2]" controls the value to 2 decimal places, " LB." is descriptive text.

I realize, now, that the ":5" is system generated and refers to the model being referenced.

My questions is how do I confirm the model reference? Is the a RMB menu or property box somewhere in the tree or user interface that will tell me the model reference number?

In the case of a mutli-model drawing, I want to control the model parameter references, for template set-up, design automation, etc. The reasons for understanding & controling this bit of syntax are many. Thanks in advance for any help.

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.

[dgschaefer]

The .5 is the session id. You can find it by going to the relations dialog and looking under the "Show" menu for the session id command. That's in WF4, they may have changed things a bit in Creo, but you should be able to find it in the relations dialog.

In a drawing, the session ID is not necessary. If it's a multi-model drawing, Creo will automatically add the session id for the current active model and will track it from then on.

Session IDs are assigned as parts & assemblies are retrieved. They are different with every session, as the name implies, and Creo / Proe seems to do a good job of tracking them from session to session.

[TomU]

I know of two ways.

1. Open an assembly. Go to "Tools", "Relations", "Show", "Session ID". Pick "Part" or "Assembly", then pick on one (part or assembly) in the model tree or on screen. The session ID will be show in the message bar.
2. Add the text in the attached file to a note in a drawing. (courtesy of Mark Heinze - PTC User list)

[SolidPerks]

OK, I understand what both of you are saying. This seems to be a type of memory management feature of Creo. If so, what purpose does it serve to the end user, other than stating an ID number? Is it used in upper-level design automation, or custom programming?

If the Session ID constantly changes, based on what is open and in what order, WHY does it show up in my text editor? It seems that unless it serves a purpose to the user, it should be 'hidden' somehow and not show-up in the UI.

Give this number some meaning... or should I just make a permanent mental note to ignore it?

Thanks for your help!! Even if I seem ungrateful, I do appreciate it, and I learned something today...

[TomU]

Fundamentally you need some way to refer to other models in notes and relations. PTC could have simply displayed the file name, but that gets confusing when multiple files have the same name but different extensions (ex. parts and assemblies). If they simply hid the session ID, you would have no idea what that specific relation/parameter/dimension actually referred to. It also is similar to the syntax used to refer to feature level information: "<parameter/dimension>:FID_<feature ID>". Normally you won't need to worry about it unless you are creating relations or notes that need to refer to a specific model other than the one currently active.

[dgschaefer]

Tom pretty much summed it up. For notes in multi model drawings or assembly drawings (or assembly relations), you need a way to pull the parameter info from a specific model. That's what this does. Could there be an easier way? Maybe, but this works.

The number kinda needs to change every session. Are you going to assign a unique number to every object that you have ever opened? What then if I open it after you, does it get the same number that you had or do I get my own set of unique numbers? If mine and yours are different, but unique and constant in our own sets, how does the software manage that?

When you start down those rabbit holes, having it different every session adn letting the software keep track of it seems like a pretty elegant solution. The user only needs to know when we need to define non-geometry (parameter) relationships between objects.

[dschenken]

PTC creates a session ID that represents an entry on list of components. Internally it has to keep the positions in each assembly or drawing, but these are probably a 32 bit number. When they point to the same items, they get the same session ID.

Example

Open A.asm ->B.prt & C1.prt;

Then open D.asm->C1.prt & ->C2.prt

C1 and C2 are the same part, assembled twice into D.

C1 in A.asm and C1 in D.asm will have the same session ID. If D.asm is opened first, the session IDs of C1 and C2 will be different because B.prt wasn't opened before them, but it will still be the same for C1 in A.asm and C1 in D.asm

The only complaint I have about session ID is that it hasn't been displayable in the model tree, and requires poking about to find it. It's still easier than the alternative of using whatever index PTC maintains in each assembly/model.

I think an excellent blog for PTC to start is "Why we created this function/feature" that describes a particular problem to be solved and the advantage to the user of solving it and why they solved it in the particular way they did. Like "Why are 32 layers not enough?" which led to the creation of the layers and rules segment of PTC parametric software. Or "Why are session IDs created?"

[TomU]

I think an excellent blog for PTC to start is "Why we created this function/feature" that describes a particular problem to be solved and the advantage to the user of solving it and why they solved it in the particular way they did.

I love this idea, but I wonder if there are even still people in the company who really know. Some of this functionality has been around since the beginning.

<off topic>

I wonder how many things are the way they are simply due to early limitations with computing power, processor architecture, perceived future needs, etc. Software tends to grow over time and very rarely will someone go back through and evaluate the why and how behind existing functionality and then try to improve on it with new, clean code. There is simply too much risk of breaking something or alienating the existing user base with altered behavior.

I've heard that the Java code that makes up Windchill is the largest Java program in the world. Not sure if it's true or not, but it makes me wonder if there is a relationship between the number of programmers and the final size (and complexity) of the software.

I came across a fascinating article the other day on the history of Pro/e. It was amazing to see how many current complaints about the software and perceptions about PTC have been around since almost the beginning.

http://www.cadhistory.net/16%20Parametric%20Technology.pdf

</off topic>

[dgschaefer]

David Schenken wrote:

Open A.asm ->B.prt & C1.prt;

Then open D.asm->C1.prt & ->C2.prt

C1 and C2 are the same part, assembled twice into D.

C1 in A.asm and C1 in D.asm will have the same session ID. If D.asm is opened first, the session IDs of C1 and C2 will be different because B.prt wasn't opened before them, but it will still be the same for C1 in A.asm and C1 in D.asm

Not true. The session IDs are assigned as parts & assemblies are opened (as far as I know, drawings do not get session IDs). A given part will have a single session ID, regardless of how many times it occurs and how many assemblies it is in. They are assigned in order as objects are brought into session (opened). Parts get even numbers, assemblies get odd. First part opened is session ID0, second is 2, third is 4, etc. First assembly is 1, second is 3, etc.

In your example above, if C1 & C2 are the same part file, they will have the same session ID, likely 2 as B would have been 0.

[SolidPerks]

Thanks for all the info guys!! I don't have specific automation plans/projects yet, but I know I will get there. I've been there in SolidWorks, and I'm sure I will advance to that level in Creo. However, since it is managed by Creo, and seems to be in a state of constant change depending on other active session files, I will probably leave this for later advanced challenges.

It's nice to know what it is, but I also try to avoid rabbit holes! I've seen too many customizations turn into nightmares, primarily because users were not able to flex with software changes, or because an organization wouldn't budge on it's 20yr old document procedure. I'm more of a 'Let's use it out of the box first...' kinda guy. I like doing cool custom things, but only if there isn't already a solution built-in that would work.

The odd/even thing is interesting. I found part ID 0, but couldn't find assembly ID 1. This will be something to explore. However, it is currently something that exists, I need to be aware of it for parameter calls, and I need NOT copy it from one call to another.

[dschenken]

I got the Feature ID and Session ID behavior mixed.

The part I got wrong is that C1 and C2 get different Session IDs; correctly**, C1 and C2 will be the same SID. The rest is true. Opening them in a different order gives them different SIDs.

C1 and C2 will get different FID***s in the A.asm, and C1 will have a different FID in D.asm

Now that's fixed better.

The reason is so that the user isn't dealing with dimensions in the notes or relations that look like:

&d1:thisisthenameofofapartorassembly.asm or &d1:thisisthenameofofapartorassembly<familytablename>.prt;

instead it will be:

&d1:0 or

&d1:1

which is less typing. Unfortunately it is less convenient to get the Session ID than to know the model name, so it's a trade. I'm sure there is a table in the drawing/part/assy that converts the Session ID that is used to the name of the intended model so that future retrievals correctly update the Session IDs to refer to the same items.

I came across this reminder:

Add this text to a one-time-use drawing note:

Session ID 0 : &model_name:0
Session ID 1 : &model_name:1
Session ID 2 : &model_name:2
Session ID 3 : &model_name:3
Session ID 4 : &model_name:4
Session ID 5 : &model_name:5
Session ID 6 : &model_name:6
Session ID 7 : &model_name:7
Session ID 8 : &model_name:8
Session ID 9 : &model_name:9
Session ID 10 : &model_name:10
etc

If an item is no longer in session (has been retrieved, but then erased) or has not been in session (session ID wasn't used yet) the &model_name:# will fail and be replaced with the text "model_name:#" This could be a very long list (hundreds), so creating the text with Excel is a useful option. Since the IDs will update on retrieval and not match the order here, don't bother saving this on a drawing. The next time the drawing is opened the # in "Session ID #" will not match the # in "&model_name:#" and those items that lost the "&" indicator will not be restored even if there is a matching session ID.

I uploaded an Excel file to http://communities.ptc.com/docs/DOC-6181

**Thanks Doug.

***Sometimes named Component ID, it is shown in the model tree under Feature ID.

[dgschaefer]

Ah yes, feature IDs or component IDs are unique even for different occurrences of the same part in an assembly. They are context specific and constant. In other words, if assy B has 2 occurrences of part C, they will have unique and unchanging component/feature IDs. If assy A has part C in it it will have its own feature/component ID which may or may not be the same. These IDs are not shared across objects, in other words assy A doesn't care what the IDs of part C are in assy B.

Everything in Creo has an ID - edges, surfaces, quilts, vertexes, features, etc. - and Creo shows you them as you highlight and select items. This is great,it helps you built intelligently and manage your parent child relationships. In SW, for example, there must be some internal IDs for things, but SW never shows you. Instead, when selecting references you simply get edge1, edge2, etc. Mostly I don't care about those IDs, but I do like that when I need to know I can see them. SWw assumes you never need to know, which is false.

BTW - The note idea above is a great idea, but it will only report the items that are in that drawing. In other words, you may have a 1,000 component assembly open in another window, but if that drawing is only of one part, that's the only thing that'll show up in that list.

Also, the session IDs are reset every time you close and open Creo, however if the note is saved on the drawing Creo will (somehow) remember what line belonged to what item. So if it was session ID 5 when created it'll be line 6 (zero being line 1). Next time you open it, it may be session ID 35, but it'll still be in line 6 of the list.

[dschenken]

I came up with the note idea specifically to deal with a drawing that had multiple models as it was difficult to guess which SID went with which model and going though the process of selecting each of hundreds of models to guess which one matched the session ID I was looking at was too much.

[James62]

Nice discussion,

Yep, parameters or items in drawing notes do get updated when Session ID of the referenced component changes, but the problem is that for instance the text/code of assembly relations doesn't get updated when that happens.

If you consider an assembly to be a parent of some parameter values inside parts of this said assembly, then such sudden change in Session IDs can lead to an unexplainable yellow light on every regen. It just won't be treated the same in the list of failed items, it may not even show you the right component that has the relations set wrong all of the sudden.

From time to time I use Session IDs to create temporary relationships between assembly relations and it's parts relations, that is when the relatioships just can't be created with geometry only. After all is done and when the result is good enough I just remove such relationships.

Question is can you automate the creation of such relations, and also it's removal? Well, then Session IDs is something for you that you may end up using extensivelly.

But if you just want to define relatioships, and keep the definitions in place then have a look elsewhere. Alot of relatioships can be defined just with geometry on model level, and system params on drawing level.

http://odin.me.memphis.edu/ptc/usascii/proe/detail/system_parameters_for_drawings.htm

[dgschaefer]

I've used session IDs in assembly relations regularly and have never had an occasion where they did not update properly.

[James62]

I can't believe that, Doug. Are you sure? Session IDs really used to update in relations as well?

Seems like it might just be another bug that came with Creo Parametric then. One that I propably won't be able to reproduce.

[dgschaefer]

Absolutely. I use it in situation where I have an assy that's treated like a part. An overmolded plastic part or a sheetmetal part with PEM fasteners, for example. In that case I want the REVISION and the PART_NAME parameters (and maybe others) to be the same, so I'll write something like this in the assy relations:

REVISION:2 = REVISION

where 2 is he session ID of the main part in the assy. This makes the REVISION parameter in the part driven by the REVISION parameter in the assy. Because this is in the context of the assy, the session ID of the assy is not needed.

[KenFarley]

I do this all the time, too. I have a part that has weight distributed to specific regions. It's flat on one side and has a variety of heights on the other. To give a table of the different regions on the drawing, I actually use an assembly of the original part cut into the regions of interest. The session IDs are used to get the mass of Region A, Region B, etc. So I can have, in the table, a list of the individual region weights. It updates nicely every time I open it, too.

One word of caution that has stung me in the past, though, is if you're using mass properties or other things like area in relations, be sure to put the relations of interest into the "Post Regeneration" section of the relations. Otherwise, you might not be getting the latest values unless you repeatedly regenerate.

[TomU]

I've created some pretty complex automated assemblies in the past, and a guaranteed way to get the session ID references messed up is to have models suppressed when duplicating. I actually had to go through and create special logic so all models used in all assemblies were resumed prior to duplication.

As far as using the session ID directly in relations syntax, keep in mind that you never need to specify the session ID of the active model (part or assembly) that you are creating the relation in. You only need to specific the session ID of the other model(s) you're referencing.