Mastering Layers Q&A

[verge]

Hmmmm....that's an interesting dilemma. The hard part may be avoiding innuendo with a subject like "layers"...


I'm sure some of our forum compatriots could give you some suggestions

 

[dgs]

I've been thinking about [a website], I have a web server, I just can't think of a cool name for the site.

I run a personal blog and I don't think the clever name is as big a deal as it seems. Make it short and related to what you're writing about and then keep the content fresh. If you have good content, and it's indexable by Google, people will find you. Use blog software like Wordpress or Movable Type (what I use) and it'll generate pretty good indexable code. My site routinely ends up in the top 10 for various specific (and relatively obscure) searches, and I'm not even trying, just writing.

I've toyed with the idea of a Pro|E blog for some time now too.

 

[dgs]

The first set looks fine
The second set is putting entities on layers, which is about all you can do with a copy geom. As long as the copy geom features are kept off of layers it should work fine.

The second set of rules could be combined, with the first set, and then there would have be 4 layers. For the stated purpose of just clearing every thing off. That would work fine.

Yeah, I thought of that, but I want to be able to show the copy geom items independently.

My axis layer rule
(Type == Has Axis(Category: Miscellaneous)) Look for: feature, look by: feature.

That's what I'm thinking too, although in keeping with the idea of separating the copy geom, I'd have to add an exclusion rule for those. My other thought is to use axis entities for the axes layers, but that creates another exception to the 'only features' idea that has to be explained. On the other hand, putting features with axes on a layer may also put a feature with a surface on a layer, which would be problematic.

Any thoughts on surface layers? I could do like you do with axes - for feature, by feature, misc, has surfaces (excluding copy geoms) or I could search for quilt, history = all (excluding copy geoms). How would the latter be handled in the hierachy of the invisibility rule? A quilt is not really an entitiy or a feature.

 

[dgs]

Stepping back a bit, Glenn, refresh my meory: How do you add in the new layers to a part that you 'cleaned'? Have you simply recorded a mapkey that adds in your default layers? I've used a layers.pro file to add in layers before, but that doesn't capture layer rules, right?

In WF4 it looks like you can save queries on disk, but I don't see a way to do that in WF2 or WF3.

Also, we have clients still on WF2, but I'm trying to move them off of it. Can you clarify the advantages, in terms of layers and the find tool, for using WF3 over WF2? In the first page you mention that threaded hole axes are now selectable without selecting the thread quilt. Is that the only advantage or difference between WF2 & WF3?

UPDATE: Maybe that's NOT fixed in WF3, at least not M170. If I create an extruded cylinder, and place the axis entity on a layer by rule (axis|axis name=*) and quilts on another (quilt|n/a history+all), isolating the axis entity layer with the quilt layer hidden does not reveal the extruded axis.

Edited by: dgs

 

[dgs]

Another interesting item:

Search for feature by 3D curve name=* and you only get sketches that have been renamed from the default 'sketch*'. Rename a sketch and it pops onto that layer.

 

[dgs]

Another oddity:

If you place a feature on a layer in your skeleton (say a quilts layer) and a layer of the same name exists in a part with a copy geom from that skeleton and that feature is part of the copy, it ends up on that layer in the target model as a feature entity.

That's clear as mud I bet. How about an example.

In my skeleton, I have a layer named 'Quilts'. It has a rule that searches for features, by feature, type = Misc : Has Quilts. I then use a copy geom feature to copy one of those quilts into a cart which has the same layer with the same name and the same rules. That part layer will capture all features with quilts, including the copy geometry, and it will have the quilt entity from the copy geometry as well.

When viewing the layer properies for thew layer, it shows a + next to the quilt entity adn the rule symbol next to the others.



So, how to I prevent that? Really throws a wrench in the works.

EDIT: Are you guys enjoying my 'stream of consciousness' postings in this thread?

It turns out that this might actually be a very good thing. It essentially accomplishes the same thing that I wanted to without the separate 'copy geometry' rules. As long as the copy geom features aren't on any layers, isolating the quilts layer gets all the quilts, including the quilts in the copy geom. Nice.

Going one step further, if I put the copy geoms on their own layer I can then hide it and isolate the quilts layer and get only the native quilts, not copy geom quilts.

The only thing i can't do is isolate teh copy geom itself without any native features.


Edited by: dgs

 

[dgs]

Last thing. There's a bit of a cascading effect won the 'has axis' layer rules.

We model a lot of symmetric items in half and mirror. Oh occasion, if it's symmetric in two ways, it'll get modeled in fourth and mirrored twice. If the first mirror feature has an axis in it, which is likely, it gets added to the AXIS layer. Then, in the same way the copy geom entities get pulled into a layer if they are on the same layer in the source part, because mirror_1 was on the AXIS layer, all the various mirrored entities from mirror_1 (axes, planes, points, surfaces) that are part of mirror_2 get added to the axis layer too.

