Reliable Modeling Techniques for Complex Part Design in Inventor

PAUL MUNFORD: Good. So the doors are closed. We're all set. So thank you very much for coming on this morning. So I'm over here from the UK. I'm kind of jet lagged and a bit tired, so if I fall asleep up here, you can always leave quietly and leave me to it.

So we're talking today about reliable modeling techniques, and this class has come out of me being basically very lazy. I'm just about old enough to start it off drawing by hand. And I loved our hand drawn stuff, but when AutoCAD came along, I realized I could be more productive. So when I saw Inventor, I was like, I want to get hold of that, because I want to be more productive again.

But when I started learning Inventor, I realized that actually it takes quite a while to model something up before you can to drawings. And before you get to that downstream building materials and stuff. So there is an investment to make. And I learned that if I model badly, I'm going to spend a lot of time cleaning stuff up. It's kind of wasted time.

So I began to research good modeling technique and good modeling practice, things like that. Bourne Technique, if anybody's heard of that, and horizontal modeling, and all these different techniques that are out there. And then just recently, I joined Autodesk. But previously to that, I was working for a reseller for a couple of years. And so I'd do advanced part modeling classes, where I'd try and take some of what I'd learned, and encourage my students to try it out.

So this class is filtered through what I learned by teaching them. I learned I'm basically very OCD, and some of the stuff I do, people won't want to do because they're not as methodical as me. But I've tried to boil it down to the things that people found kind of easy, and they found that it was very easy for them to apply back at the office.

So I always like to start by showing the learning objectives, just to make sure everything is in the right room. Autodesk University's-- there's too many good classes here to be in the wrong place. If the class is too simple too complicated, go to another class. Your time is valuable.

But our learning objectives today, we're going to take control of our parametric relationships. We're going to learn how to build complex parametric parts, and we're going to learn how to document our models so that when our colleagues come along, they know what our intention is. And I've said it in here, take away best practice workflow that can become your office standard. That is mostly tied into the handout.

So the handout kind of got away with me. It's, like, 50 pages long. So please feel free to download the handout. You can crib anything you like from the handout and reuse it in your office standard. I'm absolutely fine with that. So take a look. You can get them from the AU app, or I've put a couple of Dropbox links here. So if you want to follow those, you can get them downloaded. And I've also modeled up a whole bunch of examples in there. So you can download some of those and look at them.

Most of the part files, I've done a sort of top down multi-body assembly in there, as well. So you can take a look at that. So please feel free to download, and let me know what you think. I'd love to get your feedback.

Included in that handout is two checklists. So one checklist-- let me just see who here is like a CAD manager or a CAD admin? So this checklist is for everybody. This is for things you can do in the template, and things you can do in the application options to make it easy for people to use your standard. Because we all know if we give him a 40 page CAD standard, nobody is going to read it.

So if we can build stuff into our template to make it easy for people, we stand a better chance that they might use them. And there is one template-- one checklist here, which is for people doing the modeling. Yeah, so you can be methodical when you're modeling, look down the checklist, and see what should I do, and in what order? So we can try and encourage people to use a standard that way.

OK, so when I was teaching Inventor, I quite often asked people at the beginning of class, so what do you want to get out of the class? What do I need to hit? What are my goals for this class? And most of the time, people would say, I just want to know how to use Inventor properly. And I'd be like, well, I'm sorry there is no proper way to use it. It's a tool. You can use it anywhere you like.

There are lots of things we can do in Inventor. There are lots of different ways of working, and they were all correct given the right context. So I tried to think of a way that I could quantify a well modeled part, so we could have that common goals. So we understood we were shooting for. And I came down to two criteria that I felt were really important to a well modeled part.

One is, obviously, going to be the correct geometry. Because if we don't have the correct geometry, we're not going to get the parts made that we want to get made. So this is a given, right? We all know this one. And I felt the other one was that it's easy to update. Because if it's not easy to update, then we're going to spend a lot of time wrestling with it, we're going to lose a lot of time, we're going to waste a of time but ultimately, we're not going to use that component anywhere else, either.

So these are the two criteria we're shooting for. So the end of today's presentation, I'm hoping that you have learn some ways to make a good model part, but also a part that's easy to reuse. So parametric modeling is really good for things like families of components. So we have a parameter, we can change a size, we could create a file, copy it, paste it, change a parameter until get the next one in the family. So really good for families of components.

