Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.
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."
In WF1 that was possible, but it was unintended. There was a severe performance issue with that anyway. The item count in the top level assembly's layers, becomes astronomical. Been there, You don't want to follow!
First of all, thanks guys for this thread. Spreading the info is just the best.
I've read through this thread since we are starting up the Pro/E Wf3 with PDMLink construction now. We have the def_layer options set as of now, which seems fine by me so far. But I figure, that is because we have not made the large assemblies as of yet.
1) Is this a correct assumption?
2) Is creating the layers when you need it approach enough, or should everything go into the start parts.
3) In parts, should you just ignore layers there and use them in the assemblies only?
4) The def_layer note and gtol settings only work on notes and gtol created in drawing mode, not in modellinh mode, do you guys get the same response?
Thanks everyone. The background here is that I started with our company start part that has layers from before WF2, and I was trying to make their strategy work. Looks like that's not going to happen, so I will adopt the "lean and mean" approach that seems to be preferred here.
Still not sure about the "Rule(s) is not supported by layer" error I've been getting with axes...any insight there would be appreciated.
First of all, thanks guys for this thread. Spreading the info is just the best.
I've read through this thread since we are starting up the Pro/E Wf3 with PDMLink construction now. We have the def_layer options set as of now, which seems fine by me so far. But I figure, that is because we have not made the large assemblies as of yet.
1) Is this a correct assumption?
2) Is creating the layers when you need it approach enough, or should everything go into the start parts.
3) In parts, should you just ignore layers there and use them in the assemblies only?
4) The def_layer note and gtol settings only work on notes and gtol created in drawing mode, not in modellinh mode, do you guys get the same response?
1) Start parts and def_layer options work well for designs started from scratch. They don't help when trying to reuse models that were created under different standards. Layer standards will change over time. The skill base will go up, the jobs will be different, and the standards will adapt. In addition to def_layers you need techniques that can clean up a bunch of model's layers quickly.
2) The 90/10 rule applies. If a layer is actually used in 90% of your models, it should be in the start part. So for instance if less than 10% of models have points, don't put the points layer in the start part. I guess what I'm really suggesting is that the start part should not have extensive layers, simpley as a way of keeping a dictionary of preferred layer names. It costs in many ways.
3) I'm not sure I understand what you mean by "ignore the layers in the parts" What way are you taking about ignoring.
4) Nope. When I create gtols, notes and such in the model, they land on the correct layers, not because of def_layer options, but because of the layer rules. Gtols created in the drawing, depending on some settings are actually stored in the model. They too land on the correct model layers. If gtols are being created strictly as drawing entities, then by definition they can't be on model layers.
3) Ignore well, just don't bother with layers in parts and just focus on assemblies, that was what I was goingfor...
4) Well, this happens for me as well IF I design the layers with rules and such. But using def_layer and setting what to put on the layer as"note" or "gtol" does not work that way. It just works on the ones made in drawing mode. Why I can't tell......
That works that way over here as well. What Im unsucessfully is trying to communicate is that when adding a gtol to a model in 3D mode, it does not end up on the layer "test" to use your example. Adding it in drawing mode does.
Works fine in model mode. The layer test was created and the gtol, when created in the model, went onto the layer.
If it was expected that the gtol would be automatically placed on the test layer in the drawing after the gtol is created in the model mode, that's just not the way def_layer works.
Def_Layer options only have effect at the time of the relevant item's creation, and in the context of that creation.
I have been fine tuning my layer conversion process, updating my rules and updating files and assemblies as needed. I have noticed some odd behaviorwhen converting assemblies. Iusually spot check parts/assemblies randomly as a sanity check and found thatmost of the files had been converted properly but a few had issues. I also noticed thatthe problem files had the layers deleted so I know that part of the process worked. There did not seem to be any pattern as to which oneshad the layers copiedvs which ones did not. In addition, when I converted the "empty" files individually everything worked as expected. Has anyone else witnessed this behavior?
All the files that I reviewed were unique with no external dependencies or flexibility assigned. I thought it might have something to do with the sub-assembly location of the parts. One or two files were in the top level assembly,a few were in a sub-assembly and two others were in a sub-assembly of another sub. After seeing this I concluded that relative position in the tree was not the cause.Especially since the "delete layer" operation worked on all the files.
I will continue investigating and when/if I find something I will be sure to post.
If you had said that you were using WF2 I'd have suspected that all the relevant files were either instances or components having assembly cuts. I haven't seen that problem since moving to WF3. I am using M100.
Is it possible to remove view specific layer status in drawings?
I've changed layer status on some of the views in a drawing. Now I would like to change one of the views back to use the same layer status as the drawing does. Hope you understand what I mean.
To change the view back to drawing dependent, highlight the view that you want to change back, then click View (on top of screen) --> Visibility --> Drawing Dependent
To change the view back to drawing dependent, highlight the view that you want to change back, then click View (on top of screen) --> Visibility --> Drawing Dependent
Although it didn't help to just highlight the view. I had to choose the view from the dropdown list above the layer tree. Maybe that was what you meant? In any case, you made my job a bit easier. Thank you for that.
I came across this while updating some of my rules and found itinteresting. If you are aware of this issue and you have additional information please share.
When defining a rule, if the LOOK FOR and LOOK BY criteria are identical the resulting items captured by that rule cannot be individually modified by the Hide/Unhide options. The menu selection is greyed out. I take it to mean that all the selection criteria has been met and the only way to change the display is at the layer level. Basically an all or nothing approach.
As an example: I have a rule the moves all datumsnot used for GD&T (A-Z) to layer PLANES. The LOOK FOR was set to Datum Plane and the LOOK BY was also set to Datum Plane. The icon to the left of the entities in the layer tree looks like "x\a" (a point, an axis and a black box with a white letter A)
By resetting the rule to LOOK FOR to Feature the "x\a" icon is removed and the individual entity displaycan be set via Hide/Unhide.
Some might find this beneficial and some would think it's a problem depending on how strict you want to control your layers.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
