Mastering Layers Q&A

[Jacoolo]

ok, my fault, sorry for muddle

gkbeer, you were first right. I did not notice look for 3D Curve. I put there Look for Feature.

My fault. Everything works fine now. Thanks a lot.

 

[ameuniot]

[/QUOTE]

A separate mapkey will be needed for each status to be set...

Edit: I would say that paired mapkeys like /plane and \plane would work well as on/off mapkeys for the planes layer.
[/QUOTE]


This is exactly the problem I am trying to avoid. Prior to Wildfire, you could have one mapkey that would toggle the layer on or off. Now you need one mapkey to turn the layer on and one mapkey to turn the layer off. This was a HUGE mistake on PTC's part, as far as I'm concerned. It might seem like a minor difference to some of you, but think about it:

Scenario 1 (Then): I have numbered layers and I know that '1' toggles the master on/off. '2' toggles the curves on/off and so on. I used to be able to fly through layer changes by hitting single key mapkeys to toggle layers. And I only needed to remember one mapkey per layer.

Scenario 2 (Now): I need one mapkey to turn the layer on, say '11'. And one mapkey to turn the layer off, say '1q'. I have to choose between mnemonic naming (like using 'o' for "on" and 'f' for "off") or spatial naming to keep the mapkeys close to each other. I chose the latter because nothing slows down mapkey usage more than having to move your hand all around the keyboard. PTC's current setup forces me to hit twice as many keystrokes to turn layers on or off and all the while they are going on about how fewer mouse clicks Wildfire requires. Ugh.

Anyhow, didn't mean to slip into a rant. I know this is not the place for it. I just keep holding out a glimmer of hope that somebody out there knows some command I can insert into the mapkey or some setting in the config to set layers to toggle again. So far, no luck...

But thanks for the great topic. I'm fired up about the new rules functionality. Our new trick is to have features automatically assigned to a "Construction" or "X-Section_Plns" layer by adding a 'C_' or 'X_' to the feature's name. The rules in those layers see the rename and grab the feature.

Cheers,
A

 

[dgs]

Check your mapkeys in a text editor. If there's a 1 or 0 at tend where the display status is set, try deleting it. That may turn it into a toggle. I know that works for things like datums display on/off and other toggle commands so it may work there.


I posted a tutorial on creating a toggle state mapkey on the old Design Knowledge Base web site, but the site seems to be gone now. It's still available in the Wayback Machine archives through, here. You can also see this post & the comments on the Pro|E FAQ blog for an example.

 

[dgs]

Glenn - I have a question on layers with Copy Geoms.


In the past, I've put the entire copy geom on a layer and none of the items. I've also tried, in the skeleton, not to place items that will be published on layers as they will end up on those same layers in the target model. That has made it difficult to figure out why things can't be displayed.


Knowing what I do now, I understand that I need to rethink my layering strategy with copy geoms. I'm wondering how you handle it?


I can see it being handy to be able to hide the entire copy geom, but I would also see benefit in hiding the copy geom except for the planes within it or the curves or ??


Thinking about visibility rule #1, however, if I put the copy geom feature on a layer and blank it, I can't then show any of the entities within it by isolating another layer, can I? So what do you do?

 

[gkbeer]

To have a single entity from a copy geom visible

Put the copy geom on a blanked layer (lay1). This causes the feature and it's entities to be invisible.

Put the copy geom and one entity of the copy geom on an isolated layer (lay2).

What should happen is that the single entity will be visible.

================
Couple of tests I just did..

WF2 m250 - I could not select a csys from within the copygeom for inclusion on a layer, planes yes, csys no. That's a bug.

Also any layer containing the copygeom feature when isolated, caused all the entities to be visible except for those entities on blanked, but not on isolated layers. I'll diagram this later tonight.

WF3 M100 - Was able to select the csys in the copygeom and put it on a layer (bug fixed)

Here's a pic of how to make just the csys visible.

View attachment 4073

This works the same if the copygeom feature is removed from both layers.
The above pic is from wf3 m100.

...Deleted nonsense...

On second thought I was wrong with what I had wrote. The behavior is exactly as the various rules predict.