And it's really good for configurators. So building in iLogic, iParts, iAssemblies to better build something that can become any one of the multiple variations that your customer would like to have from you. And configurators are particularly good if you're working with people-- perhaps people in sales, or your sales engineer, and you need a very quick way to be able to create an output for a customer.

So that's what parametric design is good for, but parametric design itself has problems, right? And the main problem that people have with parametric design is the fact that we kind of need to model, not just in three dimensions, we kind of need to model in, like, four dimensions. Because we're modeling in change. We're modeling in the opportunity for this part to change over time.

So we need to make this part predictable in its behavior. So I think productivity in Inventor is a little different. Productivity in AutoCAD, and we match the keys faster. That's how we got more productive. That's how we got stuff done. In Inventor, it's a bit more like playing a game of chess, right? The further we can think ahead, the further we can plan ahead. And the more productively, more efficiently, we can work.

So creating successful parts-- parts that change without falling apart is about planning and about working methodically. So, the problem with parametric modeling is unintentional relationships. So if we are creating relationships, it's very powerful, but if we're not thinking about relationships we're creating, coupled with regeneration, means that we have an unpredictable result. We don't know what's going to happen.

And feature regeneration is something else it took me a while to get my head around. When we make a change to a part file in Inventor, we're actually not changing the part file, we're actually asking in vain to take a look at the recipe. So the feature tree is a recipe, and it's actually building that part, again, from scratch. So every time I make a change, it's actually going through all those recipes we gave, and it's building me a brand new file.

So every time I make a change, if it's an unintentional relationship plus everything is going to be regenerated again, that's where I start to get unexpected results. So, updates can become unpredictable. Our intention for that design, or prediction for how it should change is lost. We spend a whole bunch of time fixing things, and we'd rather rebuild it and reuse it.

So how many people would rather build a part from scratch and know how it's built than use somebody else's part. Yeah, most of us. And we all know who that colleague's part is that we won't touch. But that's not saving us any time. The benefit of using CAD is not that it lets us design faster. The benefit of using CAD is that we can copy and paste, right?

So when we are drawing by hand, actually making a change took as long as it took to do the drawing in the first place. CAD should all be all about we start by copying and pasting an old project. And if your old project is-- if you don't trust your old project, you're not going to reuse it again. you're starting again from the beginning every time.

So reusing rather than rebuilding is our goal. So we're looking for editable models where the design intent is captured. So there's a change going to happen. It's a predictable change. And we can see what our predictable change is. We don't need to manipulate.

We're looking for obvious models where the design intent is documented. So we can come into somebody else's model and we know what we should manipulate to change that model. And I always come back to this-- it could be you. It could be you who comes back to that model in three months and says, what was I thinking?

So you want the design intent to be documented in such a way that it's obvious. And we want our models to be reusable. We want to say, I'm going to start a new project. I'm not going to start modeling anything. I'm going to go into the server and find out what we got ready. Yeah, because I'm so confident our part modeling is great. I want to reuse that stuff.

So I thought I'd just try and define what a complex part is, or what a complex part means to me, when we're having this discussion. So the part on the left, I'd say, is complex. It's a mechanical design. There's lots of elements. The part file itself can have a long feature tree.

The one on the left here I'd say is complicated. So this is actually a seat from a motorbike I was working on with a customer. So this is all surface modeling when we're looking for good continuity between surfaces you probably can't make-- or it's very difficult to make something that's both parametric and surface modeling. We break a lot of rules when we're doing surface modeling.

So we're really looking at today-- we're looking at these complex components and how we can be more methodical in restructuring these. So what makes a part complex? Well, I figured multiple sketches. Multiple sketches work planes. Multiple features-- the more features we've got-- like if you've got two or three features, it's not only difficult to work out how to change this part, but if your feature tree is getting so long it comes out the bottom of the model browser, it's probably going to be more difficult.

Multiple bodies. How many people using multi-body modeling. Yeah, awesome. About half of you. It's a really cool technique if you're trying to model something complicated to create all those relationships within one part. But it can get out of hand. I found one of my old parts that had 258 bodies in it. And you needs to be pretty methodical if you're going to cry a part model at me.

