Efficient Coding, suppressing and unsuppressing features with parameters and rules

[KaynePellegrino]

Is there a more efficient way (processing wise, ease of writing wise, ease of understanding wise) to write this code?

'Reinforcement Kerf Count Left
Feature.IsActive("Reinforcement Kerf L 1") = False 
Feature.IsActive("Reinforcement Kerf L 2") = False
Feature.IsActive("Reinforcement Kerf L 3") = False
Feature.IsActive("Reinforcement Kerf L 4") = False
Feature.IsActive("Reinforcement Kerf L 5") = False
Feature.IsActive("Reinforcement Kerf L 6") = False


If ReinforcementKerfCountL = 1 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
     Else If ReinforcementKerfCountL = 2 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
       Feature.IsActive("Reinforcement Kerf L 2") = True
     Else If ReinforcementKerfCountL = 3 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
       Feature.IsActive("Reinforcement Kerf L 2") = True
       Feature.IsActive("Reinforcement Kerf L 3") = True
     Else If ReinforcementKerfCountL = 4 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
       Feature.IsActive("Reinforcement Kerf L 2") = True
       Feature.IsActive("Reinforcement Kerf L 3") = True
       Feature.IsActive("Reinforcement Kerf L 4") = True
     Else If ReinforcementKerfCountL = 5 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
       Feature.IsActive("Reinforcement Kerf L 2") = True
       Feature.IsActive("Reinforcement Kerf L 3") = True
       Feature.IsActive("Reinforcement Kerf L 4") = True
       Feature.IsActive("Reinforcement Kerf L 5") = True
     Else If ReinforcementKerfCountL = 6 Then
       Feature.IsActive("Reinforcement Kerf L 1") = True
       Feature.IsActive("Reinforcement Kerf L 2") = True
       Feature.IsActive("Reinforcement Kerf L 3") = True
       Feature.IsActive("Reinforcement Kerf L 4") = True
       Feature.IsActive("Reinforcement Kerf L 5") = True
       Feature.IsActive("Reinforcement Kerf L 6") = TrueEnd If 

"Reinforcement Kerf '_'" refers to an extrude/cut feature on my part.

I have 6 separate ones at different spacing on the left side of the component

Certain model states need none, some need 3, some need 6, etc.

So instead of manually suppressing and un-suppressing them, I made a multi-value parameter and rule to suppress and unsuppress one or multiple features at once. 

On a form I use the option with a radio group:

ReinforcementKerfCountL ~ Reinforcement Kerf Count Left : "0"  ,  "1"  ,  "2"  ,  "3"  ,  "4"  ,  "5"  ,  "6"

When I click a button, it will suppress and unsuppress the 6 cut/extrude features accordingly.

Button "0" suppresses all of them

Button "4" suppresses feature 5 & 6 while unsuppressing features 1-4 so I have 4 cuts on my part

Same for the other buttons

And I notice when I click different buttons the features flash on and off before finally staying steady on or off once it's worked through the code, like it's in a slight loop as it runs the rule. 

I'm not the best cod writer at all. So I'm curious if there's a better way of writing what I have.

[william]

You could switch to a loop and drastically reduce the amount of code you have. 

'Reinforcement Kerf Count Left
For i = 1 To 6
    Feature.IsActive("Reinforcement Kerf L " & i) = False
Next

For i = 1 To ReinforcementKerfCountL
    Feature.IsActive("Reinforcement Kerf L " & i) = True
Next

Personally, I would use an object collection to suppress/unsupress multiple features. It is far faster to run, but it does involve more code than what you currently have. 
You may not notice the benefit with a part this simple, but it can save a lot of time if you have a lot of features in multiple parts, see this forum post here. 
Solved: Re: More efficient way to suppress/unsuppress features? - Autodesk Community 

Sub Main
Dim oSupressFeatures As ObjectCollection = ThisApplication.TransientObjects.CreateObjectCollection
Dim oUnsupressFeatures As ObjectCollection = ThisApplication.TransientObjects.CreateObjectCollection

CreateFeatureCollection(oSupressFeatures, oUnsupressFeatures, "Reinforcement Kerf L", "Suppressed")
SetFeatureState(oSupressFeatures, oUnsupressFeatures)