I've said that unless there is a good reason, one should put features on layers instead of entities, and hinted that when the need to put entities on layers became necessary it would be self evident.

This is a case of that. The above pic shows one way to handle making a subset of copygeom entities visible. I mentioned that it would work the same if the features were left off of the layers. Just don't mix and match those techniques. Either make it a policy to always include the copy geom feature with the entities, or to always exclude.



Edited by: gkbeer

 

[gkbeer]

Since the topic of putting entities onto layer is up for discussion I'll mention something about datum curves.

Intent chains, every sketched curve includes an intent chain. Unfortunately Pro/E considers the intent chain to be an entity the same as any individual segment in the sketched curve.

A layer rule that gathers 3D curve entities will also collect intent chains. It's kind of a problem. The intent chain sits somewhere between the feature and the individual segments of the curve.

If there is a need to control the visibility of curves at the entity level, it is necessary to decide if curve features and intent chains will be managed. It's like the copy geoms above, either always put the curve features and or intent chains on every layer with the individual segments to be made visible, or don't.

Mixing it up by choosing to control one sketched curve's visibility, by placing it's feature on a layer, then doing something different for another, will only lead to confusion.

 

[dgs]

The above pic shows one way to handle making a subset of copy geom entities visible. I mentioned that it would work the same if the features were left off of the layers. Just don't mix and match those techniques. Either make it a policy to always include the copy geom feature with the entities, or to always exclude.

So, if I understand you right, if the copy geom feature is to be put on a layer, the copy geom feature needs to be included on the entity layers as well. Or, don't put the copy geom feature on any layers, instead add all the copy geom entities to the copy geom layer, then the individual entities can be placed on their own layers.


The former seems problematic as you'd have to keep adding the copy geom to the layers for entity types. I suppose you could create a rule for those layers that would find copy geom features with those entity types. Seems a little odd, though.


The latter seems odd to, though, since your copy geom layer would only have copy geom entities, not copy geom features. Hmmm.


How does the fact that any entities in the copy geom that were on layers in the source model, end up on those same layers in the target model effect things?

Intent chains, every sketched curve includes an intent chain. Unfortunately Pro/E considers the intent chain to be an entity the same as any individual segment in the sketched curve.

In a similar vein, I've noticed that Pro|E treats quilts like feature entities as well. This seems odd as a quilt could be the sum of dozens of features, but that's the way it works.


Again, thanks a lot for your help.
Edited by: dgs

 

[dgs]

Another anomaly - If a feature has been hidden from the model tree, it won't display if placed on a layer that is isolated. An exception to invisibility rule #1.


This, the oddities with quilts and intent chains and the fact that the isolate command is not part of the layer dialog or RMB menu tells me that the power in the layer functionality Glenn's discovered isn't well understood or documented within PTC. Unintended functionality, perhaps?

If so, that's scary as any of this could change with the next release of Pro|E.


I'd love to see the documented design intent from PTC on how layers are intended to work.

 

[gkbeer]

How does the fact that any entities in the copy geom that were on layers in the source model, end up on those same layers in the target model effect things?

I don't think I've observed that effect. That shouldn't happen unless both the source and target model have same layers w/rules that are collecting entities instead of features.

Or if some other type of layer operation is automatically taking place - as in having def layer options.

 

[gkbeer]

Another anomaly - If a feature has been hidden from the model tree, it won't display if placed on a layer that is isolated. An exception to invisibility rule #1.


This, the oddities with quilts and intent chains and the fact that the isolate command is not part of the layer dialog or RMB menu tells me that the power in the layer functionality Glenn's discovered isn't well understood or documented within PTC. Unintended functionality, perhaps?

If so, that's scary as any of this could change with the next release of Pro|E.


I'd love to see the documented design intent from PTC on how layers are intended to work.

Hidden from the model tree - as in datums on the fly that were created in 2001.
That behavior seem to be as it should be. Though the datum on the fly technique seems to be depreciated in WF.

Intent chains are something new with WF. That they complicate how layer visibility results are achieved is troublesome. In spite of the extra trouble they do seem to work predictably.

That PTC hasn't well documented how layer status works is an understatement.