But here's the key one for me-- multiple updates. So if you're modeling something that's maybe a supplier's component, it's not going to change. It doesn't really matter, like, how you model it because it's static. Once it's done, it's done. If you're going to live with this component, and you'll design like this-- three months, or six months, or 12 months, or 18 months. You're going to come back and do multiple updates to this component. You really want it to be done in an obvious, clear way. So that every time you come back, you don't have to figure out, again, how it was put together.

So I think multiple updates is the key one for me here. So here are some rules. Here some relationship rules. So this is my checklist for you guys. If we want a part to be successful and predictable in the way updates, first thing is no unintended relationships. So we're not just going to slap sketches on faces and not really think about it. We're going to think about those relationships and make sure that they're there for a reason.

Relationships should be kept to a minimum. So one of the techniques I mentioned there is a horizontal modeling technique. I'll talk a little bit more about later. And I have put links to these in the handout. So if you're curious and you want to know more, check out the handout and follow the links.

But relationships kept to a minimum. So perhaps instead of putting that sketch on top of another feature, we could put a datum plane in there, which isolates feature number one from feature number two. So feature number one goes away. Feature number two is fine. Because it's not reliant.

So if we can minimize relationships, that's going to make things a little bit easier. All relationships are there for a reason. They're planned. They're purposeful. We're in control of them. And all relationships are obvious and easy to understand. So this is in our planning. When we think about part modelling, this is the kind of thing we need to be thinking about.

I wanted to clarify what I was talking about when I mentioned design intent. So this is example I used to use in training. I'd say, so imagine you got a little plate here. It's like 50 ml by 50 ml, it's got a hole in the middle. And when we open it up, we find there's a parameter in there. Somebody called it length. So we think, awesome, I need to change the length. I'll go in there and put a different value in.

So what do we expect to happen? In which direction do we expect this plate to get bigger? Like this way, or this way, or this way? And what happens to the whole? Does it stay in the middle, does it go to one end, does it go to the other? So I'll get the guys to open up a whole bunch of examples I created, and I say look, these are all legitimate results. Nothing failed. Something predictable happened, but perhaps it's not what we expected.

So design intent is us deciding what could change, and making sure that we've planned for that so that when it's changed, the expected thing happens-- or something predictable happens. That's what I mean by design intent.

OK, so first I'm just going to walk through some last set ups. Some of those things we can do with our templates, some of those things we can do with application options. And again, there's a checklist that goes with this bit. So if you are an account admin or an account manager, or you're in charge of a templates, take this away, and take a look at it.

The first thing is orientation. So traditionally, in engineering drawing, we draw from the front. Yeah, so the xy coordinate is looking at the front, and the z is kind of in and out towards you. So y points upwards. Now for anybody who's come from AutoCAD background, you know AutoCAD works like an architectural package. Architects draw from the top.

So xy is kind of more like side to side, and front to back, and z is up. So why does that make a difference? Well, Inventor is set up like a traditional engineering package, so that's fine. If you are working with people in the construction industry and you're sharing files with AutoCAD or Revit, you might want to set your template up so you've got the z up rather than the y up.

It's just going to save you time when you're sharing files. Instead of every time you share a phone to Revit, comes through on its site, then you can have it come in the right way up. The changes in your template, you just get your orientation you want, right click over the view cube, choose Set Viewers Front, or Set View as Top, then you save it as a template.

And I'd given more detailed instructions how to do that in the hand out. So that's one consideration. The other consideration is the workplane. So the origin planes are absolutely awesome, because you can't delete them. They're fixed. So we always want to refer back to the origin planes when we're creating our particle. Because they're nice and stable. They can't go wrong.

But what we can do is we can rename them. So here, I've renamed my origin planes to share the same name as the view cube. And it's just one more thing we can do to encourage our users to model in a more consistent fashion. So we're saying this is the top view. So if you're going to start your part model from the top view, choose the right plane.

I didn't change the yz, xz, or anything the default names. I. just appended the view, because I went in and there were brackets. So that's something else we can do. And, again, we choose File Save as Template. The template you want to write over. I hope everyone knows this. It's the one called Standard. Does that make sense to everybody?

Whenever you click on the New Part tile, or you're going to the Quick Access Toolbar and you click on that little drop down. Allows you to create new part, new assembly. The template it's using is the one called Standard. So that's one you want to write over so that everybody's using the same template.

