What a State We’re In: Inventor Model State Tips and Tricks

PETE STRYCHARSKE: Hey, everybody. My name is Pete, and welcome to my class, What a State We're In, Inventor Model State Tips and Tricks, where we're going to go a little bit deeper into model states and really try to make these things sing.

But before we get into the meat and potatoes of the presentation, just thought it would be good to let you know a little bit of the fellow that you're dealing with. So my name is Pete, and I'm an implementation consultant with TeamD3.

And we're an Autodesk platinum partner and a coalition of brands that covers all kinds of industries ranging from manufacturing and design, architectural and construction, and process and plant. So it's really a fun group, and cover a lot of ground, do lots of things. But some of my primary responsibilities are teaching classes, mostly on Inventor, but also on some other programs.

I provide technical support on Autodesk products, so if you ever hit the Enter key and all of a sudden the program crashes, yeah, give us a call. That's what we do there.

But my favorite part is consulting with customers. I love listening and learning about my customers, seeing what they do, and then brainstorming and developing different workflows, different process improvements. And also, I like to get my hands dirty and get into some customer content creation.

So last year when I taught, I was getting very much into the YouTube channel, developing YouTube content for the D3 team. And my wife jokingly called me a CAD influencer. Well, she's still calling me a CAD influencer. And I'm still telling her, just like I told her last year, babe, nobody else is calling me that. But it's a lot of fun. Love trying to answer questions and help people out even on YouTube.

When I'm not working, I love trying to connect with god and serving in my church, particularly with kids. I'm a huge Star Wars nerd. But I also getting outside, particularly if you get me to an ocean, I'm like, oh, amazing, and sports, particularly, basketball. Love to play ball as much as my knees let me.

But what are we doing here? Why are you attending this class? What's the goal? So there's a lot of really good content out there on model states. When model states came out in 2022, there's lots of videos, there's lots of information. I believe there are even a couple of Autodesk University classes last year on model states.

So there's a lot of getting into building model states, some of the fundamentals, that's well covered. My purpose for the class is to go a little bit further than that. After working with customers for a year, answering their questions, investigating some of their challenges, I want to share some of the things that we've learned together and some of the workflows I've helped develop with customers to try to make these model states work much more efficiently.

And these tips are going to break down into three main areas. So we're going to look at organization of model states. How do we set them up to be successful? And then when the invariable changes come, how do we handle that? How can we reorganize the data and still maintain consistency and efficiency.

One of the more interesting questions I received over the past year was people who saw model states the same way I did. It's a sweet spot when you've got multiple operations, and we're seeing how a part can be progressively formed. But then somebody asked me, this is great. But I want to animate this for my shop so they can see how it's being formed. And I thought, wow, that is a great question.

So we're going to take a look at that. How do we verify the fabrication, make sure we're happy with the processes, by organizing and animating model states? And because I'm so great at times management and planning, I didn't realize that the class was 90 minutes long this year instead of an hour.

So I've added some bonus topics. So we're going to take a look at some things that are quasi advanced, talking about an interesting quirk with derived designs and model states, and maybe thinking about using linked model states instead, older assemblies from prior to 2022 Inventor. How do we handle level of detail? So we'll talk about some of the things we can do there.

And then finally, one of the big issues that I had customers bring up was we don't see the model states in Vault. So we do have a conceptual workflow showing people how you could make model states more visible in the Vault uses tab.

So let's dive into it. First topic may sound a little strange, but we're going to talk about model state naming. And you're probably thinking, well, why the name, Pete? What could possibly be crazy about a name? Well, there actually can be some stuff involved with the name, and it's really important to think about how we want to name our model states.

So one of the first things that I want you to note is that, when model states first came out in 2022, you just had to have a model state. You had to have something to start with. So they used the master model state. In 2023, they've changed the name to primary model state, but it still serves the same purpose. It's the initial model state for a design.

And actually, that's what I would challenge you to think of when you see the primary model state is just think of it as an initial model state because I think the name can be a little confusing, maybe somewhat deceptive, because typically we think, hey, if it's the master or the primary state, everything is active. But that is not the case. We can suppress features, and we can suppress components in the assembly.