Isolate, by various names, has been around since the beginning. Nothing I've illustrated is different from how things were as far back as rev 6 or 7.
I very much doubt any of this functionality will disappear. I would like to see isolate put back into the context menu. Having it in the left toolbar seem to work almost as well.



Edited by: gkbeer

 

[dgs]

Or if some other type of layer operation is automatically taking place - as in having def layer options.

That's where I've seen it, in a client file whose layers are defined with def_layer. I thought it was dues to the copy geom and didn't take the def_layers into account.


The hidden items issue I'm seeing is in a skeleton model created (I believe) in WF2. I have a sketch feature that was auto-hidden because it was used for a project feature. That sketch is then placed on an isolated layer, but it does not become visible until it is made visible in the model tree.

 

[gkbeer]

So, if I understand you right, if the copy geom feature is to be put on a layer, the copy geom feature needs to be included on the entity layers as well. Or, don't put the copy geom feature on any layers, instead add all the copy geom entities to the copy geom layer, then the individual entities can be placed on their own layers.


The former seems problematic as you'd have to keep adding the copy geom to the layers for entity types. I suppose you could create a rule for those layers that would find copy geom features with those entity types. Seems a little odd, though.


The latter seems odd to, though, since your copy geom layer would only have copy geom entities, not copy geom features. Hmmm.

Yes! You seem to have it right. Part of Mastering Layers is knowing what has been put on the layers, and how complex it can be to have both features and entities on layers. This is why I recommend to put features on layers instead of entities. Reserving the placement of entities on layers for those specific models where finer control is needed. Of course if all your work requires that kind of finesse, maybe it's good to go the other way and only put entities on layers.

Above all, use what works, have a consistent strategy and stick to it.

 

[gkbeer]

Or if some other type of layer operation is automatically taking place - as in having def layer options.

That's where I've seen it, in a client file whose layers are defined with def_layer. I thought it was dues to the copy geom and didn't take the def_layers into account.


The hidden items issue I'm seeing is in a skeleton model created (I believe) in WF2. I have a sketch feature that was auto-hidden because it was used for a project feature. That sketch is then placed on an isolated layer, but it does not become visible until it is made visible in the model tree.

Unhide it by redefining the feature, there is a check box in the control panel that says "hide original", I think it's under options. Uncheck it. Then you can control its visibility via layers.

 

[gkbeer]

About putting components on layers and using ISOLATE.

If a component is on an isolated layer, assembly features will be invisible, and they can't be made visible, even by placing them on an isolated layer.

Here is the way I figure it.

The top assembly is being considered a component same as its members. Even though it can't be put on a layer, it's treated like any other component not on a layer.

When a layer containing a component is isolated, the top assembly becomes invisible. Being invisible, all assembly features become invisible, and while they can be put on isolated layers, the Basic Invisibility Rules keeps them invisible.

What bites about that, is when this assembly is added to another, and it, in turn, is added to an isolated layer, all of the formerly invisible features become visible again. You may not have to deal with this, but your co-workers will.

The issue, as I see it, is that this doesn't scale well when working in larger projects. Even highly skilled people will have problems keeping it all straight.

That being the case, I'll still recommend keeping it simple by not putting components on layers. Style states can yield the same result without the problems.

 

[dgs]

At the PTC|User conference I was fortunate enough, at one of the lunch sessions,to sit ata table with some veteran users and the head of PTC's tech support. We all lamented the common refrain we hear from tech support, "That's intended functionality." His advice to us was that if tech support tells you that, ask fro the documentation. If it's intended functionality, they should be able to produce documentation to show it.


In that spirit, and considering we're attempting to understand the intended functionality behind layer display, I decided to ask for the documentation. I justfiled this tech support call with PTC:
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">


I'd like to see PTC's documentation regarding the intended functionality of the layer display options.


----------------


There are 3 available display statuses for layers: shown, hidden and isolated. Additionally, there are multiple items that can be placed on layers; components, features, feature entities, quilts, etc.


There appears to be a hierarchy to how items will display, especially when placed on multiple layers. For example, if an item is on 2 layers, and one is shown and one is blanked, the blanked status overrides the shown. Also, if an item is on 2 layers, and one is blanked and one is isolated, the isolated status overrides the blanked. So, it would seem that isolated takes precedent over blanked and blanked takes precedent over shown.