Parameter names. So I'd encourage everybody to name their parameters, so it's obvious what their parameter are doing. I don't encourage people to create parameters at the beginning of the modeling process. I'll talk a bit more about that later. You don't have to have a consistent parameter naming scheme in your office, but I think it helps.

So I think it helps if you can get everybody together and say, look, there's a few things that we can do. Let's agree on the best practice that we can all follow, I think that's a good idea.

So when you're planning how your parameters should be named, don't forget they're case sensitive. So you can have links in lowercase, and your links in uppercase, and eventually to do that, but it's probably not a good idea. So remember they're case sensitive. That's important, also, if you're trying to type parameter names in later to remember which is case sensitive, which isn't.

They have to start with a lector. She might notice by default, they'll be D1, D2, D3. So they'll have to start with a letter, but they can include numbers. So your parameter name could be-- start with a letter that has numbers. And parameters can't contain spaces.

We can use two special characters. We can use the underscore character, we can use the colon character. So if I said, these are some examples of parameter names, they're all kind of, like, that's controlling the overall width of the parts. So they're all good. They're all legitimate. They all make sense. They'll all be accepted by Inventor. But if you wanted to have some consistency, you could steer people towards like, we always use underscores instead of spaces. That's the way we do things here. OK, that's maybe something you want to think about, put in your case standard

And then features. So I'm a big fan of renaming features. So it's really clear and obvious what each feature is doing. But you'll have found, you can't give two features the same name, even if they're two features of different types. So I tend to have to put on the end of an extrusion, I'll put ext. to remind me it's an extrusion.

I might put cut, if it's a cut extrusion, just to remind me what it's doing. Radius, and fillets and revolves. So maybe, again, that's something you could standardize and have in hour CAD standard and have some consistency there. Give people some guidance on the best practice.

And then this is actually an application option. How many have found this-- show extended names-- how many people have found that in the past? Oh good. So only a few of you. So to lots of you this is new. So this is an application option, but the easiest way to get to it is actually in the little hamburger menu.

And you come down here and choose Display Preferences, Show Extended Names. And you get this section hey I've highlighted in brackets afterwards. So, for example, if you've created a hole, it tells you that it's an M16 hole. So you don't need to measure it or go and do a feature to see what size a hole it is, if you've got to change all the M16 holes in your feature tree, you can easily go down there and see them.

So this is adding clarity to our feature tree straight away. We don't have to do anything. Just set and we turn on. So I'd really recommend you turn that setting on. I remember that's an application option. So you'll need to make sure it's turned on each machine. It's not set in the project. It's set per machine.

So I wanted to give a bit of advice on relationships. When we're creating these relationships, and we're thinking and planning about these relationships, there's an order of preference in which we can create relationships. So the first one is parametric, which shouldn't be any surprise. Because Inventor is software, it runs on a computer, it's really good at math. So we can cry a mathematical relationship between two parameters is going to work that out super quick. So that's always the best way to create relationship if we can.

Sometimes we can't. Sometimes we can't think of a formula that's going to government a relationship between two features, so we start to use geometric relationships. Now if we're all going to use geometric relationships, I recommend going sketch to sketch first, if you can. So have one sketch drive another sketch. Because this is the simplest relationship for Inventor to work out. So this is going to update faster, and it's going to be more pleasant to work with.

If you have to, sketch the feature. This is wrong. There's nothing wrong with doing this, as long as you plan for it. As long as this is your intention. You did it on purpose. So if you need to, put a sketch on another face. That's fine. And then the most complicated one is feature to feature. So if you don't like an-- is the film too extrusion?

So you have to make sure that all the features that was going from are going to regenerate successfully. All the features it's going to could regenerate successfully, and then it can be the feature cost. So not only is it more difficult for Inventor to calculate, but it's more work for you to maintain two sets of features to make sure they work.

So again, it's not wrong software like you do it, but be wary of that, and make sure you've planned for it. Make sure it's there on purpose. You did it for a reason.

OK, so that's the setup. Now we're going to talk about the work. So working in this methodical manner. So again, I produce a checklist here. Feel free to take a copy of it. Feel free to give it to your users and see what they think. See if they find it useful. I'm a very methodical worker. Some people don't like this. But I can't help myself.

OK. So my first piece of advice, when you're sitting down to model up a new part, before you start, stop.

