Else if statements in 'User parameters'?

[Anonymous]

I don't want to use iLogic coding because it's too confusing for me at the moment.

Is there any way to use the 'else if' statement in user parametrics? Each time I write the code i get 'Unable to parse equation'. It's not even that difficult...

[Curtis_W]

Hi mtofts,

There isn't a way to do this in the parameter editor.

This is what is avaliable as far as parameter functions:

https://knowledge.autodesk.com/support/inventor-products/learn-explore/caas/CloudHelp/cloudhelp/2014...

One option that you might look into is to link or embed an Excel spreadsheet and create the if/then in Excel and hand the result to Inventor as a linked parameter.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[Anonymous]

Thanks Curtis,

I shall try the link to Excel later.

It's a shame that again I find there are odd limitations to Inventor. Parametric equations are sometimes essential with this type of design engineering. Not sure why they missed the option out...?

[Curtis_W]

Hi mtofts,

I should point out that if you're wanting to suppress a model feature, you can use If/Then logic, but you access it by right clicking on the feature in the browser and selecting Properties. Then you can set that feature to suppress if a selected parameter value is greater than, less than, equal ... etc., whatever value you enter.

That might be something to look into also,

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[mcgyvr]

I was just about to post that too Curtis..

[ic198]

I was trying to solve a similar problem and came across this thread. You can't use conditional statements but parameters do support max, min and sign functions, which can often be used to do the same thing. For example, the OP's purpose would be met using:

max(d8-Slack;0)

https://knowledge.autodesk.com/support/inventor-products/learn-explore/caas/CloudHelp/cloudhelp/2014...

[johnsonshiue]

Hi! This one can easily be done in Parameters Expression or iLogic. iLogic is fairly easy to use. I am not a programmer but I can create simple rules very quickly.

To do it in Parameters dialog, you just enter the following expression.

max(d8-Slack;0)

When d8-Slack returns negative value, 0 will be bigger. When d8-Slack is positive, it will be bigger than 0.

Many thanks!

[richard.joseph.pollak]

There are some creative ways to use equations that work like conditionals in your parameters.

Here's an example of one I used:

I wanted a parameter to be equivalent to 1/8" for diameters greater than or equal to 3/4" and 1/16" for everything else. So I used this equation:

conditionalUserParameter = sign(-1 in * ( Diameter - 0.75 in ))

conditionalUserParameter* 0.0625 in + (1 - conditionalUserParameter) * 0.125 in

The 'sign' function is working as my boolean check. It returns 1 for positive values and 0 for values <= 0.

If Diameter > 0.75 in, sign(-1 in * ( Diameter - 0.75 in )) = 0, so the parameter = 0.125 in

If Diameter = 0.75 in, sign(-1 in * ( Diameter - 0.75 in )) = 0, so the parameter = 0.125 in

If Diameters < 0.75 in, sign(-1 in * ( Diameter - 0.75 in )) = 1, so the parameter = 0.0625 in

Just a method I like to do for parameters that can be controlled with conditionals when I feel like iLogic would be overkill.

[jtylerbc]

But isn't that actually more work than the incredibly basic iLogic it would take to do the same task?

If Diameter <= 0.75 Then
	TheParameter = 0.125
	
Else
	TheParameter = 0.0625

End If

I can understand doing parameter tricks in the time before iLogic, but I don't get why you would want to use the old workaround to fake an If/Then function when you can just drop in 5 lines of simple code and have actual If/Then statements.

[richard.joseph.pollak]

I suppose it's a matter of both preference and use case. Not everyone I work with is savvy to iLogic, so this let's them see what's going on with the model simply by looking at the parameters. Additionally, the example I provided is from an iPart, which iLogic doesn't tend to play nice with.

I agree that iLogic is often the easier approach, but I've also had cases where the optimum solution was to keep the parameters directly linked rather than through an iLogic abstraction. Actually, I've created some automated assemblies where I use a combination of both methods. One thing I've noticed when calculating a large quantity of parameters: iLogic tends to take longer since it updates the parameters line by line. Calculated parameters tend to change more or less immediately. My intention in posting this method was simply to offer an alternative approach for anyone curious to be able to add to their toolbox.

I'm sorry if I gave the impression that I thought iLogic was the wrong solution or that mine was a better solution. That's not what I intended. Your reply demonstrates exactly why my method might not be the ideal choice. Thank you.

It would be nice to see Autodesk add actual conditional functionality to parameters.

[jtylerbc]

---

@richard.joseph.pollak wrote:

I suppose it's a matter of both preference and use case. Not everyone I work with is savvy to iLogic, so this let's them see what's going on with the model simply by looking at the parameters. Additionally, the example I provided is from an iPart, which iLogic doesn't tend to play nice with.

---

That does make sense, especially the iPart scenario.  Oddly enough, my experience would indicate the opposite regarding the users though.  Most of the other users at my company aren't particularly skilled with iLogic either, but they seem to be able to figure out what is going on from iLogic code more readily than from convoluted parameter relationships.  Even though they wouldn't know how to program it themselves, they can skim over the code and get the general idea of what it's doing.  Of course, that's also highly dependent on how cleanly the code is written.

---

@richard.joseph.pollak wrote:

I'm sorry if I gave the impression that I thought iLogic was the wrong solution or that mine was a better solution. That's not what I intended. Your reply demonstrates exactly why my method might not be the ideal choice. Thank you.

---

No, you didn't necessarily give that impression.  I was just confused as to why someone would still be using the conditional parameter technique when they have access to iLogic.  I tend to think of that technique as "that weird thing people did before iLogic." 

Now that you pointed out some examples, I can see where there might be some situational advantages.  They just wouldn't necessarily apply to what I do, and they hadn't occurred to me.  If we're trying to control things with enough parameters involved that it would bog down iLogic's performance, then usually we would be controlling it with a layout part of some kind anyway (multisolid or sketch-based skeletal modeling).  So I've probably never created an iLogic-driven model complex enough to have the issues you described.

Nearly every part we create has iLogic in it, but it tends to be relatively simple.  Our use case tends to be large quantities of small automations, rather than large automated assemblies.