So besides the confusion, it can actually cause some challenges when we're working with converted levels of detail. And when you look at the bill of materials for a converted level of detail, just because of the way the level of detail worked-- which we'll touch on later-- it activates the primary model state because it needs to track all the parts.

So what can happen, though, is if somebody suppresses a component in the primary model state, now when we look at the bill of materials for our converted level of detail, that bill of materials may not be correct.

So what I've suggested after looking at this with lots of different customers teaching several classes, many, many classes, actually, is that we think that you should use a specific final design model state. Now, that's just my convention, final underscore design. But you need to come up with something that denotes that, at the end of my part, this is it. This is the model state you should be using in your designs and your assemblies.

Now, of course, if you have multiple versions or things like that, this doesn't match. But if you have a conceptual design or maybe many operations, as in a sheet metal part, try to use something like final design.

If you're not doing that, though, for example, if you are trying to name each of the states in your manufacturing process, or maybe you've got multiple versions of the same part-- I'm going to show you some simple examples with dimensional lumber-- you really want to have consistent naming. It helps you stay organized. It helps you understand what each model state is doing. But also, when you get to the assembly, there's an added benefit. If you think about iParts-- I know, evil iParts-- one of the things I like about iParts, though, is that you can look at the key parameters. And it really helps customers drill down to the exact variation that they're looking for.

In model states, you don't have that luxury, at least not yet. So it's all dependent on the name. So you really want to take the time to make sure you're naming things clearly, well, and consistently.

So once you've covered the name, now it's time to get into actually working with the model states. So it really pays to get organized. And one of the very first things that I recommend doing is to create a special model state called the setup model state. You can call it whatever you want, but that's what I use.

And this can really help us think through the design, and ultimately, will make working in Excel much easier. And the reason is, if you look at the left, in the setup state I can edit all the parameters that I wish to add to the particular extra variations. In the middle, I can take a look at things like material, other iProperties. We can make changes to those in the model state, and we can even suppress, unsuppress, whatever we need to do, certain features.

And what happens is this makes Excel work much, much easier because every time that I make a change in the setup state, that adds that corresponding column into Excel. And frankly, it's just much more efficient to work in Excel when creating lots of model states.

And of course, nothing is perfect. Sometimes we make changes. We decide to do things a little differently. So hey, we need to remodel from time to time, right? Everything's get stale. We need to prep it up, maybe get a little better organize, get more efficient.

So once we've got the data in the spreadsheet, again, typically, using that setup row, now I go back in there and make whatever changes I need to to maximize my efficiency. So some common things that I do is the order in which you make changes in the setup state, well, that's the order that they show up from left to right in Excel. So sometimes, I want to group the data little bit more efficiently.

Also, you get in a groove. You start working away, and all of a sudden you realize you've made some model states and they might not be in quite the order that you'd like them to be. Well, we can rearrange those even in the browser by simply left clicking, holding, and dragging. And we can reposition model states there.

And then, finally, we can, of course, add and rearrange rows in Excel. So it's just really fast to work inside of Excel and modify these model states.

So I want to pause here, take a really quick look at an example. It's going to be really basic. Almost all my examples today are going to be pretty simple. But I want to use these to help drive home the importance of working with the setup and also making some easy changes with Excel.

So I'm going to jump into Inventor. And here's a part that I've already made. So I make these changes to the primary state. And you can see it's just dimension lumber, right? There's parameters. There's a feature, a hole. So if you ever frame walls, you may have to run wires through the 2 by 4s in the wall members. So I've go ahead and I've added a hole.

And so, what we're going to do-- and I'm going to do this a little bit out of order from my slides, but just to show you the general workflow-- I'm going to create a new state called the setup state. Yes, I know we can edit the members. So I'm going to go ahead and say setup. And this is the state where I'm going to make all of my changes.

So if I come up to the fx. I go to the parameter table. It's the order in which you make them. So if I say 24 here for the length, 5 and 1/2 for the width, 3 and 1/2 for the thickness, that's the order it's going to show up in Excel. So even if we pick them out of order, we can fix it later.