Also, it seems that sub items first follow the display status of their parents. For example, a single sketch entity (line or arc) is a sub-item of the sketch feature used to create it. If the sketch entity is placed on an isolated layer and the sketch feature itself is on another blanked layer, the entity will follow the display status of it's parent, and will be blanked. This 'sub-item' rule seems to take precedent over the 'isolate-hidden-shown' rule.


What is unclear is where items like quilts, a single item created by multiple features, fall in this. Additionally, items hidden through the model tree or auto hidden, and ending up on the 'hidden_items' layer, seem to remain hidden regardless of other layers they are on being set to isolate, violating the 'isolate-hidden-shown' rule.


I'm assuming that PTC has some documentation detailing how layer display should function. I'd like to see that so I can better implement layers in my work.</BLOCKQUOTE>
I'll let you know what I find out.

 

[gkbeer]

quote:

<div style="margin-left: 40px;">What is unclear is where items like quilts, a single item created by
multiple features, fall in this. Additionally, items hidden through
the model tree or auto hidden, and ending up on the 'hidden_items'
layer, seem to remain hidden regardless of other layers they are on
being set to isolate, violating the 'isolate-hidden-shown' rule.

</div>Without a doubt exceptions have been made for various special functions. Like the hide/unhide operation. I would not expect that to be included in the layer doc pages.

 

[dgs]

He pointed me to the help files. (Doh!) They were fairly complete, but flawed. Here's what I responded with after reading 'About Layer Display', which is available if you search 'fundamentals' for 'layers':
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">


I've read the document and have some further questions. There seems to be some inconsistencies between the document and the behavior of Pro|E

1 - The document states "In Assembly mode, if you set a specific layer or layers to Isolate, the system hides all components. In addition, the system hides all other items that are assigned to any non-Isolate layer." However, that does not seem to happen. Components are only hidden if a layer containing components is isolated. Any other layer is isolated, components are not hidden.

2 - The document states "Note: In Assembly mode, if you have components on layers that you then set to Hide, the system hides all non geometry items (datum planes, datum axes, feature axes) even if they are also on the displayed layers." I cannot reproduce this behavior. If I have a component on a hidden layers, non-geometry items in my assembly are still visible, whether on a shown layer or simple not on a layer.

3 - The document states "Note: Isolate has priority over Hide. Therefore, if a member is on two layers, one set to Isolate and the other set to Hide, the member is shown." This does not work if an item is on the 'hidden items' layer. Then hide takes precedent over isolate. This is a bug since isolate and hide have been around a lot longer than the 'hidden items' layer and the functionality has always been as described in the help document.

4 - The document states "The only features on a layer that layer display operations affect are datum and surface features. Solid geometry is not affected. ... The only exception to this rule is that, in an assembly solid, you can hide components." Actually, you can put 'Solid Geom' on a part layer and hide the part solid. Individual features cannot be hidden, but the entire solid can.

5 - I don't understand what this means: "In Assembly, Show affects the level of the member and levels above it; Hidden affects the level of the member and levels below it." Can you explain it for me?

It seems that #1, #2 & #4 are errors in the documentation and #3 is a unintended functionality (a bug) in the software that needs to be fixed (at least in WF2, M220).</BLOCKQUOTE>
As I stated, I think the hide/unhide thing is a bug. It does not follow long standing, and documented, layer display functionality. It remains to see if PTC agrees. The others are merely typos in the docs. Perhaps the WF3 docs are better, but I doubt it.
I think you're right about quilts. There is some kind of special case going on that's not documented. I need to ask about that. What's more interesting is the way the docs are worded, your 'invisibility rule' only really applies consistentlyto part features and feature entities. Layers in assy mode seem to be a collection of special cases, rather than an attempt to follow the rules laid out in part mode.
For example, in part mode, isolating a layer with a feature on it has no effect on other features, except where controlled by other layers. In assy mode, isolating a layer with a component on it will hide all other components, regardless of their layer status.

 

[gkbeer]

I'm going to make my comments in line, in bold. Yes! the layer documentation is very poorly written. There are obvious mistakes. With the errors it's sometimes hard to figure out if the software is actually functioning as intended.

