TRUST

[NateLiquidGravity]

How much do you trust the Alibre/Geomagic Design program? :?:
For the life of me; I can't figure how to accurately and parametrically calculate out how many times A_ANGLE2 goes into A_ANGLE1 using any method. I understand that some of the expected cases don't make sense however it is a test to try to find any way to do this simple math. And technically units should cross out in this case making it pure unitless math. I have attached a screenshot of this and uploaded the part for others to test.

How many people trust what the program gives them? How many people make bad parts because they don't even know of this?

 

[Hughes_Tooling]

The result ANGLE_TEST is 360°/72 Radians, don't know why it's doing that though. You can get the correct angle if you add another parameter A_ANGLE3 of 1° and change ANGLE_TEST to A_ANGLE1/A_ANGLE2*A_ANGLE3



Mark

 

[Sunprojekt82]

Hi

Please check your settings

 

[JordanCClark]

Not sure what you're trying to say, Sunprojekt82. The issue is how the equation editor handles itself. Actually it's in the conversion between degrees and radians and rounding errors. The more conversions that happen the more error you're likely to see.

I'll also say that this is the first time I've seen an angle divided by angle. So thanks for that, Nate...

Here is a shot where the units are set to radians. A1 & A2 are entered in as 360deg and 72deg, respectively. A3 & A4 are straight numeric entry. Since A3/A4 does come out to 5, the problem becomes clear that is, in fact, a rounding error.

 

[Hughes_Tooling]

After looking at Jordans example using degrees after the parameters works as well.


Mark

 

[Hughes_Tooling]

Looks like my last post is wrong and the equation editor get a bit confused.


Mark

 

[Lew_Merrick]

This is an area where what passes for the documentation well and truly sucks!

The Equation Editor is exceptionally strongly typed. When you divide a unit specific value by another unit specific value you must "cast" the result as either a Count (integer value) or a Scale (floating point value)! This is because in a more normal additive value assignment, you can mix units such as (say) .375in + 15mm + 2m and have everything convert to your default length units!

The conversion from either Count or Scale values to other units is simple -- you multiply them by a value of 1 unit and "cast" them as Length or Angle.

Now, mind you, I spent a lot of time beating my head into this particular brick wall a few years ago, so it now falls into the obvious to me category (and I rarely think about it anymore).

 

[NateLiquidGravity]

Lew, You are right it is poorly documented and has poor error catching and IMHO just poorly designed. I've brought up this numerous times. Sometimes it was my mistake (due to lack of documentation) sometimes it was IMHO a legitimate error that was denied by others.

However in this case neither Count nor Scale results in the correct value due to rounding errors internal to the program, so I tried the others just to see what they resulted in. Scale does round up when displayed in a dimension because of my units settings but if used for further calculations results in errors.

 

[Lew_Merrick]

Lew, You are right it is poorly documented and has poor error catching and IMHO just poorly designed. I've brought up this numerous times. Sometimes it was my mistake (due to lack of documentation) sometimes it was IMHO a legitimate error that was denied by others.

However in this case neither Count nor Scale results in the correct value due to rounding errors internal to the program, so I tried the others just to see what they resulted in. Scale does round up when displayed in a dimension because of my units settings but if used for further calculations results in errors.

Nate,

While I will not argue about the limitations or incomplete consideration given to the Equation Editor, I will state that, as somebody who regularly designs to +/-.00005 inch (intending manufacture to be +/-.0005 inch typically) I find that the Equation Editor is sufficient for most tasks. The thing I have found that makes up for the multitude of "lacks" in the Equation Editor is Andy Ayre's WizoScript -- a needed and exceptionally useful development!