And then we can make other changes too. We can look up here, find a material. Let's apply-- think I've been using southern pine, so why not keep a good thing going. Here's our southern pine. And then we can edit other things like the iProperties. So I'm just going to go kind of fast here. I'm just going to add in a part number, ABC123. We can always adjust this later, but just so you can see it get added. And then, finally, I'm going to suppress that hole.

So you make all the changes that you want to inside of that set up, save it. It's always a good idea to save. And then we can take this and move it into Excel. So when I jump over to the Excel sheet, what's really nice about this is everything that I changed is now inside of Excel. So it's really nice and easy. If I need to make changes, I can do that.

But it's not really in the order that I might want. So I did the length first, then the width, then the thickness. So it may be advantageous for us to change some of those things. So if we need to rearrange stuff, I can cut and paste. Oops, there we go. And I can keep doing that as long as I click in the right spots. And I can now rearrange this by thickness, length, et cetera.

We can also handle certain things in the order we want to hit them. So I really don't care about this one. So I can move it more towards the end. And I can also insert some rows here. So if I insert two rows, I'm going to use the power of Excel because not everybody knows what 1 and 1/2 is. That's a 2 by 4. Dimensional number kind of drives me nuts.

So I can create my own columns just inside of Excel also. So I'll create nominal-- whoops-- thickness, nominal width. And then we're going to straight up use the power of Excel. So I can do things like this. I can say equals round up. It's always going to be rounding up the thickness comma 0, hit Enter. It's not happy. The reason it's not happy is these are inches. So another change I make in here is I'll type in 1.5, Tab, 3.5, Tab, 12. And there you can see that it's correcting the formulas.

So again, because this is Excel, I can just go like this-- sweet-- and I can go like this. And because I reordered the columns, see how much more efficient that was to create those shapes.

So the other thing we can do is make life easier, again, clear naming. I'm going to set up an equation, concatenate. And we're going to grab the values. So I'd grab nominal thickness as my texturing. And if you're not as familiar with Excel, don't sweat it. Just takes a little bit of practice.

You can get pretty good at it. I'm just putting an x between each one. Then we'll grab the length. And then, oh, I'm actually going to write an equation here. If-- because I want to capture the hole if there is one. So I'm going to check H3, if H3 equals compute, then I want to add a texturing hole. If not, just leave it blank.

So that's a really efficient type of a name is by grabbing the properties, even columns I've added myself, and populating them. So the cool bit is we can do stuff like this then. We'll copy this. We'll just do a few just to save a little bit of time. And then we'll insert those.

So next step, I'm going to do an equals this cell here. And now I'm going to make the member name the same as the part number. And then, just to spice it up a little bit, we'll just add a compute every other one. So now it's just a question of making changes.

So let's say I want this to be a 2 by 4, so 1.5, 1.5. And then I can make these 3.5, 3.5. So do the same thing. Actually, I'm just going to copy this here. Boom. And then we'll make these, say, 7.5, OK? And then we'll do another thickness here, 0.75, 0.75 just to shake it up a little bit.

So that's how we can make all of this work together very efficiently in Excel. That set up row got the data in there that I needed. I'm using Excel functionality to make really clear, concise file names. Works great. So I save it, close it, and there you see it builds my states.

Oops. I forgot to rearrange these, so this is where we can just click on these, drag them up above the 2 by 4s. Now my 1 by 6s are above the 2 by 4s. And, whoops, we forgot the 2 by 6s. So we could copy and configure this, but it's just as fast to come back in Excel, grab these two rows, copy, insert them, and there we have it. And so we can now make these 5.5, 5.5.

But wait, it didn't change. I've noticed this quirk sometimes when I come back into Excel, it doesn't actually preserve the formula. It just is the text, except for, da, da, da, da, my setup row. So I can now take my setup row, and now it's going to convert to 2 by 6. This is still a little bit goofed up, so I just say equals again. What I've noticed as I do this the one time, I don't seem to have to do it again. And you see these converted to 2 by 6s.

So the setup row saved my bacon again. It just seems to be a really helpful approach, I've noticed. We'll save it, close it. And now, here's our part.

