I attempted an equation like this: "sqrt(D13-D26)". Why won't it work? I removed the square root and tried simple subtraction but that was also a fail. It seems as if the equation editor actually will not take more than one parameter. In the past I've successfully subtracted a constant from a parameter in an equation but trying to use two parameters isn't working why? What am I doing wrong?
equations with parameters
- Thread starter jswendell
- Start date
HaroldL
Alibre Super User
The equation editor is very particular about the dimensionality of the parameters.
alibre.freshdesk.com
Working with Equations in Alibre Design
Alibre Design has an inbuilt capability to use equations in your designs. Similar capability is made available in Part Workspace (accessed via Equation Editor) Assembly Workspace (accessed via Equation Editor) Global Parameter Files There...
alibre.freshdesk.com
idslk
Alibre Super User
The EE tries to calculate the square root out of the whole expression as in common mathematics. This means EE is calculating the sqrt from the numbers as well as from the units...
So a sqrt of 25mm² will work because of 5*5 and mm*mm... but ask yourself what is the square root of mm?
Regards
Stefan
NateLiqGrav
Alibre Super User
A trick I learned a while back from someone on the forum: create new variables for each type with a value of 1 to use to force the unit changes without value changes. For example create a new variable called unit_mm with a value of 1mm. Then you can do this in the other equation: sqrt(V2 * unit_mm)
albie0803
Alibre Super User
In case you haven't worked it out yet and for general information, here is the answer
Most mathematical functions can only be done with Scale (dimensionless) values
Display units (mm or inch) are considered as separate elements in the equation by the Editor
As Stefan said "So a sqrt of 25mm² will work because of 5*5 and mm*mm... but ask yourself what is the square root of mm?"
So distance values need to be converted to scale (dimensionless) values, which you do your desired function on, then the answer converted back into a distance value
V2 (scale) = 3.5 (mm) / 1 (mm) = 3.5/1 * mm/mm = 3.5 * 1 = 3.5
V3 (scale) = 3.12 (mm) / 1 (mm) = 3.12/1 * mm/mm = 3.12 * 1 = 3.12
D2 (distance) = 0.61644 * 1 (mm) = 0.616 mm
The equation TYPE is very important
I have asked for this article by David to be added to, or a link added into the help page for the Equation Editor Working with Equations in Alibre Design
This is my best grasp on this at the moment
Most mathematical functions can only be done with Scale (dimensionless) values
Display units (mm or inch) are considered as separate elements in the equation by the Editor
As Stefan said "So a sqrt of 25mm² will work because of 5*5 and mm*mm... but ask yourself what is the square root of mm?"
So distance values need to be converted to scale (dimensionless) values, which you do your desired function on, then the answer converted back into a distance value
V2 (scale) = 3.5 (mm) / 1 (mm) = 3.5/1 * mm/mm = 3.5 * 1 = 3.5
V3 (scale) = 3.12 (mm) / 1 (mm) = 3.12/1 * mm/mm = 3.12 * 1 = 3.12
D2 (distance) = 0.61644 * 1 (mm) = 0.616 mm
The equation TYPE is very important
I have asked for this article by David to be added to, or a link added into the help page for the Equation Editor Working with Equations in Alibre Design
This is my best grasp on this at the moment
Also note that any number typed into an equation will be assumed by the EE to be of the TYPE that is set for the whole equation. This can result in something that looks valid when first typed, but turns red when Enter is hit.
E.G. D6 = (REPEATS -1) * 3mm might look mathematically fine ( REPEATS is a COUNT TYPE) - but when equation is entered the 1 in (REPEATS-1) will be assigned as a LENGTH, so the dimensionality of the equations is inconsistent. To avoid this it is necessary to add an intermediate step
NUM (of TYPE COUNT) = REPEATS - 1
Then D6 = NUM * 3 - this time it's fine for the 3 to be assumed to be a LENGTH
E.G. D6 = (REPEATS -1) * 3mm might look mathematically fine ( REPEATS is a COUNT TYPE) - but when equation is entered the 1 in (REPEATS-1) will be assigned as a LENGTH, so the dimensionality of the equations is inconsistent. To avoid this it is necessary to add an intermediate step
NUM (of TYPE COUNT) = REPEATS - 1
Then D6 = NUM * 3 - this time it's fine for the 3 to be assumed to be a LENGTH
Thanks everybody who replied. I created a unit on/off switch (uS) as explained here and my equation works now! I think it's astonishingly inept that this isn't discussed in the user manual. It's as if the manual was written to be useful only to those who already know CAD inside and out. This isn't the first time I have pulled my hair out trying to figure out what's wrong due to major deficiencies in the manual. I guess it's not so bad though when there are so many knowledgeable and helpful people in this forum!
Has there ever been a manual that's clear if you don't already know the answer? 
I found that so many times reading through the Fanuc manuals for various CNC controls over the years.
Same thing with all of the CAD packages I've seen.
Youtube has been a great help to me over the years.
Jim
I found that so many times reading through the Fanuc manuals for various CNC controls over the years.
Same thing with all of the CAD packages I've seen.
Youtube has been a great help to me over the years.
Jim
I'm not complaining about lack of clarity. I'm complaining about vast amounts of important information simply being totally absent. If it is indeed standard practice in CAD to not have a complete manual, that is a sad state of affairs.Has there ever been a manual that's clear if you don't already know the answer?
I found that so many times reading through the Fanuc manuals for various CNC controls over the years.
Same thing with all of the CAD packages I've seen.
Youtube has been a great help to me over the years.
Jim
albie0803
Alibre Super User
Oh I so agree! though I feel its more like it was written by those who already knew CAD inside and out and it ended up presenting more like a reference rather than a teaching tool.
I find the same with the Scripting reference manual. It lists all the ways the functions can be used but has no examples of correct syntax to actually use them. Once again, great for reference but terrible for teaching.
I feel compelled to comment further that this looks a workaround for a defect that should be fixed. This is how I would expect Alibre to work: the number I enter for a dimension should be stored in an array as a float, the corresponding unit is stored separately in the array (defaulting to my global setting if I don't specify a unit). Example: My global units are set to mm but for a particular parameter, I want to see meters displayed, so I enter "2m" for the parameter. Alibre stores "2.0" as a float in the array along with the unit type "m". Whenever that parameter is called, Alibre looks at the float, looks at the unit type, and translates into centimeters automatically for the calculation, sending the number 2000 to any equation that calls it. If for some reason, I want to specifically use the number stored in the array, minus translation, there should be a specific "get" command to grab that float, ignoring the units translation.
Now this is all so obvious that I have to ask, what's wrong with my logic? There must be some rational reason why the Alibre team didn't implement something like this a loooong time ago instead of forcing the use of this clumsy workaround and worse yet, never advising those learning the software that such a problem even exists. I mean I never in a million years would have guessed that I was forced to manage units translation myself. Of course, I presumed that every number I entered as a dimension was stored as a float and that with my global unit type set as millimeters, Alibre would just grab the float and do the calculation. To me, this is not just counterintuitive, it's preposterous.
So again I ask, what am I not understanding about the world of CAD that can explain this seemingly bizarre design decision?
Now this is all so obvious that I have to ask, what's wrong with my logic? There must be some rational reason why the Alibre team didn't implement something like this a loooong time ago instead of forcing the use of this clumsy workaround and worse yet, never advising those learning the software that such a problem even exists. I mean I never in a million years would have guessed that I was forced to manage units translation myself. Of course, I presumed that every number I entered as a dimension was stored as a float and that with my global unit type set as millimeters, Alibre would just grab the float and do the calculation. To me, this is not just counterintuitive, it's preposterous.
So again I ask, what am I not understanding about the world of CAD that can explain this seemingly bizarre design decision?
Ex Machina
Senior Member
The reason that Alibre carries the units is that, this way you can have multiple units of the same type in the same equation. Even if you have set the units of a part to mm, Alibre can still accept a value of 2.125in in a dimension. Let's say that this D2. It will store it as 2.125in and the RESULT is going to be 53.975mm. Let us suppose a D1 value of 2.
Afterwards you can have an equation that calls for 3*D1+D2 and it would compute correctly to 59.975mm and not 8.125mm. If Alibre disregarded the units it would SERIOUSLY gimp the potential of the equation editor.
Let me note that the sqrt() example from above would not compute in Fusion 360, Onshape, or FreeCAD either. I checked.
Finally, I wouldn't call it preposterous when it is how physics and engineering calculations are done. Sure, it has caused me trouble in the past, especially back at school. But that's how it's done. Along with the numbers you need to do the operations on the units too. Now, some other CAD might have better intelligence built in to correct our mistakes. But that's a completely different matter.
Omitting the units is a SERIOUS problem for any engineering software and would render the equation editor useless if not dangerous to use!
P.S. This "problem" actually protects us sometimes by showing us that we haven't fully thought of something in our equation. I HAVE SEEN students make this exact error in huge extensive Excel spreadsheets and then can never debug it...
P.S.2 This square root equation can work if you just write sqrt((D13-D26)*1mm)
Afterwards you can have an equation that calls for 3*D1+D2 and it would compute correctly to 59.975mm and not 8.125mm. If Alibre disregarded the units it would SERIOUSLY gimp the potential of the equation editor.
Let me note that the sqrt() example from above would not compute in Fusion 360, Onshape, or FreeCAD either. I checked.
Finally, I wouldn't call it preposterous when it is how physics and engineering calculations are done. Sure, it has caused me trouble in the past, especially back at school. But that's how it's done. Along with the numbers you need to do the operations on the units too. Now, some other CAD might have better intelligence built in to correct our mistakes. But that's a completely different matter.
Omitting the units is a SERIOUS problem for any engineering software and would render the equation editor useless if not dangerous to use!
P.S. This "problem" actually protects us sometimes by showing us that we haven't fully thought of something in our equation. I HAVE SEEN students make this exact error in huge extensive Excel spreadsheets and then can never debug it...
P.S.2 This square root equation can work if you just write sqrt((D13-D26)*1mm)
Last edited:
NateLiqGrav
Alibre Super User
@Ex Machina, ok so what are your thoughts about Alibre Design applying internal centimeters and radians units in calculations in some cases even though the user has already setup separate default unit types for the part and assumes that those are being used when no unit type is written. That seems like a huge error on Alibre's part to continue that legacy.
Ex Machina
Senior Member
To my knowledge, Fusion and Inventor do the same. I can't speak for other software because I don't know. But Fusion and Inventor are both based on a fork off the ACIS kernel that Alibre is based too.
Furthermore, you are referring to scripting, not the Equation Editor. In the equation editor if you do not write units it defaults to the ones set for the part or assembly file. At least for the distance variables. For the angle variables, I guess defaulting to radians never bothered me because Matlab, Excel and so many other need radians for their functions too, so I guess I'm just used to it. But I think all CAD kernels are based on a single unit and convert for the rest.
As far as Fusion is concerned, I did do very little scripting in Fusion, mostly to create helixes and spirals before they implemented the tools (I think they still don't do spirals for Fusion) and it was fine to do the translation in script.
Have you noticed that behaviour in the Equation Editor? Using cm when no units are written for the distance?
P.S. I did a quick check. If you write a number without a unit in the Equation Editor, it will add the appropriate unit you have chosen in the Units section of the properties. Including degrees for the angles.
Last edited:
Thanks for replying. However, your statement, "If Alibre disregarded the units it would SERIOUSLY gimp the potential of the equation editor", shows you did not properly consider my proposition. If you look again, you will see that I was absolutely not suggesting that Alibre should disregard units but rather that Alibre should manage them for me, as should be expected from modern software. I must therefore conclude that the actual answer to my question is this: Alibre is derivative of legacy software that was written exclusively for formally trained engineers and has thus never been properly modernized. This is also reflected in the dreadfully incomplete manual.
Eventually, a CAD software design team is going to realize that we are entering a new age, an age where many people don't waste their time and money getting educated at a college where a certain amount of brainwashing is forced upon us. For an ever growing number of us, the process of learning CAD is the process of learning engineering and this should be reflected in the design philosophy but especially in the help/user manual. Just my 2 cents.
"This square root equation can work if you just write sqrt((D13-D26)*1mm)"
Thanks for the tip!
Ex Machina
Senior Member
I think your answer shows that you did not properly understand my reasoning. You therefore concluded that the opinion you had already formulated must be correct.
But it's not. Just remember that in Alibre, you are designing things for the real world. And the real world has units.
Also, CAD is just a tool for applying the knowledge you already have. It won't make you an engineer any more than learning to operate a torque wrench will make you a car mechanic. If anyone comes along and tells you otherwise, beware...
I am not an engineer, and I am new to CAD, so it would not surprise me if my opinion is incorrect. But your response did not even address my opinion, much less prove it incorrect. You revealed this when you said, "If Alibre disregarded the units it would SERIOUSLY gimp the potential of the equation editor". You revealed this again when you said, "you are designing things for the real world. And the real world has units" I NEVER for even a moment suggested that Alibre should dispense with, or ignore units. I gave a precise description of how Alibre should TRANSLATE units for me without creating any complication or confusion. You never addressed that suggestion or explained why you think it is flawed. I mean no disrespect. This is not a pissing contest. Relative to you, I know next to nothing. But please don't presume that I am stupid. It is not fair to declare that my reasoning is flawed when you have repeatedly shown that you have not even analyzed my actual proposal.
Ex Machina
Senior Member
Jswendell... It is 12:15 over here and I shouldn't be writing this but...
You say I did not even address your proposal. However I did write this, right before the sentence you keep quoting:
So, I gave you an example of what converting the values to float, doing the math, and exporting it with the units of the desired result would cause. I gave you an example where, your method would return a value of 8.125 when the correct answer would be 59.975. Because, if you wanted Alibre to calculate that sqrt for you and export it with the units of the desired result, it's a completely equivalent operation to my example.
You also said that you might want to use just that value and there should be a "get" command. There is no need for that as long as you follow the math. That's what the *1mm was in my P.S.2 comment. Do you want to use a Length variable as a scale value? Divide it by 1mm. What David, albie, and Harold where saying is a completely different problem which you did not encounter. It is the problem David describes in his (REPEATS - 1) example. But you did not hit Alibre's dimensionality problem.
You also want Alibre to "translate" units for you. Well, it does. That's why it flagged that error. Because it tried to translate the units for you, which I am assuming you mean perform the mathematical operations on them, and it came up with a result of square root of mm. That is what it got after it did the operations on the units. And it recognized that it is a physically impossible outcome.
Now, would you want Alibre to just plug the value it calculated from the float values of the other 2 parameters as the result of that sqrt expression you wrote? Did I understand that correctly? What would be the steps Alibre should take algorithmically to calculate that particular square root without disregarding the units? And when would it use your "proposal" and when should it revert to doing the actual mathematical operations on the units? How would it distinguish between the 2 cases?
I also said:
So, I did address it and prove it wrong. Because you basically want the units of the desired result to be added on to the final value. And when I said that you are designing for the real world what I meant is this:
You D13 and D6 variables are not numbers. They are lengths. The result of their subtraction is also a length. And the square root of a length, although a valid unit in physics, cannot be used to describe a length any more than a length can be used to describe an area. That's what I meant. Your expression was a physical impossibility. Not doable in the real world.
So, any method, reasoning, proposal, or algorithm that allows a physical impossibility to go through unchecked, reduces the potential of a parametric software and equates it with that of Matlab, Excel, and others. And these are indeed legacy, traditional and unevolved software. The ability of modern Parametric CAD to "translate" the units and catch these errors is the evolution in software and provides immense power to their user.
Now... All the rest about stupid, pissing, knowing or not knowing, is irrelevant.
You say I did not even address your proposal. However I did write this, right before the sentence you keep quoting:
So, I gave you an example of what converting the values to float, doing the math, and exporting it with the units of the desired result would cause. I gave you an example where, your method would return a value of 8.125 when the correct answer would be 59.975. Because, if you wanted Alibre to calculate that sqrt for you and export it with the units of the desired result, it's a completely equivalent operation to my example.
You also said that you might want to use just that value and there should be a "get" command. There is no need for that as long as you follow the math. That's what the *1mm was in my P.S.2 comment. Do you want to use a Length variable as a scale value? Divide it by 1mm. What David, albie, and Harold where saying is a completely different problem which you did not encounter. It is the problem David describes in his (REPEATS - 1) example. But you did not hit Alibre's dimensionality problem.
You also want Alibre to "translate" units for you. Well, it does. That's why it flagged that error. Because it tried to translate the units for you, which I am assuming you mean perform the mathematical operations on them, and it came up with a result of square root of mm. That is what it got after it did the operations on the units. And it recognized that it is a physically impossible outcome.
Now, would you want Alibre to just plug the value it calculated from the float values of the other 2 parameters as the result of that sqrt expression you wrote? Did I understand that correctly? What would be the steps Alibre should take algorithmically to calculate that particular square root without disregarding the units? And when would it use your "proposal" and when should it revert to doing the actual mathematical operations on the units? How would it distinguish between the 2 cases?
I also said:
I meant that when the units of the numbers are not calculated along with the values, which is how Matlab and Excel works, I have seen students and occasional users of the software get it massively wrong. Because they think that the software has a concept of Units when it doesn't. Alibre, and most parametric CAD to be fair, DO have a concept of units. And error flags like the one you encountered save us a lot of trouble. Yours was a very simple operation but imagine something a lot more complicated. The error would increase dramatically without anyone being the wiser.
So, I did address it and prove it wrong. Because you basically want the units of the desired result to be added on to the final value. And when I said that you are designing for the real world what I meant is this:
You D13 and D6 variables are not numbers. They are lengths. The result of their subtraction is also a length. And the square root of a length, although a valid unit in physics, cannot be used to describe a length any more than a length can be used to describe an area. That's what I meant. Your expression was a physical impossibility. Not doable in the real world.
So, any method, reasoning, proposal, or algorithm that allows a physical impossibility to go through unchecked, reduces the potential of a parametric software and equates it with that of Matlab, Excel, and others. And these are indeed legacy, traditional and unevolved software. The ability of modern Parametric CAD to "translate" the units and catch these errors is the evolution in software and provides immense power to their user.
Now... All the rest about stupid, pissing, knowing or not knowing, is irrelevant.