For i = 1 To ReinforcementKerfCountL
    CreateFeatureCollection(oSupressFeatures, oUnsupressFeatures, "Reinforcement Kerf L " & i , "Active")
Next
SetFeatureState(oSupressFeatures, oUnsupressFeatures)

End Sub

Sub CreateFeatureCollection(oSupressFeatures As ObjectCollection, oUnsupressFeatures As ObjectCollection, Searchterm As String, State As String)
Dim oDoc As PartDocument = ThisDoc.Document
Dim oCompDef As PartComponentDefinition = oDoc.ComponentDefinition

For Each oFeat As PartFeature In oCompDef.Features
	If oFeat.Name.Contains(Searchterm) Then
		If oFeat.Suppressed = True And State = "Active" Then
			oUnsupressFeatures.Add(oFeat)
		Else If oFeat.Suppressed = False And State = "Suppressed" Then
			oSupressFeatures.Add(oFeat)
		End If
	End If
Next


End Sub


Sub SetFeatureState(oSupressFeatures As ObjectCollection, oUnsupressFeatures As ObjectCollection)
Dim oDoc As PartDocument = ThisDoc.Document
Dim oCompDef As PartComponentDefinition = oDoc.ComponentDefinition

Try
	oCompDef.SuppressFeatures(oSupressFeatures)
	oSupressFeatures.Clear
Catch
	Logger.Error("Error suppressing features")
End Try

Try
	oCompDef.UnsuppressFeatures(oUnsupressFeatures)
	oUnsupressFeatures.Clear
Catch
	Logger.Error("Error unsuppressing features")
End Try

End Sub

[william]

Reading through your question again, you mention model states. You can set the suppression state for each feature for each model state. Once done, changing model states will show the correct features active.. So I am now wondering why you want to be able to supress/unsupress from a parameter input. These are 2 different workflows to accomplish the same thing. It seems like a contradiction to use model states, and then also use iLogic to set the correct suppression state from a parameter.

[CCarreiras]

I would setup the model states for each option (1 to 6) and then, use ilogic rule and form just to jump between each model states...

[Curtis_Waguespack]

Hi @KaynePellegrino, 

You can further reduce @william's example down by evaluating if ReinforcementKerfCountL is greater than or equal to the variable "i" as it loops.

See attached 2025 example file with a slider control in the form that might be of interest as well.

Hope that helps,
Curtis

For i = 1 To 6
    Feature.IsActive("Reinforcement Kerf L " & i) = (ReinforcementKerfCountL >= i)
Next

 
Or if you want to get really extreme you can reduce it to one line 🙂

For i = 1 To 6 : Feature.IsActive("Reinforcement Kerf L " & i) = (ReinforcementKerfCountL >= i) : Next

[KaynePellegrino]

@Curtis_Waguespack 

@CCarreiras 

@william 

So, I make doors at my company. The part I'm working on right now is the rail. It varies in length, width, and height. It goes in the top and bottom of the door. Other parts need to interlock with the rail so when we fill it with other components the door doesn't come apart. That's what the kerfs are for, to have a slot for the other parts to slide into and hold on. I made an index of every rail we use in production and it comes out to around 2'700 total rails. So my thought process is for each component, like the rail, I would make a model state for every variation. Then put it into an assembly for making the whole door. Then in the Door Assembly assembly file I would make a model state for each door we sell and just change the representation of each part to be what goes in that door per model state.

William ~ "So I am now wondering why you want to be able to suppress/unsuppress from a parameter input":

I use parameters/forms because in my mind it feels cleaner and better than manually selecting each feature and suppressing or unsuppressing it based on what that rail/model state needs to be. And it isn't just kerfs, there's a max of 6 pairs of kerfs on each side, max of 4 vent holes on each side, a fill hole, other kerfs and radius's, etc. Some rails need to be either 1 solid PVC composite or wood with a solid split and material change.

So I put it all on forms with renamed/keyed parameters cuz it helps me organize and see everything I need too better.

CCarreiras ~ "I would setup the model states for each option (1 to 6)":

I do plan on having a parent model state for each 'Kerf pattern".

