Mastering Layers Q&A

[gkbeer]

I find your technique interesting, I'd never thought that the layers of
a submodel could be selected for use with the extend function. I've
only ever selected top level assembly layers prior to using extend.

Ok, I just tried it in WF2, it didn't work. What did work was taking the assembly that had been cleared of layers, and adding it to a new empty assembly created from the start assy, having rule based layers predefined, selecting those layers and then using the extend function.

I hate to ask but, on the occasions where there was success, by any chance were top assembly layers being selected for extension, with the mis-perception being that they were part layers?

There isn't much to know about the Extend rules function. Preselect an assembly layer having rules and hit extend rules. It's pretty safe, layers are only created in models where that layer name does not already exist. Where such layers exist you get a message like "...cannot be created...". No harm, no foul.

I wonder, when the error "black hole cannot be..." was the layer Hidden Items among those selected for extension?

===========

It's my understanding that .black_hole layer was how WF1 (or was that 2001) implemented the hide/show function found in the model tree. This layer being created behind the scenes, and never shown in the layer tree. I also recall reading that such layers can be found and dealt with via toolkit calls.

WF1 had a lot of "interesting" layer functionality. One thing that could be done, using rules, was to cause every plane in every submodel to be placed directly onto an assy layer. Before you knew it you could have 10,000 items on an assembly layer. Very not good for performance.

Edited by: gkbeer

 

[dgs]

It's pretty safe, layers are only created in models where that layer name does not already exist. Where such layers exist you get a message like "...cannot be created...". No harm, no foul.

Glenn - I just tried this in WF3 and found that if the layers exist, Pro|E will add the rules to the existing layer. I found that to be very helpful. Maybe this changed from WF2 -> WF3?

It's my understanding that .black_hole layer was how WF1 (or was that 2001) implemented the hide/show function found in the model tree. This layer being created behind the scenes, and never shown in the layer tree.

It was in 2001. I remember occasionally seeing the BLACK_HOLE layer in the layer tree. It would appear at random, inconsistently. I assumed it had something to do with he show/hide functionality, but I wasn't sure. I also assumed that i wasn't supposed to be able to see it. It never got in my way, so I ignored it.

 

[eholmes124]

I find your technique interesting


It seemed logical at the time. Since we have quite a few projects that would benefit from this improved layer management, I want to make it is relatively painless for our group. In additionwe haven't updated our start.asm but I will investigate.


I hate to ask but, on the occasions where there was success, by any chance were top assembly layers being selected for extension, with the mis-perception being that they were part layers?


All the layers in the assembly including all parts had the layers deleted before I inserted the part w/ the rule layers.I started testing with a relatively small sub-assembly with a mix of parts that I created as well as some from suppliers (McMaster, OEM vendors, etc) We use family tables for ourhardware so I made sure to delete these prior to testing. We have discussed updating the hardware libraries but only after we've tested things thouroughly.


I wonder, when the error "black hole cannot be..." was the layer Hidden Items among those selected for extension?


I don't recall ifthere was a hidden item layerinitially but I believe so. After each test Ierased all files from the session to make sure I started fresh and tried different selection methods. (i.e. All layers, All except Hidden layer, Individual layers) I also had another user in our group try it out and the same thing happened. The first time or two it worked and then he hit the wall like I did.


I will use the WF2 Insert into Assembly method and provide an update, I'm sure it will work fine. When/if I hear anything from PTC regarding the SPR I will make sure to post that information as well.


Thanks for the feedback.
Edited by: eholmes124

 

[gkbeer]

I haven't stress tested WF3 yet using large assemblies. I do know that the WF2 problems involving instances, and assembly cuts have been solved.

The technique of adding a model to an assembly having the desired layers for the purpose of extending the rules to submodels is one that works and is easily communicated, and works well if an entire product structure is to be cleaned up at once, but a set of mapkeys that will insert the layers on command is so very speedy to use.

(Ha! me saying that I really dislike making and maintaining mapkeys.)<br style="font-style: italic;">

 

[gkbeer]

New Tip: (new to me)


Using RMB>Hide followed by Save Layer Status, makes the
items on the Hidden Items layer remain hidden after the next
save and retrieval.

Reversing that requires, unhiding the items and again saving the layer status.

 

[eholmes124]

UPDATE:


I have completed a project conversion using a ruled layer assembly file.


