Drawing view reflects to wrong model state

[Arto.Konttinen]

Hi!

I have made three different model states to the assembly. When I try to use these in drawing views in a same drawing, they all look the same and when I measure I get same dimensions even in the model state table they are different. I already learned that text parameters are not supported in models states and same seems to apply also for the True/false parameters. Can these unsupported parameters somehow jam the drawings views?

[Arto.Konttinen]

...in addition, these dimensions shown in the screenshot are changing according to model state which is active in the assembly. The problem is that they change in all drawing views.

[theo.bot]

Did you check the Model state representation in the view setting for each view?

[Arto.Konttinen]

Yes, they all have the model state selected which they should represent. Only thing that seems to work is the "Estimated cost" iProperty which I have set for every model state. I added that information to drawing view label and that's correct in every view.

[theo.bot]

Is the model state correctly in your assembly environment. meaning do you have different sizes in the model state as you check them in your assembly. Any additional rules running in the background? Can you share the data? 

[Arto.Konttinen]

Yes the size changes in the assembly. That's why it's strange that in drawing I get the same geometry in all views. There is a rules behind. Equations to calculate dimensions, one to take those parameters into parts and also suppression rules. 

This model is quite big and I would need to rename it because it has the customer name in it's filenames. Maybe I try with some smaller model that will it produce the same error. If not, then it's something to do with this model. 

[johnsonshiue]

Hi Arto,

I suspect you have iLogic rules in the assembly driving parametric changes within individual parts (frame members). If yes, the Model States may not be your solution. For your case, you will still need to use iLogic Design Copy to spawn the variations, just like LOD in the past. Model State changes are managed at the table within the level, not across levels.

Please feel free to share an example so forum experts can help take a look.

Many thanks!

[Arto.Konttinen]

Hi!

I don't know if this help at all but I checked the values of Models  states via Spreadsheet and found that all the different states has their own parameters as they should.

It's hard to understand that my model would not work with models states because in fact the model works fine but in the drawing side the problem occurs. I have another model from the same Demister structure but it's just a simplified one ipt model, not assembly. It has also iLogic rules and they calculate among other things these exact same parameters than shown in the picture above. Well with this single part model the Model states works all the way to the drawing.

[johnsonshiue]

Hi Arto,

The confusion here is that the model may react to the parameters and driving relationship at any given Model State correctly. It does not mean such change can coexist with other Model States. For example, the assembly MS1 drives part1's length to 100mm. MS2 drive part1's length to 200mm. You can activate each MS and see they seem to work accordingly. However, part1 only has one MS. To make it work, part1 needs two MS': MS1 and MS2 (each corresponds to the length value accordingly). Now, you can define MS1 and MS2 within part1, which is not driven by the assembly.

As I mentioned earlier, at the moment Model State does not allow you to drive across the levels. Each level manages its own Model State. It cannot manage the Model State across levels.

This is why I said iLogic will still be your best bet when you need to drive across levels. Then you still need to use iLogic Design Copy to spawn the variation so that the geometry can be presented properly in the drawing.

Many thanks!