Mastering Layers Q&A

[dgs]

I think you'd be better off posting that in it's own thread. You might get more attention from mapkey experts.

You can edit a mapkey by opening the config file in a text editor, but as you've discovered, it's a little hard to decipher.

 

[verge]

Definitely start a new thread. I want to know the answer! Could you reply to this thread with the location of the new thread?

 

[handyman2000]

Per the request I have posted a new topic about mapkeys and layers. I hope there is a better way to edit mapkeys that recreating the entire process everytime.

http://www.mcadcentral.com/proe/forum/forum_posts.asp?TID=39 198&PN=1&TPN=1

 

[dgs]

OK, after being away from this for a year or more, I'm returning to try to implement something that makes sense. Playing with rule, it seems that for points and Axes, having features on layers doesn't seem to make sense.

For example, if I search for features by axis, I get all features with an axis. That might be an actual datum axis feature, or it might be an extruded quilt with an axis point or a revolved quilt or a hole feature with a thread. For the last three, putting the feature on the axis layer means that the quilt will be there as well (as a part of the feature). If I understand the invisibility rule right, if the axis layer is invisible, there will be no way to make the quilt visible, right?

Points can be the same as there are some features (sheetmetal in particular) that create points. Not to mention that a single point feature can have dozens of points in it.

So it makes sense to control these well, I should put the aces and points themselves on the layers rather than the feature containing them, right?

I don't think this applies to planes, although it may to coordinate systems.

 

[dgs]

