Locked View Representations

Locked View Representations

Brian_Price
Advocate Advocate
2,103 Views
10 Replies
Message 1 of 11

Locked View Representations

Brian_Price
Advocate
Advocate

I am using a skeleton sketch method to making assemblies. For each of the sub assemblies I set up a view representation so that when I derive the sketch I can select the view rep and it only derives what I have already set up.

 

I have to add components to the assembly and do so by modifying the skeleton sketch. Whenever I add features it then adds those to all of the view reps. I then have to go into each rep and turn it off. Various changes can bring them back so it is a constant battle to turn them off so I only have what I need in each rep. Not to mention it makes things much cleaner and easier to use.

 

I tried locking the view reps but it allows the new features to attach to the rep anyways. I then have to go through all the reps and change the visibility on all the items I just added. It seems the lock only stops me from removing existing features not adding or removing new ones.

Is there a way to actually lock a view rep that it can not change until I activate or unlock it and make changes? Perhaps there is another method to do what I need?

 

Edit: After working with the locked reps a little bit more, sometimes it makes me unlock the rep, remove the new feature and re-lock it. Not sure why it allows the new change but won't allow me to remove it sometimes but not others.

0 Likes
Accepted solutions (1)
2,104 Views
10 Replies
Replies (10)
Message 2 of 11

johnsonshiue
Community Manager
Community Manager

Hi Brian,

 

I need to confirm with you on the behavior you are seeing. I assume you are talking about feature color overrides in a part, right? If yes, this is a limitation in Part Design View Rep. Feature colors, face colors, and origin planes visiblity are not controlled by Design View Rep. They have dependency on feature compute. As a result, they cannot be changed without going through feature compute, which is out of scope for Design View Rep.

Many thanks!



Johnson Shiue ([email protected])
Software Test Engineer
0 Likes
Message 3 of 11

Brian_Price
Advocate
Advocate

Sorry, but I wasn't clear. The features I am talking about are sketches, work planes, and surfaces. I have these turned off and on according to the view rep for the sub assembly parts I will derive it into. Whenever I add a new one it adds it to every rep. Is there a way to stop that and only add to the ones I want?

0 Likes
Message 4 of 11

johnsonshiue
Community Manager
Community Manager

Hi Brian,

 

I see the behavior. This is the inconsistent locking behavior between Part Design View and Assembly Design View. In ADV, any newly created objects like components or work geometry, is turned off by default when a locked Design View is active. In Part, the things get a bit more complicated. It is because a part is history based. The visibility of a given object is not totally dictated by Design View. For example, you edit an invisible sketch, the sketch will need to be made visible along with any projected source geometry (maybe invisible). This makes the locking behavior very hard to manage. I suggest you avoid using Part Design View while you are actively editing the part. You can run into confusing behavior easily. PDV is best used when you are done with modeling and you want to control object visibility and appearance on a given design.

Many thanks!



Johnson Shiue ([email protected])
Software Test Engineer
0 Likes
Message 5 of 11

DarthBane55
Advisor
Advisor

Hello @johnsonshiue 

I'd like to resurrect this if I may.

When in an assembly, I create view representations, to show or hide some components.  Then I lock them (the rep).

Then I create some sketches, not in a part, but in the context of the assembly, top level.  

These sketches then appear in ALL the locked view representations.  It is very annoying, because we use this a lot for machining (CAM).  Say we have a program for the fixture, one for 1st operation of the part, one for 2nd operation, 1 for cutting jaws etc, so we switch back and forth between all of these reps all the time, and add quite a few sketches along the way as we program.  It makes using the rep very tedious.

I am not sure it is the exact same situation as OP was describing...  if it is, I guess I need to learn to live with it, but if not, could you check if this could be solved?  I am just talking about sketches in the context of the assembly, not within parts.

Thank you!

Message 6 of 11

johnsonshiue
Community Manager
Community Manager

Hi! The behavior you describe does not sound right to me. I tried a very simple case and it seemed to work. But, I am sure I did not follow the exact steps correctly. Do you mind sharing an example that exhibits the behavior?

Many thanks!



Johnson Shiue ([email protected])
Software Test Engineer
0 Likes
Message 7 of 11

DarthBane55
Advisor
Advisor

Hi @johnsonshiue 

Here's a simple example of it.  Please download all 3 files attached, and open the assembly.

You will see 3 view representations, and 2 sketches.  The view reps are locked.  The sketches were done after these view rep were locked, and switching between them 3 view reps shows the sketches (visible) in all of them.

At worse, it should show the sketch only in the view rep it was created, but I say at worse, because the view rep being locked, if you make a sketch, switch view rep, and come back to it, that sketch should not even be shown in that original view rep (should be hidden), because it's locked, therefore nothing should change in it's locked stage.

But please, choose any view rep of your liking and create another sketch, then switch to any other view rep, and the sketch will remain visible.

 

For a parallel comparison, and how I was expecting the sketches to behave, is that if I insert another part into this assembly, and the view reps are locked, switching view reps will (rightfully) hide that new part.  I think it should be the same for anything, including sketches made in the context of the assembly.

 

Let me know how it goes!  This is the behavior I get in every single assembly I've created in the past 4-5 years that I am with Inventor!

Thanks for looking into it!

0 Likes
Message 8 of 11

johnsonshiue
Community Manager
Community Manager

Hi Darth,

 

Many thanks for sharing the files! I think I know the issue. This can also be seen at Part Sketch level if I am not mistaken. The issue here is that the internal process of creating a sketch is different than creating or inserting a component. The visibility of a sketch can be affected by edit target, its parent, and roll back. For example, when an invisible sketch is edited, it has to be made visible anyway. When a parent sketch is edited, the child sketch needs to be invisible. As a result, it does not yield the same behavior in locked Design Views.

I have to admit the behaviors are quite confusing. Let me work with the project team and see if we can change the behavior with minimum impact to existing workflows.

Thanks again!

 



Johnson Shiue ([email protected])
Software Test Engineer
0 Likes
Message 9 of 11

DarthBane55
Advisor
Advisor

That would be awesome!  Thank you very much for looking into it!

0 Likes
Message 10 of 11

johnsonshiue
Community Manager
Community Manager
Accepted solution

Hi Darth,

 

I did discuss with the project team and obtain some information. This is a limitation unfortunately. Locked DVR is a relatively expensive operation due to the way it was implemented. When the DVR is locked, DVR associativity will be removed. This means the top-level DVR will have to store all the visibility info across all levels.

For component visibility, the number of total occurrences dictate the visibility info stored in DVR. However, if we allow geometry visibility to be included, it can easily multiply the amount of data to manage. Also, to control such data stored in the individual files, the files need to be fully loaded. It will be a big hit to assembly performance.

Certainly, there should be a way to improve but it is much bigger than fixing a defect. At the moment, we don't have a good solution yet.

Many thanks!



Johnson Shiue ([email protected])
Software Test Engineer
Message 11 of 11

DarthBane55
Advisor
Advisor

Alright, that's too bad, but thank you for looking into it.

0 Likes