He pointed me to the help files. (Doh!) They were fairly complete, but flawed. Here's what I responded with after reading 'About Layer Display', which is available if you search 'fundamentals' for 'layers':
<blockquote dir="ltr" style="margin-right: 0px;">


I've read the document and have some further questions. There seems to be some inconsistencies between the document and the behavior of Pro|E

1 - The document states "In Assembly mode, if you set a specific layer or layers to Isolate, the system hides all components. In addition, the system hides all other items that are assigned to any non-Isolate layer." However, that does not seem to happen. Components are only hidden if a layer containing components is isolated. Any other layer is isolated, components are not hidden.


Yes, this is exactly my experience. This is one of the items that the developers need to clarify. Specifically if this observed behavior is intended or not. Either fix the bug or the documentation. Currently, I deal with this by not putting components on layers.

2 - The document states "Note: In Assembly mode, if you have components on layers that you then set to Hide, the system hides all non geometry items (datum planes, datum axes, feature axes) even if they are also on the displayed layers." I cannot reproduce this behavior. If I have a component on a hidden layers, non-geometry items in my assembly are still visible, whether on a shown layer or simple not on a layer.


I'm pretty sure this is a documentation error. If the words hide and displayed are replaced by Isolate and Isolated - this documentation matches the software's behavior.