OK, another question. Cross section planes are (usually, I've seen this fail) auto placed on a layer at creation. If I use a mapkey to delete all layers and then add in new rule based layers, these cross section datum layers will be lost.

So, how can I find all the cross section planes using the find tool?

 

[dgs]

I'm having some real difficulty with my copy geoms and would like some insight.

If I create a curves layer like this:

<div style="margin-left: 40px;">for feature
by 3D curve
history = all
</div>
I'll get all curve features, but it also picks up copy geom features, if they have curves in them. Finding planes liek this:

<div style="margin-left: 40px;">for feature

by datum plane
name = *
</div>
Picks up copy geom features with planes too.

The issue is that isolating the 'planes' or 'curves' layer also makes the copy geom feature visible. So, by trying to show planes you might see copy geom surfaces and curves too.

Is there a cleaner way to handle assys with copy geoms? Should I set up my curves, planes, etc layers to exclude copy geom features?

 

[gkbeer]

Congrat's Doug, You are getting into the deep end of the pool.

I've always said "Stick with putting features on layers, UNTIL you figure out why putting entities on layer is useful."

Feature axis vs. datum axis.


All features contain geometeric entities. Datums, Solids, Copy Geoms...


Most all geometric entities can be put on layers in addtion to the features that contains them. Feature axis are an exception.

PTC needs to make some changes here. Feature axis need to be selectable as layer items, separate from the feature containing them. In Tampa, PTC demoed a WF3 version that allowed this. It didn't make it into production. The word from the hotline was that the change was considered too much of a break for the installed base to accept.

You are correct about the visibility problem of putting surface features with axis onto layers. PTC knows how to fix this, have already done the work, they just need to know we want it.



Edited by: gkbeer

 

[gkbeer]

Points can be the same as there are some features (sheetmetal in particular) that create points. Not to mention that a single point feature can have dozens of points in it.

So it makes sense to control these well, I should put the aces and points themselves on the layers rather than the feature containing them, right?

I don't think this applies to planes, although it may to coordinate systems.

You understand this well. What applies to points also applies to all datum feature types including planes.

Features vs. entities on layers? If you need to control the visibility of one point in a datum feature that contains many, You will have to put entities on layers. That doesn't necessarily mean leaving features off of layers.

For instance a datum point feature with 10 points in it.
Put the feature on one layer.
Put the feature and points 1-5 on a second layer.
Put the feature and points 6-10 on a third layer.
Put just the points on a fourth layer.

Hide all the layers, then Isolate the layers singly, then in combinations. Don't forget to consider how the visibility rule applies.

The alternative is to never put a feature on a layer, And to convince everyone else you work with that they should never do so either. That has drawbacks too.

 

[gkbeer]

I'm having some real difficulty with my copy geoms and would like some insight.

If I create a curves layer like this:

<div style="margin-left: 40px;">for feature
by 3D curve
history = all
</div>
I'll get all curve features, but it also picks up copy geom features, if they have curves in them. Finding planes liek this:

<div style="margin-left: 40px;">for feature

by datum plane
name = *
</div>
Picks up copy geom features with planes too.

The issue is that isolating the 'planes' or 'curves' layer also makes the copy geom feature visible. So, by trying to show planes you might see copy geom surfaces and curves too.

Is there a cleaner way to handle assys with copy geoms? Should I set up my curves, planes, etc layers to exclude copy geom features?

Most of my layers are setup to select features by type instead of by content. I search for features of the type datum plane, and not for features that contain datum planes. So copy geoms and their entities are excluded by default.

My use of copy geoms is light.
Most of the time I want the copy geom stuff visible separate from the default layers, so it or its geometry goes onto uniquely configured layers. I do that manually. YMMV.

 

[dgs]

We use copy geoms pretty extensively here, so dealing with them is important.

My goal here is to have a simple default layer system that's easy to understand and use and that allows predictable use of additional layers to control the visibility of specific sets of items as the user desires. Part of that means knowing, when a user places an item on a layer by picking on screen, are they going to get features or entities?

My user base, and I suspect this is true most places, doesn't make effective use of layers now. In fact, they don't use layers much at all. Getting them to understand the nuances of features vs. entities isn't going to happen, so I want to develop a default set that allows for some ignorance, if you will, of those nuances but still allows better use of layers than we have now.

So, if I hide things on layers at the feature level and the user tends to put entities on layers, they won't be successful in getting their specific layers to work. The invisibility rule kicks in, thwarting their progress. Explaining to them the difference between grabbing features vs. entities isn't really going to help. They don't care, and don't need to really, they just want to be able to layer things off and on simply, and I want to be able to provide that to them.

Maybe my answer is to always put entities on my default layers. That way, regardless if my users put features or entities on a layer, they should (mostly) work predictably.

Thoughts on this approach? What gotchas am I missing?

 

[dgs]

Feature axis vs. datum axis.


All features contain geometeric entities. Datums, Solids, Copy Geoms...


Most all geometric entities can be put on layers in addtion to the features that contains them. Feature axis are an exception.

PTC needs to make some changes here. Feature axis need to be selectable as layer items, separate from the feature containing them. In Tampa, PTC demoed a WF3 version that allowed this. It didn't make it into production.

I'm not sure I understand what you are getting at here. In my install of WF3 (M170), I can gather axes in 3 ways;

<div style="margin-left: 40px;">for feature
by axis
name = *

</div>That gets all features that contain axis entities.


<div style="margin-left: 40px;">for feature

by feature

type = datum axis



</div>
That gets all features that are datum axis features.



<div style="margin-left: 40px;">for axis

by axis

name = *



</div>

That gets all axis entities, or at least it seems to.

Is this different than what you're seeing?

 

[dgs]

OK, another question. How do curve loops and curve segments figure in?

For example, if I have a curve that's a sketched circle. I create a new layer and then while in the layer properties I set my filter (lower right of the main Pro|E window) to 'curve'. I then drag a box over my model and the sketched curve (circle) highlights. I see 3 items in the layer properties dialog. Half one of the circle, half two of the circle and the complete loop. If my curve was a rectangle, I'd have 5 items, 4 sides and the loop. The feature itself is not added, only entities but one entity is a loop of multiple segments.

It turns out that the loop is another entity type. If the loop is hidden, the invisibility rule applies to the individual entities, making them unable to be shown.

Unfortunately, searching for 3D Curve, by 3D Curve results in the same thing, loops and individual segments get found.

Argh.

 

[dgs]

I think I'm about to give up (in fact, I may have already decided to). There's no way I can make this simple for my users, it's too convoluted and there are too many exceptions to the rules. Curves in particular, which we really need to be able to control better, are simply impossible.

I've found that a composite curve (copied curve) follows the invisibility of it's parent. I have a projected curve which I've made a composite copy of. If the composite is on one layer and the parent projected is on another, I cannot hide the parent layer and isolate the child. This is a simple parent child relationship, not a hierarchical one, but that's how it behaves.

Glenn, what you've learned about layers is great for a power user to use on his own, but PTC's implementation is simply too convoluted, too inconsistent and too poorly documented to be implemented across an organization.

Once again, PTC's poor and incomplete implementation prevents using the softwre to it's fullest.

I'd love someone to convince me otherwise, but I keep finding roadblock after roadblock to implementing a logical, predictable layering scheme.

EDIT: I was wrong, the copied curve isn't dependent on it's parent, but it doesn't follow the invisibility rule either. You must have both the feature and the entities on the same layer in order to control the copied curve's display reliably. Putting the entities on one layer and hiding it, and the feature on another and isolating it doesn't work. The isolated layer needs both the feature and the entities placed there. Better than I thought, but still an unworkable solution.

Edited by: dgs

 

[gkbeer]

Feature axis vs. datum axis.


All features contain geometeric entities. Datums, Solids, Copy Geoms...


Most all geometric entities can be put on layers in addtion to the features that contains them. Feature axis are an exception.

PTC needs to make some changes here. Feature axis need to be selectable as layer items, separate from the feature containing them. In Tampa, PTC demoed a WF3 version that allowed this. It didn't make it into production.

I'm not sure I understand what you are getting at here. In my install of WF3 (M170), I can gather axes in 3 ways;

<div style="margin-left: 40px;">for feature
by axis
name = *

</div>That gets all features that contain axis entities.


<div style="margin-left: 40px;">for feature

by feature

type = datum axis



</div>
That gets all features that are datum axis features.



<div style="margin-left: 40px;">for axis

by axis

name = *



</div>

That gets all axis entities, or at least it seems to.

Is this different than what you're seeing?

Those three will yield different results.
If my memory holds true...

The first collects features containing axis. datum axis features, holes, some extrusions, revolves, copy geoms containing axis...

The second looks for a specific type of feature, a datum axis feature.

The third collects only geometric entities (portions of features, like a single point in a multi point datum point feature, or a single segment of a sketched curve feature, or a quilt having an axis as in a threaded hole) You will not find any feature on a layer with this type of rule. In this case only the portion of a feature that is itself an axis. Unfortunately quilts with axis are handled inconsistently.

The difference is wither features or entities are being selected. This is important because of how the basic visibility rule can complicate layer item visibility.

Humm! I think what we need to discuss now isn't necessarily rules, but layer strategy. Layer rules implement strategy, but if chosen poorly can also constrain strategy.

Strategy is best determined by a couple questions:
"How can I keep it simple?"
"What do you want the layers to do, or not do, for you?"

A layer strategy also has to be easy to understand. Few people will adopt a strategy if, they have to work hard to understand it.

I consider it important to my layer strategy to avoid creating situations where the basic visibility rule will override the visibility of items on Isolated layers. I keep away from using default layers and rules where isolating a layer will fail to cause all items on that layer to be visible. The issue is that even knowing how the basic visibility rule has impact, It's always a surprise to isolate a layer and not see something that you expect to be there.

Fewer rules per layer is better than more. I've seen some examples on the web < id="message" src="RTE_text.asp?mode=quote&POID=170311&ID=280" ="hideColourPallete()" width="490" height="200">where people make separate layers for assembly datums, part datums, set datums, set assy datums.... and then they have a complex set of rules on each layer aimed at individualy excludeing all but the desired items. That usually indicates a lack of training in how to get the most from the layer tree and layer status's. Another sign of poor strategy is when multiple layers have to be set in a particular way to achive a result. Only the individual that setup that mess is going to know how it works.

That's where I'm going to stop tonight.

Edited by: gkbeer

 

[gkbeer]

I think I'm about to give up (in fact, I may have already decided to). There's no way I can make this simple for my users, it's too convoluted and there are too many exceptions to the rules. Curves in particular, which we really need to be able to control better, are simply impossible.

I've found that a composite curve (copied curve) follows the invisibility of it's parent. I have a projected curve which I've made a composite copy of. If the composite is on one layer and the parent projected is on another, I cannot hide the parent layer and isolate the child. This is a simple parent child relationship, not a hierarchical one, but that's how it behaves.

Glenn, what you've learned about layers is great for a power user to use on his own, but PTC's implementation is simply too convoluted, too inconsistent and too poorly documented to be implemented across an organization.

Once again, PTC's poor and incomplete implementation prevents using the softwre to it's fullest.

I'd love someone to convince me otherwise, but I keep finding roadblock after roadblock to implementing a logical, predictable layering scheme.

EDIT: I was wrong, the copied curve isn't dependent on it's parent, but it doesn't follow the invisibility rule either. You must have both the feature and the entities on the same layer in order to control the copied curve's display reliably. Putting the entities on one layer and hiding it, and the feature on another and isolating it doesn't work. The isolated layer needs both the feature and the entities placed there. Better than I thought, but still an unworkable solution.

Doug I do hope you won't truly give up. This stuff really does work.

Re the edit,
This is why I go on and on about the difference between features and entities. If you never put a curve feature on a layer, only curve segments, then you should be able to put whatever curve segments you wish on whatever layers and use isolate. You did find the, most roebust way to deal with curves. When ever I want to put just a few curve segments on a single layer, I start by adding the feature then the segments.

With curves, Intent chains can cause additional problems. It wasn't a problem before WF as intent chains didn't exist then.

The basic visibility rule when applied to curve features is in the order of Feature> intent chain> individual segments. If an intent change is invisible all curve segments will be invisible.

A default layer for curves that grabs all entities (curve segments ) can also grab all intent chains.

Unfortunately, Depending of the layer rule, you can wind up collecting all the curve segments and the intent chains at the same time. When you look at the item list for that layer, there is no way to tell which item is the intent chain. In that situation If you have the layer items showing and query select to the intent chain, It should highlight in the layer tree.

Strategies:

The 80/20 rule applies to creating layer rules. For some things it's just not effective to build rules that cover every possible model element. I take that approach by sticking mostly to putting features on layers, and manually catching the rest. I take what I can get, and when I run into what I believe is software stupidity, I call the hotline an point it out. (That the axis of a tapped hole is tied to the quilt, but that the axis of a clear hole is tied to the drilled hole, comes to mind.)

P.S. While I tend to put features on layers by feature type, I do put all features that contains axis on the axis layer. And yes I do on occasion have to edit the axis layer to exclude some items that I prefere the layer rule hadn't collected. (Exclude item is something that can only be done from the layer properties dialog box. A removed item will be put back the next time the rule is evaluated, Excluded items are not. )

 

[dgs]

I'm not giving up yet. Once I go that rant out of my system I think I've about got a layer system that will work for us, but I've got other fish to fry this AM. I'll try to share this afternoon.

BTW - Intent chains were available in 2001, maybe earlier, via hidden config option.

It seems that curves are going to be problematic and I may decide to give up again later.

 

[verge]

Well, I'm learning a lot on my end still, even if I'm not incorporating it.


I was laughing the other day when I was telling one of my co-workers about dragging Glenn into this...there's no way he could have guessed it would last this long!


You should start your own website for this thread, Glenn.

 

[dgs]

OK, here's my thinking. I'm planning two sets of default layers, one for capturing datum items at the feature level, the other for capturing copy geometry items at the entity level. Here's the thought (names aren't set in stone):