So the last little thing I want to see with these model states in the organization is if I jump into an assembly and I place it. So I'll find my model states. Here's my dimension lumber. And this is all you get. You have to pick it based on the name. So just make sure that you're picking a really efficient name, hit Open. And there, you can see it's really easy to control and place it. Of course, it can get intense if you have 10 or 12 different things you're controlling per model state. So again, that makes the naming even more important.

All right, so the next step-- this is where I find I channeled my inner soccer player and decided to call this one Bend it Like Beckham. But now, we're going to talk about taking a sheet metal part and how do we form it?

So one of the really powerful bits with Inventor is iLogic and the ability to grab the API. So model states are accessible via the API. And what's nice about them is they're just a collection of objects within the component definition. So you can access it either as a part, or you can access it for occurrences or documents in the assembly.

So if you want to see more of the code, please, take a look at the paper for this class. I've put an Appendix B, which lists all the iLogic rules in entirety. I'll reference some bits of code in the presentation, but you'll want to go to the report to get the whole list of code.

But just as a quick example of what I'm talking about, if you look at the left hand image, this would be accessing the model states within a part. So I simply look at the document, grab the component definition, and within the component definition is the collection of model states. And then I can access them in a number of ways.

If you look at the image at the right, this would be gathering it from an assembly. Pretty much the same thing, but I'm looking at the assembly component definition to get the occurrences object, the collection. And then I can cycle through each occurrence, get the document from the occurrence, and then check the model states.

We're going to do that a couple of times in this presentation. The first one, of course, animating the model state. But then later on when we work with Vault and trying to store those properties that have the model states into Vault, we're going to cycle through these again.

So once we've accessed the API, now we just make the magic happen. So we're going to utilize the code to animate the model states, but we're going to set a small delay, so it's not like-- b, b, d, d, done. So I at least want to see what's happening.

So the first step I did-- you can just find this on the forum. That's where I found it-- is we're going to grab a slight time delay. It's in milliseconds. So 1,500, 1.5 seconds. And then we're just going to go through each model state, as long as it's not the primary model state, then we're going to activate it. We're going to give ourselves a little delay, and then we'll activate the next one. And that's how we can watch this part being formed.

It's pretty simple, but if you're working with your fabrication team, can be really, really powerful.

So again, got a relatively simple example I want to show you. But let's dive back into Inventor, and we'll fire it up. So I'm going to go ahead and close this guy. Won't need that any more. Let's come back into here. So here's our simple box. You can see that we've got a whole slew of model states here, including the final design.

And what we're going to do is just animate them however, we want. So it's really important that you go through the order properly. I'm assuming it's a flat sheet. Then we're going to form this thing first until we get to the end. And what this will allow us to do is verify is that actually the way we want to form it?

So I'm going to go to iLogic, and in this case, I've embedded the rule. But it could be an external rule. And let's just take a quick peek at it so you can see what it looks like. It's, again, not very complicated. We're going to access, the document, the definition, the collection of model states, and then just create a model state placeholder.

We'll cycle through each model state in the collection, as long as it's not named primary, and I've left some code in here if you do use 2022 master. We're going to activate it. We'll update the document to make sure that that model state activation is visible. We'll wait whatever amount of time we want. I'll keep it at 1 and 1/2 seconds, and then we'll go.

So it's really simple code, but let's see it in action. So it activates the flat, and then you'll see it slowly flanges everything up. And maybe 1 and 1/2 seconds. I should have sped it up, but it works. So there you have it.

And what's really nice about this is I could manually cycle through that, but you could record your screen, email it to your manufacturing folks. And they can say that's crazy. We can't do it that way. You need to fold this thing before this thing. You would reorder these, and then we could run it again.

So that's the idea with animating model states. It's not complicated, which is awesome. But it can be super powerful to verify your fabrications.

All right, so we're done. No, I'm just kidding because I forgot it was 90-minute class. I wanted to give you some extra topics, bonus topics, if you will. I'm calling them extra fun. And so the first thing that I want to take a look at is how we work across models.

Some of us use the derived workflow. It still works in Inventor 2022, '23, but there's a quirk with model states that I at least want you to be aware of. Then we'll take a look at, maybe linking model states might work a little bit better as far as trying to tie designs together. So let's jump in.