I created a Layer_Convert.asm with the rules from the start.prt and also created anew start.asm fileas well.The Layer_Convert.asm contains layers from the start.prt and two additional layers from the start.asm. The start.asmonly containsthe DEF_ASSY_CSYS and DEF_ASSY_PLANESlayers w/ subsequent rules.


Ideleted all the layers in the project assembly > saved the assembly > inserted the assembly into the Layer_Convert.asm > and extended the rules for the part specific layers only.


I then went through the sub-assemblies in the project assembly and suppressed individual parts/ rolled back the model tree and saved so only empty assembly files were in session.Within theLayer_Convert.asm I then extended the assembly specific layers. Mythinking for this approach was to provide control of the part layers as well as the sub-assembly layers. This should prove to be very usefulsince we outsource a variety of equipment.


One thing I found interesting after verifying that all the individual part andassembly files hadthe correct ruled layerswas the reduction in file size.


I backed up the project to a local directory just in case something out of the ordinary happend(i.e. CRASH) After the conversion the directory contained 178 filestotaling 5.1Gb while the pre-conversion directory size totaled 6.3Gb. Ianticipatedthat the multitude of layers removed would reduce file size to some extent but not a 20% decrease. I then tested the converted assembly by hiding some layers and backing up with little effect on file size.


We plan on doing additional testing to correlate the effects of simplified layering and file size. If reducing/simplifying the layers does impact file size significantly not only will the designgroup benefit butthe IT group will be ecstatic.


Just curious to see if anyone else had noticed this effect.

 

[gkbeer]

Just a few unsolicited comments on your setup.

There seems to be a lot of work involved in having def_assy_planes and def_part_planes in the relevant type models.

I recommend for the default layers (AXIS PLANES THREADS CSYS...), that the same layer names be used for both assemblies and parts. I.E def_planes.

It might seem to be a loss, not being able to single out, def_assy_planes, but it will uncomplicate your procedure. This will make it an easier sell to others. Believe me, easy, uncomplicated, low interaction for the levels for the benefit gained - well, people put up with a lot of change for a benefit that large.

If you have specific reservations about using the same layer names for parts and assemblies, just lay them out. I'm sure I can point out ways to accomplish the same task even without the different layer names.

While I'm on the topic of layer names, I'll also recommend not having any name starting with def_ when there is another layer named the same, but not prefixed with def_.

Such layers don't provide a benefit worth their cost. The space they occupy in the layer tree, the additional file space needed, or the RAM and CPU cycles consumed.

 

[verge]

Well, this is off your specific topic, but thought I'd weigh in again, as I started this discussion by tracking Glenn down a while ago.