We're not going to get anywhere if we treat it like AutoCAD and just jump in and start modeling stuff. Because we're going to get down to the line, and then we will realize we've made some mistakes or we made some bad relationships. So remember, it's like a game of chess. The further ahead we can think and plan, the more accurate, or more predictable, our results are going to be. So I'd encourage my guys to sit down, maybe even do a couple little thumbnail sketches. Maybe think about some parameters they needed, and start thinking about how they're going to build this component to be predictable.

I think even a day's works worth spending 20 minutes just thinking about it if we start planning ahead. So when we're thinking about part we're going to model, we need to make some observations. So one thing we can observe is This Orientation.

In which orientation do we want this to end up when we're finished? What are we going to call the front here? If we can get it in the right orientation the first place, it's going to save us time downstream, so we're not going to be constantly reorientate it.

So, which side is going to be the front?

The origin. So we mentioned there that the Origin Planes are really stable. So we want to model around the Origin Planes. But that Origin, that 000 in Cartesian coordinates-- where does that want to be on our part when we're done? Is there, like, an obvious and clear place where the Origin should be? Do we need to consider downstream processes, are we going to hand this part of to a machinist? Could it be helpful for them if the Origin was in a particular place?

So we want to have a think about that. Thinking about those feature names, right? So we're going to rename these features. So let's think about, can I identify each feature on this model, and give it a name, like Boss 1, Boss 2, Boss 3 is not going to help anybody out, so I need to better think about feature names. And then parameter names.

So let's think about that. What named parameters could I build in to show my design intent, and how I'm going to name those. And finally change. Can I predict change on this part. Can I build in some predictable change. We can't predict everything. Somebody is always going to throw something at us we didn't expect, or the client is going to ask for something different, and maybe it's going to be a rebuild. You can't help that.

But ahead of time, can we make some predictions? Like one of the best benefits of working with Inventor, is we don't have to have finished dimensions when we start modeling. Because we should just change dimensions when we're done and do any final tweaks. So I want to make sure that change is built in.

And so just to dig into a couple of those a little bit more, so orientation begins to give us more information. So if we decided which is the front, we could start to name things like parameters, things like width, and depth, and height. So we start to give ourselves more information. When we're thinking about that Origin, again, is there an obvious and clear place around which we want this part to change?

Often, is right in the middle. And I think anybody would agree you model around the origin, model around the origin, have the origin the middle. Can anybody think of reasons why that's important? That's it. So I got both answers. Perfect. One is symmetry. If my part is symmetrical, I can use those origin planes to mirror features back and forward across the origins. And then the other one is downstream. When I place this component into an assembly, I can then start to use those origin planes for constraints.

So often the most obvious place is right bang in the middle of the part. Sometimes that might make sense if a part changed in a particular direction. So have a think about that. Is there an obvious place for the origin? And then parameter names. So I just did a little animation, this one. Because I want to make sure we know how to do it. But creating named parameters before you start.

So you can name parameters as you go along, but the downside of that is if you delete the feature, you'll delete all the parameters that go with it. So if you've got parameters that you want to control your main change your main datums in your component, it's a good idea to create some named parameters first. And then as your modeling, you can reference those named parameters. You want to get them all to the game with-- you may have to go back in and add some more later on, that's fine.

So next one is layout sketches. So remember I was saying the sort of second best feature relationship we can create is sketch to sketch. Now when we are teaching Inventor, we quite often say, one sketch per feature. Who's heard that? One sketch per feature. All right. The idea is that you've only got one loop. So if you make a change to that, Inventor can't accidentally pick the wrong one.

As we get more advanced and more confident, we start to create more complicated sketches, and then what happens is we get a break or we get an overlap, and Inventor can't find the loop that he was trying to use, so it picks the one next door, and it just blows everything up. So keeping sketches simple is very helpful, but it's also, then, very difficult to coordinate and make sure everything's parametric. So the idea is here that we have a datum sketch, and a datum sketch is controlling our main feature positions. In this case, you can just about make out a construction line that it's a square.

So those are my main datums-- those four hole positions I want to control. And then I've added in additional sketches. So each sketch is quite simple, but it's being controlled by the layout sketch. So I've done another slide here to try and illustrate that. Just make sure it's clear. So my datum sketches are controlling the main sizes, and then my feature sketches can be very simple, and they get pushed and pulled around.