So the first thing I want to touch on is, well, what's the quirk? Well, it's not a bad thing, but when you derive a design into another one, you're basically taking that state, moving it into the next design, and then you can design around it. So this is a great workflow for designing two parts that they're pretty intimately connected.

If you're an AutoCAD user, newish to Inventor, you could think of it as x referencing, kind of analogous. But the problem is, when you derive an original design into the referencing design-- so this is the new design. We're looking at this old design-- you can only bring one model state over.

So the issue becomes, if the original changes to a different model state, this derived design does not update. It stays pointed to the original model state that you used in the derived component, which is typically whatever is active when you execute the derive.

Again, this is not a bad thing, but it can be confusing because if you're not expecting it, things don't update quite the way you would think. So as an example, if you look at the image at the bottom left, the computer box is using the primary model state, or I'm sorry. The cover is using the primary model state from the computer box.

But if you look at the bottom right, if I change to a different model state in an assembly and the computer box is linked and can change with it, note that the yellow computer box cover did not change. And that's because it's linked to a very particular model state.

So what I would say with derives, again, not bad, but you need to be aware it can only view that one model state. So I would probably reserve derived designs more for that final design type approach that I mentioned earlier. The part is what it is at the end. That's definitely a safe one to link up using the derive tool.

So with all this in mind, linking model states now becomes a pretty powerful tool, especially if we're talking families of designs. It does take a little bit more work to set up, which you'll see in a little bit. But it absolutely can be worth it in certain situations.

Huge note, this will only work if all the model states are named identically. If they're not named the same, this does not work. So what it's best suited for is allowing rapid modifications for an entire configurations of design. So think of old iAssemblies, things like that, linking model states to make those types of changes very quickly.

But it can be a bit tedious to set up because, if you think of a top level assembly that has subassemblies and subassemblies and then the part, I actually have to link the part to the subassembly first, then this subassembly to the next subassembly, and on and on until the top assembly.

So it can result in a fair amount of linking, but let's take a look at it. So I'm going to show you the limitation, and then we'll link some model states together so you can compare and contrast the difference.

So jumping back over to Inventor-- go ahead and close this one. Well, sure. Oop, so here is the original device I have that's using this computer box cover as a derived design. So everything seems awesome until I switch. And now, when I switch to a different model state that's linked up to this foam and this green computer case, the yellow piece does not move with it.

And the reason it doesn't move is because, if we look at this computer box cover, it's using a derive. And if we edit the derived part and take a look at what's going on inside, when we look at the representations for the derive, it's only using that primary state.

Now, I could still switch it to a different state. But now, if this part's being used in other designs, it just starts to become a mess. So really, again, like I mentioned and I want to reiterate, I would probably reserve the derive for the final design type components.

So if we know that the hammer is exactly the way we want it and now we want to design the over molding, we can derive the hammer handle in and, with confidence, apply whatever over molding we want. That's a great use for this.

But what I think might be a better fit for something like this-- and I'll just go ahead and-- sure. I guess maybe not save them, save some time-- is here's that same device. But now, this part I've designed, it's not derived. So now it's independent of the computer box, and now we can do things like this. When we switch it, we can link the model states so now all the parts grow at the same time.

So if you're not familiar with linking model states, I'm going to walk you through a pretty brief demonstration of it, which will illustrate the technique. Also might show you how you could see it getting tedious. But let's go ahead and give it a shot.

So I'm going to right click on the box length 18, and I'm going to copy. And one of the reasons I want to show you this is this another thing that has tripped me up-- and I've seen it trip up students and customers as well-- is, when you do the copy, it's really great at keeping most of the name, but it didn't switch.

So that is something to note because you may end up editing the wrong model state. So I'm going to come over here and rename this one because, remember, the name is super critical. So I'm going to go ahead and rename it, and I'm going to control A, control Charlie to rename the model state.

Reason being, I can now come over here, and I'm going to create that same model state-- whoops. There it is, ha. Going to create the same model state here by copying and pasting.

Now, another classic Pete move is I make the model state, but I forget to actually edit the data. So make sure that when you're linking you actually activate the model state, come up here to your parameter table or whatever it is you're changing, and we need to actually change that length.

