Layers vent

Can anyone explain to me why, after 23 releases of Pro Engineer,
something as simple as removing an entity like a datum plane from a
layer is still such a f***ing problem? Why can I still try it 3 or 4
different ways and the f***ing datum planes are still on their f***ing
layers? And it's not the first time in case you were
wondering...........

 

Here's another one. Maybe somone has an answer for this.

I have a master part with layers. In an assembly I merge (reference)
this part into a series of child parts. These parts get the same
layers with the same surfaces, curves, datum planes on them as per the
master part. Of course now these surfaces, curves, datum planes are
not now separate features but are part of feature #1, the merge. I
don't want the same level of complexity of layers in the child parts
but when I try to delete the bloody layers they pop up again later on.
Is there a config.pro setting that changes the associativity of layers
with the parent part?

 

: Here's another one. Maybe somone has an answer for this.
:
: I have a master part with layers. In an assembly I merge (reference)
: this part into a series of child parts. These parts get the same
: layers with the same surfaces, curves, datum planes on them as per the
: master part. Of course now these surfaces, curves, datum planes are
: not now separate features but are part of feature #1, the merge. I
: don't want the same level of complexity of layers in the child parts
: but when I try to delete the bloody layers they pop up again later on.
: Is there a config.pro setting that changes the associativity of layers
: with the parent part?

I was checking out config.pro to try to answer another post and decided to see
what I could 'find' on 'layer'. This one looks interesting, maybe worth a closer
look because it refers to an interface for selecting assemblies and layers. The
option is intf_in_layer_asm_dialog which might apply to reference parts in
assemblies as well as imported geometry.

David Janes

 

Not that it helps with your legacy parts, but other data sharing
features like ExtCopyGeom do not bring in the layers of the referenced
part.

- Wallace

 

I know, but I don't like that command, it's not really parametric IMO.

 

Here's another one.
I have several default layers. Someone else who was checking my work
on another computer has different default layers on their system. Now
every time I regen my assembly these bloody extra layers come up
again. I delete them and they keep reappearing. They are not set as
default layers on my config.pro and do not reference any common files.
How do i stop them from reappearing?

 

(Wallace White) wrote in message

IMO.

Hmm, I'm curious what you mean by that. Could you explain?

- Wallace


When you copy geometry, you can pick any group of surfaces, regardless
of how they're made or what feature they belong to. If your model
changes you often have to redefine the copy geom (in assembly mode) to
add the extra surfaces.

If, for example, you grab the surfaces of a round feature, and maybe
the edge changes and the number of surface pieces in the round
changes, then your copy geom ignores that extra bit of surface and you
wind up with a gap. At least, that's how I remember it. Maybe intent
surfaces can be used now in copy geom?

 

: Here's another one.
: I have several default layers. Someone else who was checking my work
: on another computer has different default layers on their system. Now
: every time I regen my assembly these bloody extra layers come up
: again. I delete them and they keep reappearing. They are not set as
: default layers on my config.pro and do not reference any common files.
: How do i stop them from reappearing?

Sounds like your company has Pro/MODELCHECK running in batch mode. It tries to
enforce certain rules about model construction, parameters, views, layers and a
bunch of other stuff. In particular, it adds/deletes layers, moves items to
layers, removes items duplicated on multiple layers. It does this unattended,
during off hours and goes through any changed files, often in conjunction with the
pdm system. If it were available for all users, you'd find it under
'Analysis>Model Check' and you could run your own check and get a report of what
doesn't match the criteria set up for checking and which it deems in need of
fixing. If they had but a single license and ran it in batch mode, you might never
even know they had Model Check.

There is no other functionality, within Pro/e or Intralink, which automatically
brings about the changes you're experiencing with layers. It is *not* normal
functioning for layers to resist deletion or undelete themselves. Also, other
people's def_layer setups in config.pro have no influence on files that were not
created on that host as the def_layer settings work *only* when a file is created.
It does *not* come along behind you and restore deleted layers: even Pro/GOOFY
isn't that goofy! If you'd like to check where, besides your workstation, your
files are being altered, look at 'Info>Audit Trail' which shows information from
the file header about every hostname that has opend and saved the file. BTW, a
checker notating your drawings with Markup Mode shouldn't alter your files or even
require saving them. But, while files are at WIP level, anyone in an authorized
group can do anything they like with the files unless a pdm checkout procedure is
preventing them. Once checked back in at WIP level, they're fair game. Once again,
though, this is looking outside the normal functioning of config.pro and
def_layer.

Good luck, let us know what you figure out. It's not an easy one, that's for sure.

David Janes

 

Yes, you can use intent surfaces and chains in the data sharing
features (CopyGeom, ExtCopyGeom, PublishGeom). Also you can select
quilts rather than individual surfaces. Same goes for complete datum
curve features instead of individual curve entities.

All of these can be selected in the "Misc Refs" section of the data
sharing feature. I advocate using Misc Refs rather than individual
surface, edge, or curve references for the reason you point out, and
also because Misc Refs gives a nice list of the referenced features.

- Wallace