(Isolate used to be called display. I believe the person who was responsible for updating the documentation wasn't familiar enough with the software to understand what they were doing)

3 - The document states "Note: Isolate has priority over Hide. Therefore, if a member is on two layers, one set to Isolate and the other set to Hide, the member is shown." This does not work if an item is on the 'hidden items' layer. Then hide takes precedent over isolate. This is a bug since isolate and hide have been around a lot longer than the 'hidden items' layer and the functionality has always been as described in the help document.

I disagree about this being a bug. This Note had to be added to the documentation when it was decided to expose the "hidden items" layer. Previously that layer, or one like, it was there, just not listed.

The "Hidden Items" layer has a "Special Status" that goes beyond the normal for Hidden and The documentation needs to identify this status as being different, also the layer tree needs to use a distinguishing icon.


4 - The document states "The only features on a layer that layer display operations affect are datum and surface features. Solid geometry is not affected. ... The only exception to this rule is that, in an assembly solid, you can hide components." Actually, you can put 'Solid Geom' on a part layer and hide the part solid. Individual features cannot be hidden, but the entire solid can.

I really wish this hadn't been mentioned. I can't see where putting "solid geom" items on a part layer will cause anything but trouble.


5 - I don't understand what this means: "In Assembly, Show affects the level of the member and levels above it; Hidden affects the level of the member and levels below it." Can you explain it for me?

Substitute Isolate for the word show. (More bad documentation).


What this is saying is that the Isolate layer status of a subassembly, can impact the visibility of components in higher level assemblies. One part, all by its self on an isolated layer in a low level subassembly, can cause all the other components, in your product structure, not on isolated layers, to be invisible.


The second part, about impacting levels below, is another way of stating the basic invisibility rule. (If the part is invisible the features are invisible and so on.)


It seems that #1, #2 & #4 are errors in the documentation and #3 is a unintended functionality (a bug) in the software that needs to be fixed (at least in WF2, M220).#1 Could go either way. But it's most likely a documentation problem.
#2 Is a documentation problem.
#3 Is a feature, that, in WF, has been exposed for what it is and is poorly explained.
#4 Is ten+ year old documentation that needs to be brought fully up to date.
#5 Strictly bad documentation. I'm sure there could be a long discussion about how we might like this to work, but until there is an actual change in how the software operates, the documentation should be corrected.

</blockquote>
As I stated, I think the hide/unhide thing is a bug. It does not follow long standing, and documented, layer display functionality. It remains to see if PTC agrees. The others are merely typos in the docs. Perhaps the WF3 docs are better, but I doubt it.I think you're right about quilts. There is some kind of special case going on that's not documented. I need to ask about that. What's more interesting is the way the docs are worded, your 'invisibility rule' only really applies consistentlyto part features and feature entities. Layers in assy mode seem to be a collection of special cases, rather than an attempt to follow the rules laid out in part mode.I think there is only one special case where assy's are the issue. Follow this logic and see if you don't agree.

The documentation says "Isolate affects the level of the member and levels above" (from #5 above).

The top assembly item, is above component on an isolated layer. The assy is impacted, and becomes
invisible for not being on an isolated layer. It can't be on a layer, it's the top assembly. (Note: no special case is being made for the top assembly)

Think about it, the basic invisibility rule says "Once and item is rendered invisible everything that makes up that item is made invisible". Given that, you can see that all the features and components should be invisible. The exception seems to be for components that are on isolated layers. (this is the only special case where assemblies are concerned)

For example, in part mode, isolating a layer with a feature on it has no effect on other features, except where controlled by other layers. In assy mode, isolating a layer with a component on it will hide all other components, regardless of their layer status.Where assemblies are concerned, I think this is efficient cpu and data wise. If an assembly didn't make everything else invisible when a component containing layer was isolated, then like parts, everything would have to be on a layer. That takes up space in the database. Pro/E has to spend more cpu cycles keeping track of the whole shebang. Not to mention the time you would spend dealing with those long layer lists.
FWIW: I have the vague memory (circa 1993) that parts USED to be the same as assemblies in that respect, and that enough people requested differently that it was changed.

 

[dgs]

I see what you mean. I wish they would remove all the special cases regarding assemblies (except the one aboutisolating components)in the docs and explain it using your 'visibility rule'. It makes things much easier to follow. Regardless, the docs need corrections & clarifications,big time.


As far as #3 goes, you are likely right, PTC sees this as intended functionality of the hide command. However, the docs (pretty clearly, actually) indicate otherwise. There's nothing in the page entitled 'Using the Hidden Items Layer' to indicate that it has special rules either. I'd like to see the hidden items layer function like other layers. As it is now, it makes it hard to effectively use isolate, especially since Pro|E adds stuff to the hidden items layer by itself. If I could simply not use it, that would be fine ,but I can't. It should act like other layers. The way the docs are written makes a good case for it, I think.


This is one of those crusades for me,to get PTC to clean this up. I get one of these bugs in me every year or two. I push it with tech support, they typically call it intended, i push back a bit and then get tired of fighting the machine and give up.

We'll see what happens here.

 

[eholmes124]

Great forum, very helpful for my latest endeavor.


I saw Glenn present at the 2007 PTC/Userconference andrealized we could makeuse of his methods forlayer management to solve our current issues.Iwork for a manufacturer that has grown considerably over the last few years and needless to say layers were not a priority. I think we have at least (6) different versions of a GTOL layer. In addition, we have also used various consultants for different projects which adds to the problem.


Previous: we relied onthe config.prodef_layer optionforall parts. Of courseduring design work everyone in our group would create layers as needed and the results were as expected, the inevitable Datum blob.


Current WF 3.0 M090: We have implemented a new start part with rule based layers. The rule options for Associate, Enable and Independent are all set. All previous and newly createdfeatures are moved per the rule to these layers. No problem.


I created a mapkey to delete all layers from parts within the assembly as well as the assembly. No problem. At this point our procedure is to insert a blank part w/ the start part / rule based layers into the assembly. Only the layers from this part arevisible in the layer tree. I then select all of these new layers and use EXTEND RULES to push these layers w/ rulesinto all of thesub-assembly parts. The first time or two it worked flawlessly. No problem


Forsome inexplicable reason this method no longer works. Sometimes there won't be any feedback in the dashboard that previously indicated the parts being edited. On a few parts/assemblies we have seen this error ".black_hole cannot be created in model xxx" This has something to do with components/featuresbeing hidden in the assemblies/parts prior to the layer manipulation. Big problem.


Apparently the .black hole layer is related to WF 1.0 and the PTC TPI says that it cannot be removed manually and you have to send the part back to PTC in order to have this layer deleted. Shocked but not surprised https://www.ptc.com/appserver/cs/view/solution.jsp?n=130309


Has anyone else experienced this problem? If so were you able to resolve it? We have a call into PTC and it sounds like they have created an SPR for the EXTEND RULES function since the supportrep could not resolve the issue and there is no documentation in WF 3.0 for EXTEND RULES.


Any assistance is very much appreciated.
Edited by: eholmes124