So now, when I go to the link, it won't be like that bum, bum, bum, moment. It'll actually change. So I'm going to do the same thing with computer box and the foam.

So again, this is real life. I have to do this for every single model state that I wish to link. So it just takes a little bit of time, as you can tell. So it's not bad, but this could be part of the tedium. Of course, if you really get into iLogic, we might even be able to speed this up a bit as well. But we're not doing that. So here we go.

So I go up here, and I change this to 24. Woo, all that work, I think we're ready. So if I go back to the device, now I can do the final bit, which is linking the model states together. So I click on this underneath the productivity tools in the Assemble tab. They have tons of really great tools in them.

We're going to look at linking model states for now. Grab the link of the model states, and you say which assembly level model state do you wish to link? I want to link the 24 inch.

So it says, hey, are you sure you know what you're doing? We're going to change the model state. It's going to be linked. It's going to save the document. Yes, yes. So it'll save it, switches to 24. You see it, everything updated. That's linking model states.

So again, that behaves probably more what you're used to with the derived design, in other versions of Inventor, but linking could work a little bit more slick in 2022 and 2023.

So I'm going to go ahead and save those. Yes, and then we'll close these guys as well. Excellent. So extra fun topic number two, what do we do with our old assemblies? We had LODs, levels of detail, and now that level of detail is gone. How do they work with model states?

So this is a question that has come up quite a bit the last year. And I've got several videos on our YouTube channel about it. But I want to give you the overview.

So just as a refresher, if you're not familiar, LOD means level of detail. And when you take an old assembly, your levels of detail get converted into model states of the same name.

So one of the things to be careful about with these levels of detail is they were super helpful in many ways when managing large assemblies, but there's a really, really, really big thing to note when you're working with model states is that, with level of detail, you could suppress a component, and it would still get counted in the bill of material.

However, with the introduction of model states, when you suppress a component, that quantity goes to 0. So it's a very different behavior from level of detail.

So the challenge is, when I convert a level of detail into a model state, it still wants to count all the parts because that's what it was used to as a level of detail. So the only way that that would work with model states is when you activate the bill of materials for a converted level of detail, it's going to launch the primary model state. That may not be super awesome if you've got a large assembly.

So that's not really super great, but all is not lost because we could take that level of detail that got converted, and we can still place that assembly using the custom LOD as a subassembly. And it will report all the parts but not have to load the primary assembly.

So it's a really nice workaround if you're going to use this as a lower level sub and you're going to move it into upper level assemblies. We can still make use of that converted level of detail.

So just a couple of images you see at the bottom left. That's me taking an assembly, placing it as a subassembly into an upper level assembly, looking at the BOM. I'm using the converted LOD, and it still shows all the parts. But I didn't have to activate the primary state.

And that also would work if we use the simplify tool and created a substitute. We can also get that same bill of materials achievement, which we'll see in just a second.

But there's another question that comes up. Well, I get what I can do now with the converted LOD, but I actually want it to behave like a model state. So if I suppress a component, I want that to 0 out in the BOM. Is that possible?

The answer is yes, and thankfully, it's super easy to do. All you need to do to get a converted LOD to behave like a model state is to copy it in the browser. That's it. Now, I take the extra step of renaming it so that I actually know it's a model state versus a converted LOD. But it will behave exactly as a model state should, or at least you'd expect it.

So let's take a look at it. We're going to jump back into Inventor. I'm going to show probably one of Autodesk's oldest data sets. It's been around a while. And we're going to take a look at how does this work?

So you can see it's an older assembly because there was a medium level of detail. So I can activate that. And it'll just take a moment or two, but hey, there it is. So you can see that some of the parts are suppressed. Awesome.

Now, with level of detail, prior to 2022, I could click here, and I would see all of the parts. But now with model states, it'll say, well, I can do that, but in order to do that, I'm going to activate the primary state. No, I don't want that. So I'll say no.

So while it's not as useful in the assembly itself, it can be super helpful if we build an assembly and place that as a sub. So I'm going to place this one, find my blower. And before I place it, I'm going to look at the options. And I can see which model state to place. Perfect, medium LOD. Go for it. Hit Open. I'll just drop it at the origin, like I do.

