Error with 'Split' feature when changing Model States

[KaynePellegrino]

I'm making a Component that is either Extruded PVC or LVL Wood

When it's extruded, it's just one solid piece.

When it's LVL, it's multiple layers.

I made everything for the parts first, then at the very end added the 'Split' feature.

Added a 'Yes' or 'No' parameter so that when I say 'Yes' it will split the component to show layers for the LVL, and change the material to plywood to give it the correct look/properties. Then vise versa for the PVC, when I choose 'No' it will suppress the split feature, and change the material to a solid Beige PVC so it corrects to the proper properties.

However, the issues comes when "Model State 1" has the Split as 'Yes' and "Model State 2" has the Split as 'No'.

When I switch between model states it shows the error attached before allowing me to activate the model state I selected.

I've had it both ways where the Split Feature only affects faces, and where it splits the body into multiple bodies. No matter what it shows this error when changing between model states where one has Split as 'Yes', and one has Split as 'No'.

I'm using simple code, I don't know if that's the issue, but this is the code I use to suppress/unsuppress the Split Feature, and to change material.

'Split Active
If Split = "No" Then
		Feature.IsActive("Split") = False
	End If

If Split = "Yes" Then
		Feature.IsActive("Split") = True
	End If

'Material Change
If Split = "No" Then
		iProperties.Material = "7 Tan Standard PVC (Rail)"
	End If

If Split = "Yes" Then
		iProperties.Material = "9 Brown Fire-Rated Wood (Rail)"
	End If

I've tried it with and without the changing material code and still get the error

I even tried it with a dummy model where the split command is the only feature on the whole part and it still says the same thing.

Any Ideas or Suggestions?

 

[kacper.suchomski]

Hi

I don't understand the logic behind your workflow.

Either you're distinguishing variants using Model States or using an iLogic parameter and rule.

There is no need to duplicate the differentiating factors.

[johnsonshiue]

Hi! I believe this is due to Edit Scope confusion. When you have active iLogic rules and the Edit Scope is set to Member Edit Scope (one pencil), the iLogic rules may change the table. This is like double overrides. Any member specific parameter change or property change or feature suppression change should be captured on the table. It should not be triggered by an iLogic rule. Otherwise, it defeats the purpose of having the Model States.

Before activating a Model State member, make sure the Edit Scope is set to Factory, which means the change made by the iLogic rules apply to all members. And such change will not be captured on the table.

Many thanks!

[KaynePellegrino]

Kacper,

So I plan to have multiple model states. Like a few hundred

Some need the part to be solid, PVC composite

Some need the part to be layered, LVL Veneer

And when I do a section view for the drawings I need the layers to be visible.

So I make it a solid body split instead of just splitting the faces

'Model State 1' might be 40" long and PVC

'Model State 2' might be 30" long and LVL

I made 2 Parameters

LVLSplit: Text, Multi-Value; Yes, No

SplitThickness: Numeric; (About .125" Thickness)

Then I made a form with those parameters so I could easily just click "Yes" or "No". If "Yes", then the Split feature would become active and it would split the part into 2 solid bodies. If "No", then it would suppress the split feature and return the solid bodies back to 1.

I used rules to do so, as seen in my original comment.

I needed them to change material depending on if they were split or not. So that why why there's a material change rule.

I kept them separate for no particular reason if that's what you're asking. Just looked cleaner in my brain.

[KaynePellegrino]

Johnson,

I think I understand what you're saying, but I'm not sure you understand what I'm trying to achieve

I have a part that has hundreds of variations. So I planned to make a model state for each variation. So the table won't have the same values on each scope

Some need to be solid, PVC

Some need to be layered, LVL Veneer

And when I do a section view for the drawings I need the layers to be visible.

So I make it a solid body split instead of just splitting the faces

'Model State 1' might be 40" long and PVC

'Model State 2' might be 30" long and LVL

I made 2 Parameters

LVLSplit: Text, Multi-Value; Yes, No

SplitThickness: Numeric; (About .125" Thickness)

Then I made a form with those parameters so I could easily just click "Yes" or "No". If "Yes", then the Split feature (LVL Split) would become active and it would split the part into 2 solid bodies. If "No", then it would suppress the split feature and return the solid bodies back to 1.

I used rules to do so, as seen in my original comment.

I needed them to change material depending on if they were split or not. So that's why there's a material change rule.

I found the error came from me having multiple factors using the same name.

When I made the original comment, I had a parameter named "Split" (Now named 'LVLSplit'), and a feature named "Split" (Now named 'LVL Split' [with a space]). So it would confuse the program when switching b/w model states that where one had the split active and the other didn't. Once I gave them different names it worked smoothly

[kacper.suchomski]

It's very simple:

1. You distinguish variants through model states and define variables within them (browser interface / table / Excel), or
2. You create iLogic rules and define variants through user parameters (or form), or
3. You create iLogic rules and generate variants (components) through the configurator (form).

You cannot define two factors at the same time because they will compete with each other rather than cooperate and as a result you will receive recurring error messages.

You must consciously choose your modeling and data management strategy and stick to it.

Good luck

[johnsonshiue]

Hi Kayne,

I think I know what you want to do. Essentially, you want to use an iLogic rule to tweak each member selectively. This isn't a supported workflow. As I mention before, any member specific change needs to be captured on the table. Otherwise, the table will not be able to drive changes. All the required permutations need to be spilled out on the table. Each member should be unique. Before running an iLogic rule, you need to make sure the Edit Scope is set to Factory Edit, not Member Edit.

Many thanks!

[KaynePellegrino]

Johnson,

I may have misspoke. I don't run the rules to try and change multiple model states with different permutations individually.

I make the model states either one at a time, or I adjust the table by adding more rows and changing certain parameters how I need.

I just mean when I activate different model states that had different options selected for the 'Split' Parameter it would give me an error code.

Model States:

- [Primary]:

- Model State 1 (Has "Split" as 'Yes'): Active

- Model State 2 (Has "Split" as 'No'):

So the model states would already be made

It's just when I would activate a model state that doesn't have the same options selected for "Split", as the one previously activated, it would give an error.

Ex.:

Switching from Model State 1 to Model State 2

[johnsonshiue]

Hi! The iLogic rule gets triggered when there is a change in a parameter. When the Edit Scope is set to Edit Member Scope, the change by the iLogic rule will be captured on the table. The only way to avoid being captured is to set the Edit Scope to Edit Factory Scope.

Many thanks!