And the nice thing about this is, all of this can happen at the top of the feature tree. So anybody coming into my part, can see a bunch of sketches. They can very quickly work out which sketch is controlling which feature then I have to kind of mind down through the feature tree to try and work out which sketch they got to change.

So I'm encouraged with these last sketches, and then comes datums. Remember, again, this is that horizontal modeling technique where instead of building a feature, then building another feature, and building another feature-- imagine that instead of being like a recipe, I imagine that like a Jenga tower. That game Jenga where you pile the bricks up on top of each other, and you poke a brick out and see if it falls over, well if we're creating features just slapped on top of each other and you change the bottom one, no surprise, all the features above it are going to be wobbly, too.

So if we can use these datum planes-- in this case, I've used work planes that are being controlled by my layout sketch, I can have a sketch on each datum plane, and if one feature I suddenly decide I don't want it, or I make a big change to it, it's not going to have that downstream ripple effect. So this is more methodical, it's more disciplined, but you'll end up with something more reliable in the end.

The next thing I want to talk about is the order in which we do things. So I think it's really helpful to work in this sort of methodical manner where we build, in this case, we build all the features that add material first. And this is about feature relationships and making sure we relate the right features together. So you may not end up with the features in this order, but I recommend when you're thinking your way through the modeling process, you think OK, so I need to add some volume here, and add some volume here.

Once you've done all the add features, then we would use the end of part marker to move the featured tree up and down. Has anybody used the end of part marker? Good. Yeah, you move the end of part marker up and down, and start the modify features. So this is to make sure that we're not putting like fillets really early, we're putting shells really late where they're going to cause problems. We're putting them in the right place in the feature tree.

So the Add group and the Modify group and then the Remove group. So this is things that remove volume. And then Patterning and then Edges. And again, they may not end up in exactly this order in the feature tree, but I find it very helpful to go through methodically. You'll notice there's one weird one which is fillets, which are in two places.

So the fillets, I'd encourage you to keep right at the end those sort of edge breaking fillets we just put on at the end just to kind of save the off edges and stuff. Why does anybody think we'd put those on last? Gavin?

[INAUDIBLE].

That's it. So when you create a sketch on a face that hasn't got any edges because they've been removed by a fillet, not only is that fillet starting to control the position of your sketch, but if you went in and suppressed or deleted those fillets, then it also blow up the sketches on that face. So it's always a good idea to leave those at the edge breaking fillets to last.

The fillets I've put under Modify are more kind of structural, more constructive fillets. And you'd see that if you take a look at some of these samples. Now there is a modeling technique they call Resilient Modeling Strategies. Has anyone come across that one?

So there's a guy called Dick Gephardt, who's taken a lot of this stuff and he's built this amazing document. It's actually on our website. You'll find if you Google RMS.com-- RMS.com in the UK. And one thing he recommends is actually grouping those features together in that order I just discussed in the feature tree. Now we don't have folders or groups in Inventor. So I just dropped like a 3D sketch in here to identify the groupings.

I found in practice when we're teaching this that this kind of works for mid-level complexity components. And it does add to that being able to read the feature tree correctly, but I also found that once you start game really complex that people find it too much to think about. Because they're really thinking about the order. Trying to get things in the right group game, which is one too many things.

But where I have found this technique really useful is a multi-body modeling. So I can drop a sketch in, name that sketch to group together all the features that are going to belong to a body. And I find it much easier, then, to skim up and down the tree and work out which features belong to which bodies. So I'd be curious now your feedback on that one.

The reason I dropped the slide in was because you'll see all the examples I've done are modeled in this way. So I'd like to know whether you find that useful.

And then something really important I want people to do-- let's see if I can get that to go. Flex. So flex is a term that I've nicked from the Revit guys. But the idea is that you don't wait until you need to change your parameter to check it's going to work. You check it as you go along. So you put those parameters in at the top level, you put those named parameters in. You start creating some sketches, you change your parameters, and just check that all your sketches relate, and things update.

You build a few more features, you change the parameters again. Just flex it. And just make sure your design works. Because what you don't want to do is just assume you did a great job of building a parametric part, and then, again, it could be you who jumps into this part in three months, makes the change, things explode, and you can't remember what you're thinking. So don't leave any time bombs in there they're going to go off later. Check your part before you finish work for the day, and just make sure it does behave in the method you predicted it was going to behave in.

