Switching model states of subassembly in main assembly

Switching model states of subassembly in main assembly

alikhan.ganayev
Enthusiast Enthusiast
2,708 Views
6 Replies
Message 1 of 7

Switching model states of subassembly in main assembly

alikhan.ganayev
Enthusiast
Enthusiast

So my problem is that I have a main assembly that consists of two subassemblies. These first and its mirror. The subassembly consists of 3 model states. It's just a couple of metal plates next to each other. In the first state I start of with 3 parts, in the second state it's 4 and in the third it's 5. The front and back plates don't go anywhere, it's the middle part that gets added.

sub1.PNG

State1

sub2.PNG

 State2

The problem is that, in the main assembly, however I placed the subassembly that's how it will remain. So one is stuck in State2 and the other in State3. I do see change because if the one stuck in state2 gets changed to state3, it just leaves a blank space where a part used to be because it somehow can't generate the extra necessary material. If If I change the one stuck in state3 to state1, the remaining plates just float nearby. Here is an example.

glitching out.PNG

 Also: Inventor 22/Windows 10.

0 Likes
2,709 Views
6 Replies
Replies (6)
Message 2 of 7

andrewdroth
Advisor
Advisor

How is the mirror created?


Andrew Roth
rothmech.com

YouTube IconLinkedIn Icon


IV2025 Pro
Apple IIe Workstation
65C02 1.023 MHz, 64 KB RAM
Apple DOS 3.3
0 Likes
Message 3 of 7

alikhan.ganayev
Enthusiast
Enthusiast

Just a simple component > mirror > mirror on XY and then I made sure to mirror existing relationships. I saved all the mirrored parts. I wish it was just a problem with the mirror but the same problem also exists in the original subassembly.

0 Likes
Message 4 of 7

johnsonshiue
Community Manager
Community Manager

Hi! I suspect you are seeing a limitation in Model States. You are trying to use Model States to drive Derive source. This is not a supported workflow. Please share the files here. Forum experts can help take a closer look.

Many thanks!

 



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

tomasz.sztejka
Advocate
Advocate

 

I can see You know Model State limitations very well so maybe You may enlighten me. I am a bit reluctant to upgrade to 2022 because it will require updating all the seats in a company, but may decide to do it depending on the detailed information. All the information about model state shows something what looks like a merge between iPart/iAssembly and LoD/ViewRep/PositionRep.

 

I am looking for an efficient way of implementing "product configuration". The request is that I should put MANY nested sub-assemblies with many parts and make one product of them. Then in the product (top) assembly I should be able to add something like "configuration table" where I may change each of parameters of EACH part and EACH sub-assembly. By "parameter" I mean both f(x), iProperties, constraints and BOM levels. For an example I would like to disable hole in sub-assembly-X-part-Y, and suppress from visibility and BOM some bolt-B in sub-assembly-Z which is mated with that hole.

 

This change of configuration must be applied in top level assembly and MUST NOT modify the component files because they are used in other products, each having own configuration. The change however MAY ADD some configuration dependent information to component files as long as it does not affect it's use neither in drawings nor in other products where they are also subject of separate configuration.

 

Can it be done with Model State or should I rather think about model state as View/Position/LoD representation + iPart/iAssembly equivalent?

0 Likes
Message 6 of 7

johnsonshiue
Community Manager
Community Manager

Hi Tomasz,

 

I think I know what you are trying to do. You want to drive configurations at all levels from the top-level assembly like in SWX Configuration. Inventor Model States works differently. Each level's configuration is done within the author table at the level. Cross-part driving isn't allowed.

For your configuration need, I think iLogic is still the best way to go. Essentially, you may create a new iLogic Model State or just keep using Master. Then use iLogic rules to drive changes. Once you are happen with the result, use iLogic Design Copy to spawn the variation.

Many thanks!

 



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

tomasz.sztejka
Advocate
Advocate
Thanks, You guessed correctly.

I currently applied such an approach without a model state, with minor success (basically due problems with efficiently suppressing component in assembly without too many many mess, ie. View Reps not surviving hiding, LoD messing up with drawings, Enabled doing nothing, and other. I think You know it best.). What I am able to do now it is to "switch" the whole project tree according to settings in a spread-sheet according to part number selected. Unfortunately it does not fully cover my needs, because I can't see and compare two part numbers at the same time. Not mentioning, that switching process takes quite a bit of a time.

The downside of any approach which is not top-down is the continuous application of changes to all components in a tree each time master, top level configuration changes. Remember, those components are used in many projects, so this may be a breaking change if I don't return to "base" configuration. This may be escaped with iAssembly/iPart one-row-per-variant, but it generates tremendous amount of member files which are extremely hard to keep up to date. Btw, I hope You are aware, that many changes in iAssembly/iPart factory does not trigger update of the member files, right? And that since certain version Autodesk disabled ability to validate it by graying-out many menu options when editing a member file, right?

Model State, as far as I did understood (I don't want to upgrade and mess up my work environment just to try it out) does not produce "member files", so if it covers the functionality of iPart/iAssembly it will be a better solution.

The problem is, that what You do propose in a last paragraph (iLogic Design Copy) is, as far as I remember, a suggestion to create few thousands of project copies (I am giving my customer about ten options to make a choice from, what produces thousands of variants). Those copies will be independent of each other, right? How do You imagine to maintain them and keep up to date?

(....) drive configurations at all levels from the top-level assembly like in SWX Configuration(...)

Hah! SWX is Solid Works? I wasn't aware it has such a functionality. I will give it a try. If it will work I think I could save tens of work hours. Thanks for a suggestion.