AU Class
AU Class
class - AU

iLogic, Your Foundation for CPQ

共享此课程
在视频、演示文稿幻灯片和讲义中搜索关键字:

说明

iLogic provides powerful, but underutilized, capabilities for Inventor. In a recent poll of Autodesk users, almost 50% had never heard of iLogic, and only about 30% are actively using it. Many users that are aware of iLogic, limit its use to part design and small utilities. However, that is just scratching the surface of what iLogic can do. In this session, we will introduce how iLogic can be used to configure an entire product, including supporting drawings, documentation, and pricing. We will also show how the configurable model can be made available to non-Inventor users, such as sales reps or customers, to create their own configurations, freeing up time for Engineering to focus on value-add activities.

主要学习内容

  • 1. Understand what iLogic is within Inventor
  • 2. Structure models to enable full product configuration
  • 3. Learn how iLogic can directly drive product pricing
  • 4. Extend Inventor Models to the WEB for non-technical users

讲师

  • Shannon Lundrigan 的头像
    Shannon Lundrigan
    Shannon has a Bachelor of Applied Science in Mechanical Engineering from the University of Ottawa, and is a certified P.Eng registered with AEPGA in Alberta. With over 10 years of industry experience in design and manufacturing, she has developed many custom products for mission critical applications, some of which were granted patents in the US and Canada. Shannon has extensive experience working directly with clients to meet unique requirements and provide technical support throughout long-term & high-profile projects. At SolidCAD, Shannon is a Technical Consultant on the Manufacturing Team. Drawing on years of industry experience using AutoCAD, Inventor and Vault, she provides pre- and post-sale consulting services, software implementation, training, and support for our clients.
Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected
      Transcript

      DON BORESKY: Hello. Thank you for joining us for this session. ILogic, your foundation for Configure Price Quote. In this session, we'll be talking about iLogic capabilities that are Inventor Professional and included with your subscription. The content is targeted at users that are new to iLogic or are using it in a limited way, such as individual utilities, and productivity enhancements, or part design. Power users that have experience with full iLogic driven models may expect some of this material to be review.

      Bringing you this session are myself, Don Boresky and Shannon Lundrigan of SolidCAD, a Canadian based Autodesk platinum reseller and Forge certified developer. My role is the industry account manager for configuration solutions. I've worked in the Autodesk channel for about 15 years. And 10 years before that, I was focused on manufacturing and retail ERP systems. While my formal education is very technical, I've always had a passion for viewing technology through the lens of business improvement, which fits well with my current role where I lead the business development efforts for SolidCAD configuration solutions. I'll let Shannon expand more on her background.

      SHANNON LUNDRIGAN: Thank you, Don. Hi, everyone. My name is Shannon. I'm a chemical engineer. I spent over 10 years in the world of design and manufacturing. Most of that time was spent in the research and development of industrial products, designing technical furniture, predominantly for air traffic control environments. I was an Inventor and Vault user on a daily basis during that time.

      I've now been with SolidCAD for just over three years, with which I'm a technical specialist on the manufacturing team. I'm specialized in the implementation training and support of Inventor and Vault. And for the past year and a bit, I've become one of our resident experts with our configurator, Variant. So I help clients build and upload their models with iLogic and learn to administrate that platform. And that's why I'm here today.

      DON BORESKY: Thank you Shannon. Let's start by confirming what iLogic is. ILogic is a powerful programming environment that's built into Inventor. But don't let the reference to programming scare you. iLogic provides a guided environment with substantial pre-built content to get you started. It's also based on a very common programming language called VB.Net that has lots of reference material readily available.

      While programming experience will be helpful, it isn't required to use logic effectively. An iLogic can be used to control virtually all of the model's characteristics, from simple user productivity tools, to full product configuration. And our focus today, obviously, is using it for product configuration.

      To illustrate the flexibility of iLogic, here are just a few examples of entire products that are configured with iLogic driven models. Some are simple, while others are very complex. Today's case study is built around range hoods from the company Vent A Hood.

      Vent A Hood is a longtime user of iLogic, obviously not for the full 80 years they've been around. But you may recognize them as an early adopter and signature account for Autodesk configure 360. As you may know, Autodesk configure 360 is no longer available. But Vent A Hood still sees over 2000 configurations generated per month in the system that they selected to replace it. More on that later, but let's continue with iLogic.

      Before we get into configuration management, we'll level set on some iLogic basics. For anyone that's used iLogic, these concepts may be review but we won't be here long. Some terms you will hear a lot of, code, which is a generic programming term. In this context, it means an individual or collection of iLogic instructions.

      A rule is a specific iLogic element that contains code to control Inventor functions. And models will generally have multiple rules, which can vary from very simple to very complex. Snippets are predefined chunks of code that go into rules that Autodesk provides with iLogic. These snippets are a big part of what makes iLogic usable even without a programming background.

      And iLogic code and rule capabilities are extensive. But there are a few elements that you'll use early and often, so you need to become very familiar with them. If you're using Inventor, the concept of parameters won't be new. But your current use of them may be limited. With iLogic, you'll make extensive use of parameters for inputs, value limits, optional values, and multi value lists to define allowable product options.

      Equations make use of parameters to evaluate and define a model's properties. And conditional statements are a code element that you will use extensively in configuration design. Now going to turn it over to Shannon to demonstrate some of these basics.

      SHANNON LUNDRIGAN: Thank you, Don. So as you mentioned, parameters are really at the core of iLogic programming and modeling in general. Whether you don't or not, anytime you're modeling in Inventor, you're using parameters. Inventor creates them in the background, as you enter your values. And then you can rename them to use it to your advantage for iLogic automation, and for other reasons, too.

      So I'm going to show you how we can push parameters from an assembly level into a part level. I've got this very basic assembly created here with two independent part files. And what I'm going to do is use the parameters I have set up in the assembly to change the parameters inside the individual part files. So let's open up that rule that I'll use to do that.

      So at the top here, I'm going to control the cylinder size. So what I've done here is use the parameter function. And I've called the cylinder occurrence. And the second element of the function is calling the parameter I want to control inside that part file. In this case, I'm controlling the cylinder diameter on the first line. And the second line is calling the cylinder height.

      After that, it's a simple expression indicating what you want those parameters to be. So in this case with the cylinder diameter, I want it to be equal to the diameter of input within the assembly file. So I just have cylinder diameter equals diameter. Second line is for a cylinder height. And I want to make the height a function of the diameter in this assembly, and so I have a diameter times 1.5.

      The next few lines of code are going to control the block. And so I call the block occurrence, and then the width, height, and depth respectively. Those are parameters all within the individual block part file. The first two will be controlled by the width and height, and will equal the values I enter in the assembly. And for the third one, the block depth is going to be the sum of the height and the width.

      Ultimately, I'm able to control five different parameters inside two part files, all with just three parameters I have inside my assembly. So let's take a look at that in action. And close up the rule here for a second.

      So I'll bring out the parameters dialog box in the assembly here. And you can see my user parameters are width, height, and diameter. Let's change the width, and we'll make that 5 When I hit Enter, you can see the width has indeed changed in the block. And because of depth is a function of the width and height, it is also changed to 8.

      Changing the height now, we're going to move it to-- or change it to 4. You can see it changes in the model view and the depth is also updated accordingly. So you can see that it's 5, 4, and 9 there.

      So lastly, we're going to change the diameter to 5. And then you're going to see that will update in the model view. And the height of the cylinder is going to be 1 and 1/2 the diameter. So it's 7 and 1/2 there now.

      It's very straightforward. And it might not seem like a lot, but this is very effective for configurators, because you're always going to be making the changes at the top level of the assembly and not at the part level. So having these rules push the changes down into the parts is quite important for manipulating configurations.

      Next thing I want to show is how we can set or change the parameters that require a dropdown list. These are very simple to create in the parameters dialog box, but they can easily be controlled using iLogic, as well. Meaning if your selection options change based on other important-- other input I should say, these dropdown lists can reflect different available options accordingly.

      The function is something Vent A Hood uses extensively, due to the large number of accessories and finish options that they allow. Since in their case, there are many instances where available options change, due to the size and what have you, they need to have this work seamlessly and without additional user input. So they're using the multivalue.setlist function.

      Inside this function, you simply call the parameter you're looking to control. So in the first line here we have height. This is a height parameter inside my assembly. Following the first comma, you enter the values you want in the dropdown separated by commas. There can be as few or as many as you like. And in the case of height, we have 1, 2, 2 and 1/2, 3, and 3 and 1/2.

      The second function is using a variable to call the list. What this means is that I've declared the diameter list as a variable inside my rule. And then using the function multivalue.list, I call the diameter, again, that's the parameter within this assembly file. And then I call the diameter list that I've declared above.

      A reason you might use this variable list is so that you can use that diameter list in multiple places within your rule. If you ever need to add or remove some values, you can do that in a single place. And this is where you've declared the diameter above there-- or diameter list I should say. This touches on one of the good habits to get into with coding. Rather than having to change list in several different places, and potentially missing one or typos, you can keep that list in one central location. And the changes will be reflected in every location that diameter list is used.

      So let's run this rule, and see what happens. Close up the rule here there. There we go. So let's open the pyramid of dialog box. You see that the width, height, and diameter are all static values currently.

      And then when I run the rule, I'll open the dialog box again. And we can see that the height and diameter are now dropdown lists. And they have the values, which the list has as options. So now I can make my selections based on the drop-downs. And all the values are still changing in the model, because the push parameter rule is still firing. But now I have limits as to what I can enter for the height and diameter.

      Moving on to conditional statements. This is really where the magic of iLogic takes form. This is where we can create conditions for when we want certain things to happen. As Don touched on, two of the most commonly used are the if statement and the Select case. So let's look at an example of each of these.

      The first block of code is an if statement. If the user inputs a value for the parameter width greater than 6, then the width is set back to 6. The else if allows you to enter an additional condition. Else if the width is less than 1, the width is set back to 1. Essentially, what we've done here is created a lower limit of 1 and an upper limit of 6 for the width.

      Else is your catch all. If the if and else if are specific scenarios requiring a statement, else is anything that isn't met the if and else if lines. So in the case it's neither greater than 6, nor less than 1, we've set the width to the user's input.

      You also have the option of leaving this part blank. The else line doesn't require a statement, which means this line essentially does nothing. And so in this case in particular, it would be the same outcome. The last line of that section is end if, which you would need to close out that statement.

      The second part of this rule is a select case method. When you start select case, you need to tell the rule which parameter you're going to be reading. In this example, we're going to look at diameter in the assembly. For each different function or action you want the rule to perform, you need to indicate in which case you want that to happen.

      So our first case is when the diameter is 1 or 2, separated by commas. If that case is satisfied, then it sets the height of the block to 4. And it's going to change the color of the block to yellow. If that case is not satisfied, it moves on to the next one. And they all move in order. And it looks for whether the diameter is 3. And in that case, the height is set to 6, and the color is changed to blue.

      The next case is the case else, which is our catch all function for the Select Case function. The rule will perform the following actions, if none of the above cases are met. And so in this rule, if this happens it sets the height to the user's input. And it will change the block to orange.

      You can have as many cases as you want, doesn't need to be a dropdown parameter. It can compare strings. You can also do greater than or less than, or any sort of math equation for it to compare that diameter to. So we're going to close that out, and then watch it in action here.

      You're going to open up the parameters dialog box again. And I'm going to set the width to 0.5. Then you'll see that it right away, it sets it up to 1, because it's below our lower limit. If I try 7, it's going to reset it back to 6, because again, six was our maximum. And finally if I enter 4, it's going to accept that value, because it's within the limits. And it's going to set the value of the width to 4.

      Moving on to the diameter, I'm going to enter 2, which was our first case. And you can see the height has changed to our set value of 4, and it changed color to yellow. If I set the diameter to 3, that's our second case. And again, you're going to see the height change to our set value of 6, and then the color changes to blue.

      If I set the parameter to something not within our conditions, I'll put 5 in there, then it's going to change the color of the block. But the height parameter doesn't change, because we didn't enter a value for that condition. So it just states. I can now enter whatever height I want, and it will accept it. And you can see that the diameter of the block-- or the cylinder, is also changing.

      So that's the absolute basics of iLogic programming. And you'll see a more contextual example of those in my next demo. For now, I'm going to throw it back to Don.

      DON BORESKY: Great. Thanks, Shannon. Actually, the next topic that we want to talk about is-- now that we've got the foundations, is looking at assembly control. And there's a few different options that we're going to look at. So my iLogic actually has four methods that can be used to control a model's assembly structure. Each has trade-offs, so there's no one ideal method. And this chart summarizes those options at a very high level.

      The first two, the visible and active state options, have been in iLogic from the start. And these are the easiest to use and manage, good place to start, but can create challenges with large models, or when unused components need to be removed from the final configured model. And replace and manage functions we're introduced more recently to address the limitations of the original options. But trade offs are there's some added complexity with both co design and file management. And with that, I get to hand it back to Shannon.

      SHANNON LUNDRIGAN: All right. Thanks again, Don. For this demo, I'm going to be using one of Vent A Hood's more complex designs. This model has a lot of different options for trim and accessories, as well as a number of rules in there for overall sizing, and pricing, and other accessories and finishes. You can see all the parts in there. I've simply collected them into a folder. So we can look at just the parts we want to focus on today.

      So today we're going to be focusing on the lower lip treatment. So you see it highlighted there in a second. So that's the copper band, you see at the bottom. We're going to be changing that out. And that's the option that we're looking at.

      The parts that affect this are those bottom four. Two of them are called sides, two of them are called front. So those carry out like four different options there. So we show how we can control this trim feature, using each of the methods that Don just mentioned. Here we have the visibility function, for using the Select case conditional statement I talked about earlier. And this model has four options for the trim configuration, as well as the option of None to have no trim at all.

      The function we're focusing on here right now is a component.visible, which is a snippet. All of these we'll be talking about today are snippets that you can use, which help you with the syntax of the code. This is a Boolean function, meaning it's a true false statement. True meaning visibility is on and false meaning visibility is off. That same line is repeated for each of the four options to ensure that only one option is on at a given time.

      You're going to find in iLogic, things tend to be quite repetitive. Copy and paste is your friend here. Because once you have that first case written out, you can copy and paste with the other ones, and then just adjust the true and false as necessary for each scenario.

      So we're going to see this in action here. In the model browser, you can see that there are-- all four parts are in the model, as I mentioned. But the visibility is only turned on with the front option, and then the rest are off.

      So we're going to change this up. And then we'll see that the visibility just changes, but the parts are all still in the model. So we saw it change from front to sides. And then we went back to the front of the two strips there, the TV.

      So I'm going to bring your attention to the BoM. The parts are still there, regardless of visibility. The rule is simple, and straightforward, and fast. But it might not be the best solution for you, because these are all still pegged as normal. And they also have a quantity of 1. So if you require the BoM to be really accurate for your current configuration, then this might not be the best solution for your particular model.

      Next up, we're going to look at the suppression option for managing assemblies. We're going to open up the rule here. Again, we have a very short line of code for the function. And again, it is Boolean.

      So this one is simply a component.isactive. And it's going to set the suppression for each part as true or false for each option, I should say. So another instance also that you can copy and paste your way down. And keeping these consistent and in the same order in these scenarios is really going to help you with troubleshooting. And copy and paste is always going to be the best way to reduce typos.

      So let's have a look at that in action. So here the difference is. You see those three parts are invisible, but they're actually suppressed. So that's the biggest difference between these two. So we're to make a change here, from the front TV to all sides. So we're going to see that bottom one gets suppressed. And then the top one is going to become active.

      It's still pretty quick. And then the bonus here is that your bond now reflects your current configuration. So the current quantity of these parts before at the bottom there, the one that's turned on sides is 1, and the rest are 0. So generally speaking, the first two functions are fairly interchangeable. But the suppression function will affect the BoM, and be a little bit more accurate. So that could be a better option for you.

      Next up, we're going to use the replace command. First thing you might notice about this in the model browser is we only have a single option right now loaded into the model. This ties into the file management topic that Don touched on earlier. The other files are currently not in the model, because we're actually going to replace the current option with the new one. If you're dealing with many different options, this could benefit you by keeping your overall file size down. And of course, your BoM is going to reflect only what's in the model.

      So let's have a look at the code for this one. As you can see, it is a little bit more involved. The function itself is still fairly straightforward. The snippet is component.replace.

      But because we are replacing a file, we need to specify which file we're replacing. And because we have four different options, we need to have the code, look, for any of the other possible three options to replace. Because any one of them can be active at any given time.

      This is where the try catch comes in. If the try statement isn't met , looking for sides LT, it moves into the catch. And then we nest the second try and the catch for the third option. So each of the cases is going to be looking for the other three options that could be active at any given time.

      The last two lines of code are for the constraints for adding those in there. I want to mention that try catch is not the only way to do this. And it's probably not even the best way. If anyone out there has experience in iLogic, you might have different methods to use for this.

      There are ways to stabilize occurrence names, which could simplify this. It's actually another reason in this particular method that isn't going to be my first choice. And I'll go through that in a second there.

      So in the model browser, as we change options here, you'll see it happen in the view window first. So it changes out to the front strip there in the view. And then it comes in in the model browser.

      This one's still pretty quick. But in large assemblies, or the parts have a lot of constraints, this is where you're going to start to see some lag, in comparison with the first two methods. And this is due to Inventor just having to find the parts, and perform the Place command and the constraints.

      So the one caveat to this method in particular, which I alluded to a minute ago, is the None option. If I go ahead and select the None option, it's going to delete the components altogether. Once the component is deleted, there's no longer one in there to replace. And so the rule is going to throw an error, if I were to make another selection.

      Ways to remedy this would be to suppress or turn off the current option, when none is selected. Then your BoM wouldn't be correct. You could also add the component back in. But at that point, you might as well use the manage components, which will be next, because that would be a ton more code than necessary in this particular case.

      So while this method has its place, it's not the best solution for this particular model. I would typically use this for configurations that have only two options. Or at the very least, avoid it any time there's a none or an off option like this one.

      And so now we're going to see the last method, which is manage components. And that uses a components.add. So this is actually an upgraded-- the components.add section has been upgraded in the last couple of releases of Inventor. The upgrade is called manage components. And what this does is allow you to essentially add and delete components as necessary with just a single function. So you don't really need to go through-- or you don't actually at all need to go through and delete anything that you don't need.

      So for this one, we're starting it with nothing. We don't have any trim parts at all in there. We have the none option selected. And none of the parts are in the model browser. And obviously, they're not in the BoM, as well.

      Similar to the replace function, we just don't have the parts that we don't need. So your file size can be reduced for assembly of many options for instance. I should also point out that you can do these methods with assemblies, as well. So if you're adding or replacing subassemblies within a large top level assembly, you might start to see how the file size could matter for you.

      So if you look at the code here. At the surface, it's actually not much more code than our visibility or suppression rules. However, it is doing a lot more. The begin manage and end manage are the key lines here. This is still relatively new, and might be something even experienced users maybe aren't too familiar with.

      As you can see, these lines kind of sandwiched in the code that affects the parts we're working with. And that's how manage components works. Any components that are within the begin and end manage lines are part of this group, a group I've called lip treatment. When you need a component added, you simply need to add it using the components add function. And then add the constraints, as we did with the replacement command.

      The constraints can be added fairly easily using capture current state, where you can actually do the work in the model, then grab everything using the capture current state, which is a right click command in the rule editor. You can, of course, write up the code from scratch, but this method is a lot easier.

      So back to manage components. When a particular component is added, it's going to be added if and only if the associated condition is satisfied. Meaning for a particular condition or case, only that part will be added. And the other parts within this group will be deleted, if they currently exist in the model. They don't exist, it doesn't do anything.

      You no longer have to worry about deleting the components you don't need. And that's really the magic of manage components in general. We've made it quite a bit simpler to manage this.

      So if we look at the model browser again, we've got nothing in there. But we're going to change this one to all sides, top, and bottom. This one does take an extra second. But you'll see it updates in the Model Viewer, again, first, and then it populates in the model browser.

      Still decently quick. The video recording software actually slows us down a tiny bit. We're going to change all sides now to front only. And at this point, it looks a lot like the replace command. But it's a lot cleaner, from a coding perspective. And we can easily take care of the none option. And you can see that change there.

      So it is still relatively quick. As I mentioned before, you will notice the difference in speed between the methods, when you're getting into subassemblies, large overall models, the more complicated configurations, when you're changing up multiple items at the same time, and things like that.

      Ultimately, as Don touched on before, there is no right or wrong answer to how you create your configuration rules, similar to modeling in general really. There's always more than one way to write code to get the same result. The most important thing is to make it robust and error proof. Because you need that rule to run flawlessly without the need for secondary input, especially when we're talking in the context of web configurations.

      In the case of Vent A Hood, they chose the toggle visibility, the first one we used. Because they didn't need to worry about inventory BoM output for their online configurator. They wanted to maximize the speed and have everything contained in the master model assembly file.

      The trim option we focused on today is only one of about 12 or 13 options that they have in this model. They also have things like drop-downs that change depending on selections that are made. So it might not look like it, but this model does actually have a lot going on. So visibility was the best solution for these guys. And back to you Don.

      SHANNON LUNDRIGAN: Excellent information, Shannon. Thank you very much. And now let's jump into pricing. How we can take that assembly controls, and extend that to product pricing. Because once you know how to drive assembly, it can actually be pretty straightforward to extend the models to include pricing. Not to say it's simple, but straightforward.

      Because at its core, we use the same coding structures, but in a specific iLogic pricing rule to calculate a value for a specific price parameter. And pricing is also a very good example of how linking your model to a spreadsheet can be especially useful, such as for maintaining raw material and component prices that can fluctuate over time. You want to update those rather than having them directly in the model. And let's take a look at those concepts.

      SHANNON LUNDRIGAN: All right. Thank you, Don. So when it comes to pricing, we typically see about half of our web configurator clients generate quotes directly from the site. The other half will simply have the request for code option. Vent A Hood has a very extensive price coding calculation built into their configuration models.

      So I want to quickly show you one of the options you can use, which keeps the price reference outside of the model. And then I'll show you what Vent A Hood incorporates into their master model.

      So firstly, we have the external method, if you will. This involves using iLogic to pull values from a spreadsheet, as Don mentioned. The spreadsheet simply needs to be saved in the same location as your assembly file. Then there's just a couple of lines needed really to pull the appropriate values. So let's have a look at that basic example.

      So again, we're going to be looking at the JCIH model, the same one we were looking at before from Vent A Hood. This rule is not what they use. I've just created this one for the demo, so I can use the same model for comparison.

      The main function is go excel. In this line, you can call the file VH pricing, the sheet lip treatment, and then the column option. Then we tell the rule to compare the values in the option column in the spreadsheet, that's the spreadsheet you see at the top there, to our parameter LT option. This will find the appropriate row.

      The next go excel command will read the cell value for the corresponding row under the appropriate column. In this case, price. And it assigns it to our parameter called LT cost.

      The next section, we're going to do the same thing. This time we're going to look at the finished cost. The conditional statement that you see in there takes care of the none option, in which we would obviously not have a cost for the lip treatment at all. And then at the end, we add the LT cost to the LT finished cost to get our LT price. You'll see that second spreadsheet is below the first one there in your screen.

      The message box is just there so that we can see the price show up when I run the rule. In the configurator of the world, this price parameter would be pulled by the configurator engine, and entered into an actual price quote. So let's have a look at that in action.

      So I'm just going to run the rule with the current selections here, the all sides in the hammered copper. And we're going to see that message box shows us that the lip treatment cost ends up being $355. So that's just for that option. We just broke out that lip treatment cost.

      Make a couple of changes to the model. So we'll change front and back. And then we'll change this to brushed brass, just so we get a different price to show that it is pulling different values from the spreadsheets. We'll run the rule again. And then you can see in the message box the cost is now 318. So it is pulling the appropriate values from the spreadsheets.

      Next up, we're going to look at how Vent A Hood does it. And as promised this rule is quite a bit more intense. The section of the rule is only for the lip treatment cost. As I mentioned in the last demo, there's about a dozen different accessories and options for this model in particular. This rule is over 250 lines long and calculates the overall cost based on it's size, as well.

      It's not intended to scare anyone away from this method. But just wanted to demonstrate how precise you can be with these rules. They use the select case to identify the options for each of the lip treatment. And then they base the price on the overall size of the hood, because that's going to change the amount of material. And then they add a multiplier of 5.95. You can see the case else will cover the none option, and return a value of 0 there, the bottom line that's circled.

      The second condition is the finish for the lip treatment. The cases go through all of the available finishes. They have some if statements nested in there, as well. And these account for the none option, and also a couple of Boolean parameters that have been set in the rule above this. You can see we are on line 180 of this rule. So there have already been a number of things firing by other selections that we haven't been focusing on today.

      The orange vowel and round terms that are used in the calculation that you see there are set to maintain a maximum value-- or maximum of two decimal places, I should say, since this is currency we're talking about. And then the current multiple in blue there, that parameter is declared at the beginning of the rule and accounts for the difference between the US and Canadian currency.

      At the bottom, they take all the values calculated above, and then they add up the total cost. In this case, I removed a number of the other options from the calculation, just for this demo. So it's a bit easier to see how the final cost is calculated. And we can pull those three major components in. So we've just got the hood costs, the lip costs, and the duct cost for this one.

      So we're going to see that in action here. Again, we're just going to run the rule with the current selections, the front back only and the brushed brass. And we're going to run the rule, and see the message box. So this one has a $7,388.40. Again, this is so much more, because it's actually incorporating the hood and the duct cost, along with the lip treatment. The important thing here is to see the changing costs.

      So we're going to change these back, the options back to all sides. And we're going to go back to the hammered copper, because I think it looks pretty cool. And then run the rule again. And now we see our cost is $7477.40.

      So that is clearly changed. It's updated based on your selections. And that's it. The cost is calculated directly within the rule and no external documents are needed. Another case though where there's no correct or incorrect method, it's all just whatever works best for you in your company.

      And before we move on to the actual configurator talk, I just want to go over to a few of the good habits or best practices when it comes to iLogic. Constraining, using the origin or work geometry, can help make your rules more robust, especially when bringing in parts using iLogic or replacing parts in general. This is just simply because these elements themselves are less likely to change and cause errors in your rules.

      Using meaningful names for your components, components parameters and features, will help you not only when coding, but just in general with modeling. It's a good habit to get into. So you can make quicker edits. Especially helpful for collaboration with colleagues, and also for those times when it's been a few weeks or maybe months since you've touched a particular design and need to work on it again.

      Trying to avoid explicit values in your rules is good practice. Wherever you can, use those variables or named parameters at least in your rules so you can make your changes in a single location. Comments. Comments are an underrated feature in iLogic. Explaining what each rule or section or rule is doing in plain terms will allow you or your colleagues to understand a lot quicker what's happening. You really will think yourself later, or you'll think your colleagues.

      The last one is specific to web configurators. Typically speaking, any input, prompts or forums, or message boxes are not going to be able to be used inside the Forge engine. And that's what runs configurators for Autodesk.

      So while they're great for troubleshooting your configuration model, like we did with the pricing rule there, just keep in mind that you'll need to make these particular elements inactive for the web. So you just shouldn't rely on them for your user experience. And now Dawn is going to take us a little deeper into that side of things.

      DON BORESKY: Thanks, Shannon. Yeah, now that we've got the foundations in iLogic for configuring assemblies and the related pricing, let's see how we can extend that to the web. The default answer from Autodesk frankly, is to use the Forge Design Automation API. And there's no question that capability for Inventor is very powerful.

      And I don't want to discourage anyone from starting a Forge project on their own. Just be aware that using Forge may not be as straightforward as it might seem at first. So some key things to keep in mind, you need to be a programmer, full stop. No qualifiers on that statement.

      Unlike iLogic, which is a guided programming environment, Forge is not. And unlike iLogic on the desktop, Forge is not an interactive environment. That means that code has to be written to handle conditions, such as size limits and display dependencies, so that valid parameters are submitted to Forge. And there's also significant setup and management requirements for Forge, and If you're going to use a web environment, such as AWUS.

      So with that in mind Vent A Hood had decided to take a different path. Vent A Hood created their public facing Build A Hood product configurator, based on SolidCAD Variant. In Build A Hood, customers design their dream range hood in a live 3D interactive environment. And once it's configured, they can download drawing and model files. They also have the option to submit a request for quote for that specific configuration.

      So why did why did Vent A Hood pick Variant? And there's a few reasons. But primarily, SolidCAD Variant provided Vent A Hood with the power of iLogic and the Forge Design Automation API for Inventor without the complexity of building their own applications, kind of the best of both worlds.

      Variant is fully web based, making it available to the general public, without complex infrastructure to manage. Variant made web based configuration quickly attainable with a simple annual subscription, letting the engineering and sales teams continue to focus on what they do best. With that, let's take a quick tour of the Build A Hood portal. And by the way, Build A Hood is open to the public, so feel free to take it for a spin when you get home.

      Because Vent A Hood products can be specific to regions, we start by picking the area that we're in. This provides access to all the configurable hoods. Each of these is an individual iLogic driven adventure model.

      Let's take a look at the JCH A1. When we pick the model, the website links to the Variant tenant for that configuration. All the configuration parameters and valid options are drawn directly from the adventure model and displayed on the left.

      So let's pick a width, and we'll decide on the CFM we need. I kind of like the stainless steel finish. And we'll also add a couple of bands. And we now see additional parameters to define the details of the bands. Part of the setup in Variant is to prompt for band details, only when the number of bands is not 0.

      And now I can select the band style, and whether there are bands on the duct cover, and the band finish. And once we've defined the options that we want, we can hit generate model.

      Variant and Forge now do their thing. Variant packages up the selected parameters and sends them to Forge to generate the configuration. Because the model is already uploaded to Forge as part of the initial setup process, only the parameters themselves need to be passed. Forge applies the parameters to the model and sends back the result.

      Now while Forge is doing its thing, we provide feedback, so that users know the process is running, and they stay engaged. When it's done, the updated configuration is displayed in the Forge viewer.

      If further changes are needed, we can update the parameter selections and rerun generate model as often as we need. And when we have the result we're looking for, we hit generate downloads. Forge is then reengaged to generate the additional documents and files related to that configuration.

      And Vent A Hood has given their users the options to download a couple of model formats, 3D and 2D, DWGs, a drawing in PDF format, and to request a quote for the configuration. Now Variant also has options for additional downloads, including the configured adventure model, and the price document, which are used by some of our users.

      And that wraps up iLogic, your foundation for Configure Price Quote. We appreciate you taking the time to join us.