And then the last tip I want to give people in modeling is, again, use that end of part marker. So I do this anytime I get a file from anybody. I'll just grab the end of part marker, slide it up to the top, and just roll it down a couple of features at a time just to learn how that person built their component. There's always something to learn, sometimes it's-- I'm not going to do that. It's always something to learn. But I'll do this in my components, as well.

And when you finished a job, and you take the end of part market to the top, and you roll it down, you're looking for-- could I use fewer sketches? Could I use fewer features? Could I model this in a more efficient way? And you might not have time to go back and change it. I appreciate that. We're all busy. But you'll learn something that you can apply to your next job. So I think it's good practice just to suggest this.

I don't know if you noticed in the animation, you can just select on something, right click, and just move the end of part marker straight up. But watch out for that one down there. You can see that. Delete all features below the end of part marker. Watch out for that bad boy. If you do that accidentally, do a Control Z straight away and you'll get your features back. But don't do a save. If you do a save, you just lost your work. So just be careful.

OK, we've talked about the setup, and what we can do to help our users follow this advice. We've talked about the methodical advice when you're actually working, and then the final step is the documentation. So how do we make it obvious and clear we've built this design intent. But how do we make obvious and clear what the design intent is?

So the first thing is, again, coming back to those naming the features. So we talked about having some sort of convention for the way you name your features. And we talked about thinking about it before you start and making sure you've got a descriptive name for your feature, and then when we're going through, I would suggest you rename features as you go. Like, don't leave it all to the end or it's just a bit of a boring task.

But we have this consistent naming scheme. So I've called my solid here Boss, so I know that the whole belongs to the Boss. I know that extrusion is built on top the whole, is built into the Boss. So I know that all these features are related. And one nice feature if you're using one of the recent releases of Inventor, is that we can now search the feature tree. So we can't group it, or we can't put it in folders, but what we can do is click on this little spyglass at the top here and type in a search term. It just shows all the features that contain that search term.

So if you've got a consistent naming scheme, it's a really quick and easy way again, particularly if you've got a feature that goes off the bottom of the browser. Instead, of having to scroll up and down, try and find it, just type in the top. Just find it that way. So there is a benefit that will help people if you're trying to sell it to somebody else, will save them time later.

Next place we can document. In our parameters, we've got this comment section. And again, I always encourage you to add a comment to remind you. So our parameter naming-- we can follow those conventions, but you know if you want a better type parameters in as you work, you're going to keep those names kind of short, and it can get a bit obscure as to what that premise is actually doing. The parameter names themselves can get kind of obscure.

So put a comment in it, again, to remind you. Put a long form comment in there that reminds you what you were thinking when you created that parameter. Because again, it could be you who has to come back in like six months and work out what you meant. And I would encourage the people using these parts downstream, before they fiddle with anything or do anything, just open up the parameters manager and see if there is a parameter looks like it's going to do the job. Like look for that parameter that's changing the length, or changing the width. Make a change and see if your part updates will.

What else can we do? Now, this is an old one. This is the Engineering Notebook. How many people use that? Yeah. It's still in there. I used to do these by accident. I didn't realize what it was doing. But you'll find you can right click on any feature, and you can add a note. You get this sort of sticky note that appears in the feature tree, but you also get his engineering notebook, which is a separate space held inside the part file, and it pops in a little image of your screen at the point when you created the note, and then you can add some more notes in it.

So if you want to add a note to say, hey, I've still got to check this file before you release it. It's not ready to go, yet. Or some other communication between you and your colleagues, this is one way you could go about it. Now, I've got a couple other suggestions to make here. I suggest you go with one-- I've got three suggestions. Go with one of them. Try not to use all three. So maybe show these off in your office, and say, which one do you think looks best? And let's be consistent in the way we do it.

So we have the Engineer's Notebook. The other one we have, which I really like-- this is in the later releases of Inventor, we have in the 3D annotation tools, we have something called a General Note. And the thing I like about the General Note is that it appears flat to the screen, and then when we revolve our part around, it just stays there. Now, you'll only see this in the part file. Like, if you're in the assembly, you won't see it. If you double click in any place edit, it will just pop up. So people can't miss this. They can't say, I didn't see that note. It's right there for them.