And now, when I look at the BOM, sweet. It didn't ask to activate the primary state, but it still shows all the stuff. So pretty cool. And that works out really, really well. Super easy.

We can also use this converted LOD to create a substitute. So substitute model states work the same way as substitute LODs did. It replaces the assembly with a part. So I'm not going to get into all the nuances of the simplified command, but I will give you a quick example is this allows me to refine the design even more. For example, I can remove all holes.

So not only will it allow me to suppress components, but I can remove holes I don't want and keep the ones I do want. So I want to keep these holes here so that I can attach stuff to the end of the blower if I want.

So I'm not going to worry about the naming, all the other settings. I'm sure there's other great classes that talk about the simplify tool. I'm just going to hit OK, knock one out. Cool, so now we've got a blower main. And notice, there is even more simple. There's no holes in it except the ones I want wanted to keep.

Jump back over to my assembly. Let's place this guy. So again, the same thing. Make sure that I'm grabbing the substitute, hit Open. And notice the difference, subtle, but it's placing a part.

When we look at the BOM, however, interestingly, it just tells us there's two subassemblies now because it's exactly the same roster of components.

So the moral of the story here is that, while the converted LOD's a little bit of a pain. In the host assembly, it's extremely useful when we work with it as a subassembly. But the last thing that people ask me about when it comes to the converted LODs is, well, how do I make it act like a model state?

So again, it's really easy. What we need to do is take the model state we wish to emulate, or I'm sorry, the LOD that we wish to emulate as a model state. We just copy it, come over here, click on this. And I'll just rename it so that we know it's the medium model state. And that's it. That was not difficult to do.

And as soon as we hit the BOM, it's not asking about the primary or anything else, and all of the components that are suppressed get zeroed out. For example, here's the motor assembly. It is definitely not there, so it's 0.

So those are just some of the things you can do with the converted levels of detail. Pretty straightforward stuff. Works really well as a converted level of detail. As a model state, just a couple of things to be aware of.

And the last one, I've maybe saved the best for last. My last extra fun topic is how do we track the model states in Vault without having to use Vault items? It is possible.

So this is probably the biggest question slash limitation I get asked about. I don't know if it's every class, but it feels like it's pretty much every class. How can I tell which model state is being used in an assembly?

So the problem that arises is Vault looks at the component that's being used, but it only shows the primary model state properties. An additional kind of challenge with that is what if I used four different variations of a part? Well, it's still only lists the one part in the Uses tab of Vault.

So it's kind of a challenge. And if you look at the image on the left, you can see what it looks like in Vault. The assembly uses the dim lumbar tester. The part number is dim lumber tester. Great. But if you look at the image to the right, which is the browser and the four pieces of wood, I'm using different model states in each one.

So in the Uses tab of Vault, it's just not clear at all what's happening. I know that I'm using the part that has model states, but I don't know which model states are active. So that's the challenge.

The solution, or at least a solution, is again, using our friend iLogic and the Inventor API. We're going to gather the active model states, and we're going to see if they're the kind of model states that we want to report.

So just like I showed you before with the animating model states, we would cycle through that entire model states collection. But this time, we're looking at an assembly, so we want to look at each occurrence within the assembly and see what the model state is.

Now, caveat, I'm only searching the top level assembly. I'm not looking at subassemblies or leaf components, if you know what that means, because I figure you would do this at every assembly level. So I'm only searching through the top level assembly at any given level.

What we're searching for are unique, active model states. What I'm not looking for are things like the setup state, the primary state because that's confusing. The final design state, because if a component just has the final design state, well then, the component name is the final design state. There's no unique variation, if you're following the same kind of convention that I mentioned earlier.

So we search through all the occurrences, check to see what the active model state is. And then we're going to take that and populate it into an array list. So we're going to grab the component name, the actual file name, sans the file path, and then we're going to add the active model state into one string and store that into an Array list.

Using that array list, now we can report that data and Vault could see it, potentially. But where should we put it? Well, after doing some testing-- and I have a big kudos to a gentleman. I'll share that in a little bit.