Messy.

So I think I'm going to add an exception to the axis & quilt layers (they both use a 'has ___' rule) for mirror features. That seems to clean it up.

Now, the question is what else might produce a similar result?

 

[gkbeer]

That's what I'm thinking too, although in keeping with the idea of separating the copy geom, I'd have to add an exclusion rule for those. My other thought is to use axis entities for the axes layers, but that creates another exception to the 'only features' idea that has to be explained. On the other hand, putting features with axes on a layer may also put a feature with a surface on a layer, which would be problematic.

Remember: You can put items on many layers. That's why Isolate is there. It does not matter how many layers an item is put on. As long as it's on the one that is Isolated. Now you might have to put both the feature and it's entities both onto a layer in order to get it to show.

Any thoughts on surface layers? I could do like you do with axes - for feature, by feature, misc, has surfaces (excluding copy geoms) or I could search for quilt, history = all (excluding copy geoms). How would the latter be handled in the hierachy of the invisibility rule? A quilt is not really an entitiy or a feature.

I've struggled with this too. For the most part I deal with copy geoms manually.

 

[gkbeer]

Stepping back a bit, Glenn, refresh my meory: How do you add in the new layers to a part that you 'cleaned'? Have you simply recorded a mapkey that adds in your default layers? I've used a layers.pro file to add in layers before, but that doesn't capture layer rules, right?

In WF4 it looks like you can save queries on disk, but I don't see a way to do that in WF2 or WF3.

Also, we have clients still on WF2, but I'm trying to move them off of it. Can you clarify the advantages, in terms of layers and the find tool, for using WF3 over WF2? In the first page you mention that threaded hole axes are now selectable without selecting the thread quilt. Is that the only advantage or difference between WF2 & WF3?

UPDATE: Maybe that's NOT fixed in WF3, at least not M170. If I create an extruded cylinder, and place the axis entity on a layer by rule (axis|axis name=*) and quilts on another (quilt|n/a history+all), isolating the axis entity layer with the quilt layer hidden does not reveal the extruded axis.

I use the Search dialog to create layers. After refining the search rules, I use the save query function to create the layer. This has the effect of creating the layer with the associated check in place. I created a mapkey for each layer. The biggest trick was getting the find dialog to revert to the same state before running each mapkey. I finally created a mapkey /resetfind that preps the search tool before running the individual layer creating mapkeys. I believe the resetfind mapkey is shown in the first post.

I'm afraid I can't remember the WF2 well enough to list the differences.

The axis didn't show because it is considered a sub entity of the quilt entity. As such the basic visibility rule is kicking in. I think the basic rational is that if the quilt isn't visible that there is no reason to show the axis. So in the case noted all the other axis would show but not the ones associated with the invisible quilt.

 

[gkbeer]

Another oddity:

If you place a feature on a layer in your skeleton (say a quilts layer) and a layer of the same name exists in a part with a copy geom from that skeleton and that feature is part of the copy, it ends up on that layer in the target model as a feature entity.

That's clear as mud I bet. How about an example.

In my skeleton, I have a layer named 'Quilts'. It has a rule that searches for features, by feature, type = Misc : Has Quilts. I then use a copy geom feature to copy one of those quilts into a cart which has the same layer with the same name and the same rules. That part layer will capture all features with quilts, including the copy geometry, and it will have the quilt entity from the copy geometry as well.

When viewing the layer properies for thew layer, it shows a + next to the quilt entity adn the rule symbol next to the others.



So, how to I prevent that? Really throws a wrench in the works.

EDIT: Are you guys enjoying my 'stream of consciousness' postings in this thread?

(1)It turns out that this might actually be a very good thing. It essentially accomplishes the same thing that I wanted to without the separate 'copy geometry' rules. As long as the copy geom features aren't on any layers, isolating the quilts layer gets all the quilts, including the quilts in the copy geom. Nice.

Going one step further, if I put the copy geoms on their own layer I can then hide it and isolate the quilts layer and get only the native quilts, not copy geom quilts.

(2)The only thing i can't do is isolate teh copy geom itself without any native features.

(1) That, I read somewhere is intended function. It has nothing to do with rules. Other than the skeleton model's layer rule was what put it there first.

(2)That's pretty much the nature of creating some layers with features and others that have only entities.

 

[gkbeer]

Last thing. There's a bit of a cascading effect won the 'has axis' layer rules.

We model a lot of symmetric items in half and mirror. Oh occasion, if it's symmetric in two ways, it'll get modeled in fourth and mirrored twice. If the first mirror feature has an axis in it, which is likely, it gets added to the AXIS layer. Then, in the same way the copy geom entities get pulled into a layer if they are on the same layer in the source part, because mirror_1 was on the AXIS layer, all the various mirrored entities from mirror_1 (axes, planes, points, surfaces) that are part of mirror_2 get added to the axis layer too.