There's 11 patterns where the kerfs are spaced differently and the patterns also need different amounts of kerfs. Then I'll make model states off of them for the different widths of doors and whether or not they are on the inside or outside of door because that changes the length even more. If it's on the outside it's just shorter in length than the width of the door. But if it's inside then it has to fit between multiple components and therefore is even shorter, sometimes more on one side than the other depending on the door structure.

Curtis:

This code works flawlessly

For i = 1 To 6
    Feature.IsActive("Reinforcement Kerf L " & i) = (ReinforcementKerfCountL >= i)
Next

 The one I had would take many seconds to activate different model states and even adjust the parameters, but this one is nearly instant. Thank you!

But yeah, I'm gonna have roughly 2'700 model states, so anything I can do the speed up activation and loading times is greatly appreciated

I'm attaching a zip file with the Rail model example and a door assembly example to see mostly how it would work.

[CCarreiras]

Hi!

I prefer to go more on the parametric side (combined with iLogic rules, modelstates, etc), instead of relying only in hundreds of ModelStates.

2700 model states... i don't know... probably is better to do some models dividing them by type or any other categorization, instead of making a super model that have it all.... but it's very slow and hard to track some errors that arise.

It´s just some tips based in my experience.... after all,  i don't know in what you want to achieve in detail...

Here's an example:

[KaynePellegrino]

Are you saying to make one model (ipt.) for each component of the door, with only the primary model state and then adjusting each component at the assembly level?

That's what it looks like to me in the video, but I'm not 100% sure 😬

My only concern with doing that, if that's the case, is how do I make a production drawing for each component if I'm only adjusting it at the assembly level. I will definitely need to adjust parameters like where holes go, the diameters, Kerf widths and depth, etc. on individual rails. But if I only adjust them through the assembly how can I translate that to a drawing (.idw) for each individual component?

[CCarreiras]

Hi!

There's not assembly features, each part is independent, but they all have common parameters.
In this case,was created a part (SKEL.ipt) with the overall scheme of the door, and all the parts will come to get info at this reference part.
This SKEL.ipt is like an excel, in terms of parameters, but also have sketches, surfaces, rules... that will help to create each part.
This reference part is partially loaded as a derived part in each part and give to each part specific information to set that part.

The rest is created by changing this reference part: changing parameters, running some ilogic rules to set the assembly, etc .... and all the parts will adapt to this global changes.

Theoretically, you can have the size you want for this door (respecting the boundaries you set), in opposition of the static values imposed by a ModelState for each member.
Well... some parts must need that static values for each case (standard parts),  but some others will need to be more adaptative, so.... you will not need the 2700 fixed versions, you can have infinite possibilities in terms of size, respecting some modelstates in some parts... so .... a lot less modelstates, but, a litle more simple ilogic code.

[KaynePellegrino]

So I think I'm understanding the reference part aspect. You have one part that controls the parameters of other parts by linking the parameters between them. So, then you can assemble the parts and have them adjust based on how you change the reference part. Using rules, forms and parameters.

But when it comes to the aspect of making a drawing for the parts, that's where I'm confused.

If I make the reference door part 36" wide, that will adjust the rails to be 34.905" long. Then If I make a drawing of those rails, it will show them at 34.905" long. But if I change the reference door part to 30" wide, that will adjust the rails to 29.905" long. Won't that change the first drawing when the door was 36" wide? Or would the 36" wide door and 30" wide door be a separate model state?

I will need to have an individual drawing for all 2'700 rails because they're all slightly different, but is that possible without having a model state or separate file for each one?

[CCarreiras]

---

@KaynePellegrino wrote:

But when it comes to the aspect of making a drawing for the parts, that's where I'm confused.

I will need to have an individual drawing for all 2'700 rails because they're all slightly different, but is that possible without having a model state or separate file for each one?

---

I understand your doubt...

Imagine the example model like a generator of doors: with any size and versions possible controlled by the user.

Also the 2D drawings are already setup and ready to update.

