Layers and imported models

[ehill]

As more and more vendors make IGES/STEP models of their products available for download, more and more of the library models our users are creating are just imported geometry. One aspect of this that is causing me pain is the crazy number of layers that Pro/E makes when importing neutral files. I am not sure if this is something Pro/E decides to do on its own, or whether they are embedded in the neutral file. Does anyone know how to prevent Pro/E from making any newlayers when importing geometry?

---

Eric Hill

---

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[HugoHermans]

I'm afraid STEP/IGES brings the layers from the source model along. This indeed is a PITA. Generally speaking, importing models demands some discipline, not only because of the layers.

Regards, Hugo.

<< ProE WF5 - PDMLink 9.1 M060>>

[BrentDrysdale]

Missed the original but Layers in ProE have always quite a bit of effort to
get working well and this generally means that when something new intrudes
such as imported STEP things get messy.

I know some stuff now and everything I learned started with Glenn Beer and
his Layers Presentation at the 2007 Conference. Subsequently
Doug Schaefer has developed information too. The original Help is useless
unless you already know what to do in which case there is some info. From
what I have seen Layers are not even taught well. Have not looked at
learning connector and PTCU though so maybe things have improved.

In short:

- Old ProE trained people to use the *def-layer*.... in a config.pro to
assign features and enties to Layers as they were made. It works, sort of.
In WF this got broken with the consolidation of tools such as Extrude and
VSS. Each of these can make solid or surface and def_layer cannot handle
changing between if you redefine.
- More latterly using *Layer Rules* has seemed to be the Holy Grail.
With this approach it looks at what is in the model even if it is already
made so is great for having Layers accurately represent what is in them.
We are not there yet as even after years I still have not had time to nut
it out properly and implement it here. I do have great mapkeys from both
Glenn and Doug that can reset Layers for a model or assembly though. Both
of them have mapkeys that remove all existing layers and recreate all
layers with rules.

So it is the last bit that pretty much solves your problems if you are
using Layer Rules. If you are using def_layer.. then best of luck.

If either Glenn or Doug respond you will be getting the good oil



Regards,

*Brent Drysdale*
*Senior Design Engineer*
Tait Communications

[kimndave9]

Agree.

Rules are terrific. Change some attribute of an item and it will be
moved to a representative layer automatically. My favorite was to take
all the small items and exclude them from an assembly simplified rep
when I was just working the overall assembly. It would remove 90% of the
complexity outright.

I've attached the WF5/Creo elements layer function tree and rule
function tree to show available functionality.

Link to Glenn Beer's presentation->

[dgschaefer]

Yeah, I've put a lot of effort into better using layers here. I even gave a presentation at NOPUG last year on what I learned [1] (borrowing heavily from Glenn's original 2007 presentation). I bet I spent my a month of down time tweaking our layers here and revamping them and I'm probably to the point where I can control the display of 90-95% of the items on screen. That last 5-10% is painful, however.

I've not yet done anything to bring all that work into Creo, and frankly, I'm not sure that I'll bother. What I've realized is that probably 90% of our work is using customer generated template parts and config.pro settings, so none of that layer work comes along. Some clients are more tolerant of us generating our own rule based layers than others. So mostly we live in other people's systems.

Even bigger, however, is that they are simply far too complicated to be used by a group. I find that most users are happy using the hide command and the global display toggles for planes, points, etc. I want that fine control and while others might express it, trying to explain to them the nuances of rule based layers & the difference between hide, unhide & isolate was too much. They'd simply rather deal with the cluttered screen.

Frankly, this is an area that could use some attention from PTC. There are several problems with the current system of controlling display of items.


1. There are 3 different systems that can change the display of items, datum display toggles, hide & unhide in the model tree and layers. They overlap and interfere with each other and none is absolutely comprehensive. Changing one interferes with the effectiveness of the other. A consolidated system that worked consistently would be very helpful.
2. Too many 'layerable' types. Pro/E distinguishes between an axis feature and an axis entity within the feature. Why? Users don't, they just see an axis and they don't want to think about it.
3. Three layer display states (isolate, hide, unhide) but only hide & unhide are prominent in the interface. I think the 3 states are valuable, but they need to be consistently displayed throughout the UI and easily understood.

What I'd like to see is an integrated item display system, built on layers, where I've got built in layers & corresponding toggle buttons for all 'layerable' items. If I toggle the planes button off, the built in 'planes' layer should become hidden. If I create another layer and place some planes on it and set it to 'isolate', those planes should come on even if the planes toggle is off. Make the existing 'hidden items' layer behave like any other layer rather than some 'super layer' like it does now.

PTC did a great job on the new measure tool in listening to our complaints and not only correcting it, but building a comprehensive measuring tool that delivers a lot of info with little effort. They now need to do the same with display.

Sorry for the rant, it's probably more than you bargained for. If read all the way to the end, now you've got to work through lunch to make up the lost time. 😛

[1] -

[dgschaefer]

I realized my big long rant had nothing to do with the question at hand. Oops.

I haven't found an easy way to deal with the garbage layers that come in with imported models. I've simply made it part of my import routine to delete them.

--

[DonSenchuk]

It can be a real mess. I've typically seen users just delete all layers then use ModelCheck to bring in and populate our default layers to the imported file.

In Reply to Eric Hill:

As more and more vendors make IGES/STEP models of their products available for download, more and more of the library models our users are creating are just imported geometry. One aspect of this that is causing me pain is the crazy number of layers that Pro/E makes when importing neutral files. I am not sure if this is something Pro/E decides to do on its own, or whether they are embedded in the neutral file. Does anyone know how to prevent Pro/E from making any newlayers when importing geometry?

[kimndave9]

On 1 - Layers and Hiding used to be separate, but they were
consolidated. Hide/Unhide were fast, transient selections (state could
not be saved.) Then Hide/Unhide got grafted into Layers, and became
persistent.

On 2 - The reason there are too many types is because they are making
available to the layer system all the detail one needs to do search
without leaving pieces out. The alternatives are to make certain pieces
unfindable or to create a separate search system just for visibility.

On 3 - Agreed. This is prevalent in the PTC interfaces; there is a lack
of situational awareness available through the interface.

There is also a lack of feedback on learning the interface. For example.
there is no method to flag those techniques used in a model that a user
has not used before, therefore alerting either the user or his
supervisor that some trouble may be ahead for the user. Ever run into a
user with 3000hrs of experience only to find out they've never done a
sweep, created a symbol, or experienced a relation? Pretty ugly when
they are supposed to modify a model and drawing that depends on all three.

Dave S.