Messy.

So I think I'm going to add an exception to the axis & quilt layers (they both use a 'has ___' rule) for mirror features. That seems to clean it up.

Now, the question is what else might produce a similar result?

So you would prefer that only the items that are not mirrored be put on layers?
Or... Is it that the mirror feature is being put on all those layers because it has all those entity types? Must be causing something to become invisible that shouldn't be.

 

[gkbeer]

One way I look at the task of creating layers. I simply first to create the layers necessary to remove the clutter from the display. Those layers have rules for that.

Additional layers are created to bring back specific subsets of what was previously removed. Those subsets are drawn from across the entire mode. An axis here, a datum there, this or that. Showing all of a single kind of thing has it's place, but the other is quite useful.

 

[dgs]

(1) That, I read somewhere is intended function. It has nothing to do with rules. Other than the skeleton model's layer rule was what put it there first.

(2)That's pretty much the nature of creating some layers with features and others that have only entities.

Actually, all of my rules add only features to layers, the entities just end up there down stream.

Here's the deal. A rule puts features that have axes on an 'AXIS' layer. The feature MIRROR_1 mirrors the entire part, and therefore has whatever axes exist in the part in it. The feature MIRROR_1 ends up on the AXIS layer.

Then, the part is mirrored again creating MIRROR_2. For the same reason, the feature MIRROR_2 ends up on the axis layer. However, because the source of MIRROR_2 is also on the AXIS layer, all the entities for MIRROR_2 end up on that layer as well.

So, if I have axis A_2 in my part, it becomes A_2_1 in MIRROR_1 and axis A_2_1_1 in MIRROR_2. Axis entity A_2_1_1 ends up on the AXIS layer, not by layer rule, but by some kind of internal Pro|E rule similar to the 'invisibility rule'

Pro|E evidently assumes that, since the feature containing A_2_1 was on the AXIS layer, any copies of the entities in MIRROR_1 should be on that layer as well.

The same happens with copy geoms. If, in the source part, you place the plane feature DTM2 on the PLANE layer, in the target part (with the copy geom), the plane entity DTM2 of the copy geom will end up on the PLANE layer there, if the PLANE layer exists. If the two parts don't have the same layers, it doesn't happen. Pro|E won't create the layer if it doesn't exist.

The nice thing about that with copy geoms is that if I have a layer for copy geom features that's hidden and I isolate my PLANE layer, I only get the planes native to the part. If I need to see the copy geom planes, I isolate both layers. There's no way to Isolate just the copy geom planes, though.

One way I look at the task of creating layers. I simply first to create the layers necessary to remove the clutter from the display. Those layers have rules for that.

Additional layers are created to bring back specific subsets of what was previously removed. Those subsets are drawn from across the entire mode. An axis here, a datum there, this or that. Showing all of a single kind of thing has it's place, but the other is quite useful.

That's what I'm going for. I want to clean everything off and let my users be able to show the sub-sets that matter to them for the work they are doing now. I think I have it adn I'm creating mapkeys to make it all happen. I now need to modify my AXIS & QUILT layers to exclude mirror features and I think I'll be good. Then add them to our corporate config.win and schedule a short training session on using them.

I'll post my final set when I'm done.


Edited by: dgs

 

[dgs]

So I've got all my layer mapkeys set up, but when I run each one I get this error in the message area:

<div style="margin-left: 40px;">Rules cannot be evaluated for submodels of a Layer model.
</div>
It only happens when I leave 'Propagate Status' checked in the 'Save Rules' dialog:



This is checked by default and seems to have the same effect as creating a layer and then selecting 'Extend Rules' in the layer drop down menu. Unchecking it prevents the error and it does not occur if I create the assy level layer and then extend the rules.

It happens in WF2, WF3 & WF4.

Is this anything to worry about?

EDIT:

Answered my own question. When created with 'Propagate Status' checked, the layers in the submodels don't have 'Rules Enabled' checked. When added to the submodels by the 'Extend Rules' command, they do.

Now I get to re-do my mapkeys.

Edited by: dgs

 

[gkbeer]

So I've got all my layer mapkeys set up, but when I run each one I get this error in the message area:

<div style="margin-left: 40px;">Rules cannot be evaluated for submodels of a Layer model.
</div>
It only happens when I leave 'Propagate Status' checked in the 'Save Rules' dialog:



This is checked by default and seems to have the same effect as creating a layer and then selecting 'Extend Rules' in the layer drop down menu. Unchecking it prevents the error and it does not occur if I create the assy level layer and then extend the rules.

