Help with visibility of work planes, axes, sketches and points

Help with visibility of work planes, axes, sketches and points

nathan_m_gardner
Enthusiast Enthusiast
388 Views
8 Replies
Message 1 of 9

Help with visibility of work planes, axes, sketches and points

nathan_m_gardner
Enthusiast
Enthusiast

I want to ask if someone can help me with hiding these items from view. If I understand how Inventor handles these items correctly(I am sure I do not), these items should have been turned off at the part and sub-assembly level before saving and vaulting the files.

 

Often, when I open a top-level assembly or I place a sub-assembly into my working assembly, it will come in with many of these items turned on. I am told I need to open each individual file and manually turn off these items so they do not show up where I am using the files. I do not want to use Object Visibility because I still need to create sketches and such at my working level. Turning these off with OV also turns off the features I am working on. 

 

So, if I understand Inventor correctly, I would like a script of iLogic to turn these items (work planes, axes, sketches, and points) off for all subparts and subassemblies in my working assembly.

 

I have been given a post that will turn these off, but it uses the OV to do it, and therefore is not useful for me. 

 

Any help would be appreciated.

nathan_m_gardner_0-1748612247274.png

 

0 Likes
Accepted solutions (1)
389 Views
8 Replies
Replies (8)
Message 2 of 9

WCrihfield
Mentor
Mentor

Hi @nathan_m_gardner.  This has been a pretty popular topic in this forum for many years, with many discussions about it, and many 'solutions' posted for it.  As you have found out, it is not a very simple task, and there can be a lot involved.  One of the most helpful tools, or most troublesome stumbling blocks (depending on which side you are on), is the DVRs (DesignViewRepresentations).  These are present in both parts, and assemblies.

When you are in a part, there will be a 'node' near the top of the model browser tree with a name starting with "View:", and ending with the name of the 'currently active' view, which can be expanded to see the individual view representations within it.

When you are in an assembly, there will be a node near the same location named "Representations", which can be expanded to show sub categories for view representations, and positional representations, and so on.

 By default, there is only one view representation named either "Master" (in older versions) or "[Primary]" (in newer versions), and it will be 'Locked' by default, meaning it will not record/save visibility related changes to the file, and it can not be unlocked.  So, it is up to us to create a new/custom view representation that is unlocked, and activate it, if we want it to 'record' visibility changes, and 'reliably' see the model a specific way (such as all that stuff visibly turned off or hidden).  The view representations are what record things like colors, appearances, object visibility, and such (not object suppression).

 

If the only view representation you have in the model is a 'locked' one (like the original one is), then any of those types of changes that you make while that 'locked' view representation is active, will not be recorded by that DVR.  I have made it a point to include at least one 'custom' view representation (unlocked by default) in every new part or assembly that I create, by including it in all the templates that I start from, and making sure that 'custom' one is the active one.

Now, when we place a component into an assembly, we can set that one, individual component to specific 'representations' that are available within the 'source model file' that the component references.  That includes ModelStates, DVRs, and positional representations.  So, I always set my components to the 'custom' DVR, and set it to 'associative'.  That way, if that view representation of that part changes in the source model file, those changes will immediately be reflected in the assembly component.  On the other hand, if your source model file did not have any representations, and you place a component of it into an assembly, you do not have any options for setting it to a specific representation, so whatever the source model contains will be visible in the assembly component, and the only option you have is to edit the source model to turn the visibility of those things off.  So yes, the best way to do this is to edit the original model files, create a custom DVR in them, then activate it, and while it is active, make all visibility, color, and appearance changes needed, then save the model file.  But were not done yet, because now we need to go back to the component occurrence in the assembly, and set that occurrence to the view representation that we created within the source model file.  Now, we may still not be done yet, because we have to keep the assembly's own DVR's in mind.  For example, which DVR in the assembly is currently active?  If it is a 'locked' one (like the original one), then those settings for the individual occurrences will not be saved properly.  So, make sure the main assembly has a custom DVR, and that it is active, before setting all those individual component occurrences representations the way you want them.  Without any representations being involved, it can be chaos.  But all that is not nearly as much work when it was all being done as each model file was being created, which is how our shop does things.  If none of that was done in preparation, then large, complex, recursive automation codes start needing to get involved to drill back down through all of that and do all of that work later.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

0 Likes
Message 3 of 9

Stakin
Collaborator
Collaborator
0 Likes
Message 4 of 9

Andrii_Humeniuk
Advisor
Advisor
Accepted solution