00_COORD_SYS [FOR = Feature | BY = Feature | TYPE = Datum | Coodinate System]
00_CURVES [FOR = Feature | BY = Feature | TYPE = All | Curve]
00_PLANES [FOR = Feature | BY = Feature | TYPE = Datum | Datum Plane]
00_POINTS [FOR = Feature | BY = Feature | TYPE = Datum | Datum Point]

01_COPYGEOM_COORD_SYS [FOR = Coordinate System | BY = Feature | TYPE = Data Sharing | Copy Geometry or External Copy Geometry]

01_COPYGEOM_CURVES [FOR = 3D Curve | BY = Feature | TYPE = TYPE = Data Sharing | Copy Geometry or External Copy Geometry]

01_COPYGEOM_PLANES [FOR = Datum Plane | BY = Feature | TYPE = TYPE = Data Sharing | Copy Geometry or External Copy Geometry]

01_COPYGEOM_POINTS [FOR = Point | BY = Feature | TYPE = TYPE = Data Sharing | Copy Geometry or External Copy Geometry]

I think this will sucessfully blank all planes, points, curves and coordinate systems in the model and allow predictable selective isolation of smaller sets of items, provided (and this is the biggie) the user puts features, not entites, on those other layers. It will also allow showing individual items in the copy geoms or keeping them turned off while showing other non-copy geom items.

Notice, no axis layers. Glenn's right, axes are problematic. I could do the same kind of thing, but axes for extrusions or hole features wouldn't get captured. Not sure what to do there. I'm leaning toward having no default axis layers at all. I also haven't yet figured out what to do with quilts. I'd love some input on those two, particularly quilts as we use them extensively and the ability to selectively turn them on and off is quite important.

Any thoughts or feedback?

 

[gkbeer]

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.


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

For most of my models the rule is 100% accurate. The false positive rate of putting unwanted features on the axis layer is less than 5% of the feature count, in less than 5% of the models. By accepting that, and manually exclude those few false positives, it helps a lot in keeping my layer counts and rule complexity down. YMMV.

 

[gkbeer]

Well, I'm learning a lot on my end still, even if I'm not incorporating it.


I was laughing the other day when I was telling one of my co-workers about dragging Glenn into this...there's no way he could have guessed it would last this long!


You should start your own website for this thread, Glenn.

It's done for entirely selfish reasons. If I can get the general skill level up on this, maybe I won't have to wade thru so much litter.

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