I have a different position now than I did when this discussion started, and I don't use Pro-E nearly as much as I did then. I work with other people's assemblies constantly now, just short projects changing components here and there, small redesigns, etc. I've found that it's always worth the time it takes to delete all existing layers (it's a mess every time, too, what a waste!) and use Glenn's technique to create my own.


I've found that I can create the layers I actually need for these short projects within five to ten minutes (including the time it takes to delete the initial layers). The ease and efficiency these layers add to my work make it way more than worth my while. I am working on teaching this technique to others I work with.


Thanks again to Glenn and Doug for all of your help. I'm still following this thread when I have a chance. Keep up the good work.

 

[sip]

Hi verge,


Can you point at the page where Glenn's technique is hiding? We're at 9 pages for this thread.


Thanks,


Sip

 

[dgs]

Back on page 1, Glenn attached his presentation on layers from the 2007 PTC|User conference. It's in his first post.

 

[verge]

Sip,


I dug a little to find this in a previous thread mentioned on page 1 of this one (Sorting Out Layers). This is the basis of the technique. Enjoy.
<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid" ="gmail_quote">
<DIV>


Using find to create layers.</DIV></BLOCKQUOTE>
<DIV>This is best done at the top model of and assembly you need to clean up.

<DIV style="MARGIN-LEFT: 40px">Use the find dialog and create a search that finds all the items that you would have placed on a layer. That might be all features that are of the type datum plane. When your search terms work as desired, go to the pull down labeled "Options" and choose "Save Query" (Who would ever know that this creates a layer). When the Save Rules dialog opens, enter the name of the layer you want created. DO NOT check the Propagate Layer box. Hit OK. Now go to the layer and examine it's properties and options. They will be set to best effect.
</DIV></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid" ="gmail_quote">
<DIV>


Using the extend function to create layers, with rules, recursively. </DIV></BLOCKQUOTE>
<DIV>This only works from the assembly level.

<DIV style="MARGIN-LEFT: 40px">In the layer tree, highlight the layer just created. (There is no point is doing this if the layer has no rules.) At the top of the layer tree there is a dropdown called "LAYERS" Select it and choose "EXTEND LAYERS". The highlighted layer will be created in all submodels of the product structure, except for those model that have a layer by that name. They are skipped. You can select more than one layer at a time.

From your email it sounds like you already have a well regulated top assembly with the rule driven layers you want. You could simply open the offending subassy, delete all the layers, go back to your top level assembly, set the layer tree to show only the top level layers, select them, and extend them.
</DIV></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid" ="gmail_quote">
<DIV>


Searching for items in the layer tree. </DIV></BLOCKQUOTE>
<DIV>In the layer tree, select the SHOW drop down and select FIND then SEARCH. This can be useful for finding layers by name, which is useful when creating mapkeys that need to select a specific layer instead of the layer and nodeX. I highly recommend exploration and testing, it's worth a few lunch hours. </DIV>




<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid" ="gmail_quote">
<DIV>


Using the selector to manipulate the layer tree. </DIV></BLOCKQUOTE>
<DIV>The selector. It's that arrow to the left of the SHOW drop button. Click on the arrow and then select any part or subassy in your assembly. The layer tree will focus on that part showing only the part layers. You can now easily change the layer status's for only that part. This also allows you to set the layer status for that part you are trying to assemble (the one that was correctly saved with all it's layers blanked). Chose the chooser pick on the model being assembled and set its layers as needed.
</DIV>
<BLOCKQUOTE style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid" ="gmail_quote">
<DIV>


How to distinguish between entities and features. </DIV></BLOCKQUOTE>
<DIV>I think I was clear that entities are the geometric items that make up features. What many don't realize is that when trying to select items to be put on layers, query select will allow you to pick an entity instead of the feature.


<DIV style="MARGIN-LEFT: 40px">Try this. In a new part that has only the default datums and no layers.
Create a layer called FEATURE.
Manually add a datum plane by selecting it in the model tree.
Create a second layer called ENTITY.
Add the same datum plane to it EXCEPT don't pick it from the model tree. In the lower left corner change the selection filter from SMART to GEOMETRY, then graphically select the same datum plane. Close the layer creation dialog.

Now. in the model tree, expand both layers to show their contents.
Note the icons are different for features and entities. Features typically have the same icon shown in the model tree. Entities have a different icon, the entities that make up datum features typically have a point/axis/plane like icon.

Now, look at the text. There is a clear difference between the feature and the entity. Entities always have a segmented notation (There is a colon in the text), features never have that. The segmented notation is the most reliable way to tell if the layer item is a feature or entity.

I recommend putting features on layers instead of entities. There are good reasons to put entities on layers and I'm sure you will recognize the need when it occasions.
</DIV>
It's most important to be able to make the distinction between features and entities, because layer status combined with Proe's basic rules about how invisibility is applied, has been a major cause of confusion for a long time.
</DIV>

 

[thomasqg]

Hi folks. I'm having trouble setting up my start models with the layer functionality I want. What I want is for a parts to have layers named 01___PRT_DTM_PLN, 02___PRT_AXIS, etc, and assembliesto have all ofthe part layers pluslayers 01__ASM_DTM_PLN, 01_ALL_DTM_PLN, 02__ASM_AXIS, 02_ALL_AXIS, etc. The idea is to have an indented structure and to be able to turn on/off part layers, assembly layers, or both with a single layer pick. Unfortunately, I can't figure out how to get the 01_ALL_DTM_PLN type layer to work. I've tried "including" the 01__ASM_DTM_PLN and 01___PRT_DTM_PLN layers in the layer properties, but doing so only results in the 01___PRT_DTM_PLN layer in the assembly, not the one from the part,being affected by the layer. I've also tried creating a rule that adds all datum planes with the "Include Submodels" button selected, but that gives me the following error "Rules cannot be evaluated for submodels of a Layer model." and doesn't include the layer from the part. I've tried setting the config option Add_lower_level_comps_to_layer to "yes" but it still doesn't work.


Is it possible to achieve the functionality I'm looking for? If so, how?


Thanks everyone!


Tom

 

[thomasqg]

Another layer question: Is it possible to create a rule that will add only GTOL type datum planes to a layer? I find it very annoying that they don't obey the datum planedisplay setting but there doesn't seem to be an automated way to add them to layers.


Thanks again!


Tom

 

[eholmes124]

I just went throughsomething similiarand found that creating ruled layersto extend toparts and separate ruled layersto extend toassemblies was the simpliest way to go, not ideal by any means but it works for us.


The partspecific layer rules look for the default TOP/FRONT/RIGHT planes. The rule search uses DATUM in theLOOK FOR and LOOK BYfields and uses the NAMEattribute option. The assembly specific layer rules look for the default ASM_TOP/ASM_FRONT/ASM_RIGHT datums in the same manner. I used this approach for the CSYS's as well.


you can refer to my previous post on how I extended the rules for parts and sub-assemblies separately.


In response to your GTOL datums question.I encountered this same issue and set up the rule to use the datum plane option in the LOOK FOR and LOOK BY fields and set up the "is equal to" condition for letters A through Z. We also include AXIS features in with this same method (A through Z). However this is only part of the equation.


In addition to the GTOL PLANES layer you need to incorporate a catch all PLANES layer. The rules for this layer will search for all the remaining datum planes. The rule(s) I created used Datum Plane in the LOOK FOR and LOOK BY fields and set up the "not equal to" condition for letters A through Z as well as the previously defined TOP/FRONT/RIGHT planes inthe part and assembly files


This does get a little involved but it is worth the effort to segregate datums and geometric entities


Thetrial and error method seems to be the only way to create rules that behave the way you want. We also work with another group that creates more organic geometry (ISDX)and they use techniquesthatIdon't.So I had to test extensively to ensure I captured all the possible scenarios. If I have 80% of them covered now that's great. I'm sure I'll be finding more in the weeks to come.


Hope this helps.

 

[thomasqg]

So it sounds like I can't quite get what I want by building it in to the start parts. Any idea why the "include submodel" option doesn't work?


As far as the gtol datums go, I will use your technique. The only down side is if someone creates a normal datum plane and gives it a single letter name, but that's probably pretty rare.


Thanks a bunch...this is very helpful.


Tom

 

[thomasqg]

Oops...should have tried it first. How do you set the condition "A through Z?"


Thanks,


Tom

 

[thomasqg]

I can do it by creating 26 rules...one for each letter, but is there an easier way?


Found another problem. If I try to create a layer for GTOL axes and create a rule that looks for axis, looks by axis, name = A, B, etc, I get the following error: Rule(s) is not supported by layer." What's up with that? I get the same error if I do a look for axis, look by axis, all entities.


This is getting ugly.


Tom

 

[dgs]

I've not done this, but I think Glenn uses a ? wildcard to represent a single character feature name. Then you don't need a rule foreach letter of the alphabet. This will pick up panes with a single letter or number name that aren't GTOLs as well, however.

 

[thomasqg]

Yeah, I was trying to avoid using that because it will grab numbers too, but it may be worth it to avoid putting in 26 rules into all 4 start models.


Thanks!


Tom

 

[gkbeer]

I've not done this, but I think Glenn uses a ? wildcard to represent a single character feature name. Then you don't need a rule foreach letter of the alphabet. This will pick up panes with a single letter or number name that aren't GTOLs as well, however.

Busy thread today.
I do indeed use the wildcard ? for set datum planes, and axis.
And yes, the numbers 0-9 would also be included, if I ever used them as names. I would suggest that if items are being numbered that they be numbered 01,02,03... or even 001,002,003... avoiding 1,2,3... This is actually a good thing, as those names will sort properly in any listing that allows sorts, as opposed to 1,10,2,20,3,30...

It's very desirable to have as lean of a set of layer rules as can be managed.
It may not seem to be a problem when dealing with individual parts or with small assemblies, but trust me, having a lot of rules will really eat up the cpu time when the assembly size gets large. It sneaks up on you quietly, until one day you are wondering why your computer is so slow.
I have 9 layers that I create by default. Each has only 1 rule.
The same layers and rules are used for both parts and assemblies. (axis,axis_tags,csys,curves,gtol,notes,set_datums,planes,thr eads)
Other layers are created as necessary to serve specific needs.

By default I keep all those layers hidden. At any given time the layers from only 2 or 3 models are set to isolate.