Hi @nathan_m_gardner . Try the following iLogic code:

Private Sub Main()
	Dim oInvApp As Inventor.Application = ThisApplication
	Dim oDoc As Document = oInvApp.ActiveDocument
	If oDoc.DocumentType = DocumentTypeEnum.kDrawingDocumentObject Then Exit Sub
	Dim bVisible As Boolean = WhatDoing()
	Dim newTM As Transaction = oInvApp.TransactionManager.StartTransaction(oDoc, "VisibleObjects")
	Call ControlVisible(oDoc.ComponentDefinition, bVisible)
	If TypeOf oDoc Is AssemblyDocument Then
		For Each oRefDoc As Document In oDoc.AllReferencedDocuments
			Call ControlVisible(oRefDoc.ComponentDefinition, bVisible)
		Next
	End If
	newTM.End()
End Sub

Private Function WhatDoing() As Boolean
	Dim digResult As DialogResult = MessageBox.Show("Objects must be visible?", "Visibility of working objects", _
													MessageBoxButtons.YesNo, MessageBoxIcon.Question)
	If digResult = DialogResult.No Then Return False
	Return True
End Function

Private Function ControlVisible(ByVal oDef As ComponentDefinition, Optional ByVal bVisible As Boolean = False)
	For Each oWPl As WorkPlane In oDef.WorkPlanes
		Try : oWPl.Visible = bVisible : Catch : End Try
	Next
	For Each oWA As WorkAxis In oDef.WorkAxes
		Try : oWA.Visible = bVisible : Catch : End Try
	Next
	For Each oWPo As WorkPoint In oDef.WorkPoints
		Try : oWPo.Visible = bVisible : Catch : End Try
	Next
	For Each oSket As PlanarSketch In oDef.Sketches
		Try : oSket.Visible = bVisible : Catch : End Try
	Next
End Function

Andrii Humeniuk - CAD Coordinator, Autodesk Certified Instructor

LinkedIn | My free Inventor Addin | My Repositories

Did you find this reply helpful ? If so please use the Accept as Solution/Like.

EESignature

0 Likes
Message 5 of 9

nathan_m_gardner
Enthusiast
Enthusiast

hummm... this turns everything on. I think this is the line I need to change to turn everything off. What should I change it to?

 

Is there a tool that will give me choices to use in place of bVisible? In Visual Studio if you select a object you can get a list of choices to use. I know my terminology is not correct. I hope you understand what I am asking.

 

Try : oWPl.Visible = bVisible : Catch : End Try

 

0 Likes
Message 6 of 9

Andrii_Humeniuk
Advisor
Advisor

You should run the code and click the "No" button in the visibility selection window.

Andrii_Humeniuk_0-1749209034455.png

Andrii Humeniuk - CAD Coordinator, Autodesk Certified Instructor

LinkedIn | My free Inventor Addin | My Repositories

Did you find this reply helpful ? If so please use the Accept as Solution/Like.

EESignature

0 Likes
Message 7 of 9

WCrihfield
Mentor
Mentor

Hi guys.  I was not sure if @nathan_m_gardner meant that he wanted more control over the visibility of each type of object, rather than one setting for them all, so I looked in my 'code toolbox' and found a code example that you guys may find useful.  I don't really recall using it much myself before (yet), because I usually don't need codes like these, so I probably created it with someone else's wants/needs in mind.  I will put it in a text file, then attach that text file, because it is pretty long, and has an almost ridiculously large amount of 'Optional' input parameters to offer the most flexibility.  Likely more options than I have ever put into any single method before.  And yet, it still does not include the use of DVR's.  I'm thinking this massive Sub routine could be put into a Class or Module, with each of those 'input parameters' being a Public Property of that Class/Module, to make it a bit easier to use.  Then additional resources could be put into it to aid with DVRs (view representations).

Edit:  I just created that Module I mentioned within an external iLogic rule.  I called it 'VisibilityModule', turned its 'Straight VB Code' option on (and all other options off).  Then I tested it from an internal iLogic rule in a local assembly, and it seems to work OK.  I attached a text file for that Module also, as an added reference.  It could definitely be developed further, but is a good start for a handy, referenceable utility.

Wesley Crihfield

EESignature

(Not an Autodesk Employee)

Message 8 of 9

nathan_m_gardner
Enthusiast
Enthusiast

FYI, I just realised this does not run through pattern components. 

0 Likes
Message 9 of 9

nathan_m_gardner
Enthusiast
Enthusiast

Yes more control is desired but something is far better than nothing 🙂

0 Likes