Imagine you get an order for X Doors with 30" and Y Doors with 36" (and imagine Z doors with 34.5"(but probably you don't have this last size in the model states, so you are out for this case)).

Regarding the X and Z doors:

I use the generator model  and setup the XDoor version: set 30", among other specs.

The drawings will update. (in my case, even the part numbers update reflecting the window version and size)

It's done? Ok, lets copy the result to the XDoor folder and send it to production (this copy process can be also automated).

Start the configurator again and setup YDoor, set 36", among other specs... in a few minutes, i have the 3D and 2D results... save it to the YDoor folder and send it to production.

Start the configurator again and setup ZDoor....... etc

_____________

This is just a process to make you aware of new directions, i don't even know if that applies totally for you...

...but a i know one thing... you will built a 2700 versions model, which will be a cumbersome model (if it even works, i don't know if inventor will permit so many modelstates)... and most probably you will not use 70... 80...90% of the main assembly states available, right?
Also you will be restrict to the model states you have... if you need some different size, you will not have it.

"All the processes have pros and cons..."

[KaynePellegrino]

Are you saying, if I setup a ref model with all the parameters and all the door components and assembly. Then I can have it generate a door assembly and component models for that door, then it will make drawings for that door and it's components?

I've never setup something that complex so I'm very unsure of how it all would work

My whole plan (before this thread) would be to have a door assembly file that has a model state for every door that we make (We make a couple hundred different doors)(Which means I would be using all 2700 rail model states at some point).

I would also have a part file for every component that goes in the doors we make, and those components would have a model state for every variation of that component.

Components:

1. Skin (Face of Doors, main design) ~ A few hundred Model States

2. Stiles (Sub-assembly, edge of door. Made up of Cap, LVL, Steel) ~ 150 Model States

         - 2a. Cap (Part of stile that makes the doors' visible edge) ~ 40 Model States

         - 2b. LVL (Piece of Laminate wood, 0.5 - 3.5" wide, reinforcement for the sides of the door) ~ 50 Model States

         - 2c. Steel (1/8" Steel Strip that's glued to LVL for more structure in certain cases ~ 6 Model States

3. Rails (Top and Bottom of Door, outer rails & inner rails (inner rails sit inside door between the skins and stiles [Makes up 60-70% of the rail model states])) ~ 2700 Model States

4. Glass ~ 50 - 70 Model States

5. Foam Blocks ~ 10 Model States

The Door Assembly would consist of 2 Skins, 2 Stiles, 4 Rails (2 for outer top and bottom, 2 for inner top and bottom. If I need more than one top or bottom inner rail then I'll array it inward however many I need), 1 Glass, 2 Foam Blocks (1 for inside top and 1 for inside bottom).

I would make each component model, with all it's model states. Then make a separate idw. for each model state with the rev number. Then print each one out to PDF so I can share them over email if needed, or if someone on the floor needs to review it for whatever door they're making I can print it out for them to see.

If I needed to revise a part because something changes and say we need to move where the vent holes are in the rail, I would open the rail model file, change the model state name rev number (CRRLT3000.00  ==>  CRRLT3000.01), make the adjustment, open that rail model states' idw file, update the drawing, print it out and send for approval. Which would then update the door models that use that rail as well. And depending on the severity of the change to the component would determine whether or not it warrants updating and reprinting the door drawings associated with that part as well.

Then for the Door Assembly I would create new model states for each door, name it whatever it is, then suppress or unsuppress the components based on what I need in the door and change their representation to be what the door needs. Then repeat till I have a model state for every door we make.

Then same as components for door drawings. I would create a separate idw. file for each door model state, print out on PDF, and then I can send it over email or print it out if needed.

If I need to revise something I activate that door model state, rename it (DRS003068.00  ==> DRS003068.01), make the adjustment, update and reprint the drawing and it's done. Then because I have all those model sates, I can activate whichever one I want to view it.

Plus then I can do thing's like test the fitment of different door knob sets. Sometimes there's mortises that need cut and if I make a new assembly with the door model as the main component, I can change it's representation in the "Door Knob Cut" assembly file to see how it fit's on different door structures, after making different cut patterns on the face and edge of door. Mainly to see if the depth of the cuts compromise structure of the different components.

Is what you're saying a way for me to do what I just laid out, but faster/more efficient? Or is your way only a way to temporarily show possible configs for all the doors based on part parameters? What I have is things already tested and work. But 95% of our files are AutoCAD 2D drawings. I want to make everything Inventor 3D models and IDW 2D drawings. So I'm, looking for the best way to do that, while also having room to add new things when needed.