It happens in WF2, WF3 & WF4.

Is this anything to worry about?

EDIT:

Answered my own question. When created with 'Propagate Status' checked, the layers in the submodels don't have 'Rules Enabled' checked. When added to the submodels by the 'Extend Rules' command, they do.

Now I get to re-do my mapkeys.

Exactly!
-------------
In WF1, you could also select the find in submodels check. For the datum planes layer this had the effect of putting every plane from every model on the assembly layer. You could put features from submodels onto assy layers in WF1. It was not a speed enhancing feature.

 

[dgs]

Well, I finally got around to implementing our new rule based layer standards. Here what I decided on:

<div style="margin-left: 40px;">00_AXIS - Finds all features that have axes, except mirrors or copy geoms
</div><div style="margin-left: 40px;">00_COORD-SYS - Finds all coordinate system features
00_CURVE - Finds all datum curve features
00_IMPORT - Finds all copy geom, external copy geom or import features
00_MIRROR - Finds all mirror features
00_NOTE - Finds all 3D notes
00_PLANE - Finds all datum plane features
00_POINT - Finds all datum point features
00_SURF - Finds all features that have quilts, except mirrors or copy geoms
</div>
I created mapkeys that will strip all layers from a part or assy and add in these new layers. I also created a mapkey that will strip our old default layers only and add in these new layers. I created a new "Layers" drop down menu with these mapkeys in it as well as shortcuts to the hide and isolate commands to make them easier to find.

I prefixed our standard mapkeys to keep them grouped together and easier to find. it also means I can more easily grab our defaults amoung a bunch of mapkeys and extend those rules through the assembly.

I've made a cheat sheet for my users with the layer list and some crutial instructions like using isolate instead of unhide and only putting features on layers as well as other tips like leaving the datum toggles on, leaving these layers hidden and creating custom layers for grouping like features for fine visibility control.

I have some ideas for mapkeys to make creating those layers easier, but I've spent enough time on this for now. We'll see what kind of grumbling I get with the new rule based layers for now.

 

[Zestje]

First of all, thank yo uall for this most useful topic! It helped a great deal in understanding layers, but I'm having a problem:

I'm currently updating my start parts and configs for better layer handling. At present I (still) have a start part with layers but without any rules.
In the config.pro def_layer rules are set, but no part for default layer rules is set.

The first 3 layers only contain the default datums (1 CS, 3 planes and 3 axes) from the start part and should -not- get anything else assigned to them!
From layer 4 and onwards I have rules to add items to those layers.
However while testing adding external copygeometry with datums I noticed that the datum entities are added to those first 3 layers! These are so-called 'simple layers' -without- rules set and -without- def_layer settings. How can this be

!?
See picture:

View attachment 4648

When creating other types of features in the part the entities are
handled correctly and are not assigned to these layers. BTW these 3
layers have 'rules enabled' and 'independent' set active. Deactivating
'rules enabled' makes no difference.


I'm really confused here...
What am I misunderstanding here.

 

[gkbeer]

The def_layer options in your config.pro are, most likely, the cause of items landing on layers, where rules have not been set.

Def_layer options may be set in the loadpoint config.pro. Check that. You can override those by adding def_layer options, to your personal config.pro, without specifying the destination layer.

EXAMPLE: def_layer curves <no layer specified here>
-----
The items you show in the layer tree are a combination of features and geometric entities.
The geometric entities are the ones with the point/axis/datum icon. Those are also the ones with the colon in the notation curve:F8(extcopygeom).



Edited by: gkbeer

 

[Zestje]

@gkbeer: Thank you for the reply.

I was already using an empty config.pro and also checked the loadpoint dirs.
The features in the tree are from the part itself and belong there, the entities are from the external copygeometry and don't bleong there. I just tried the same on another PC and the problem did not occur.

I guess I must have overlooked a def_layer setting somewhere, which is still active and causes the problem. Back to the search it is then ...

UPDATE: I just found the cause. The rules are working correctly. The reason the entitiesshow up, is because they were on a layer with the same name in the referenced part. Therefor ProE automatically also put them on the same layer they come from. I found out because I renamed some layers to test exactly this...

Now I have to see if there's a way to turn off this behaviour, since I do not want this kind off assignment for 2 reasons: It creates entities on layers, which I try to avoid as much as possible, to keep the layer display status easier to understand for all users. Also it could cause items to be added to the 3 layers for default datums, which I never want.



Edited by: Zestje

 

[dgs]

Keep it for now and play with it. I've found some advantage to that behavior in that it allows you to control the display of items in a copy geometry feature independently. You also need a layer for copy geom features. Then, you can isolate the 'planes' layer and hide the 'copy geom' layer and only get the native part planes.

It's not without bugs, but it's not necessarily bad either.