Something funky going on with formulae in user parameters

[sristic]

Can anyone explain why the expression in the screenshot isn't working? There's something weird going on. Exponentiation doesn't work other than using '1' as the exponent. Multiplication is broken. Division seems to work. Just upgraded to the latest available version 2.0.5790. There is no sketch. Just started entering these basic parameters. No leading/trailing spaces. Can't figure it out. I started with a more complex expression then started segmenting it to find where it was breaking, which led me to multiplication and exponentiation being broken. There might be others too.

[HughesTooling]

Because the answer is square mm. You need to add /1mm at the end to cancel out the units.

Mark

[HughesTooling]

You might find this help page useful for expected unit types and returns.

Mark

[sristic]

Thanks Mark. Your solution works for that particular scenario but the actual formula I was trying to input was this:

sqrt((oRingCS/2)^2-(oRingGap/2)^2)

Adding /1mm at the end doesn't work in this instance. oRingCS and oRingGap are both in 'mm'. I'm not clear what adding the /1mm does, if I was honest. The other link you provided didn't help me understand any better unfortunately.

[HughesTooling · Accepted solution]

Dividing by the units makes the parameter unitless.

So for your problem this should work, /2mm removes the mm units from oRingCS for example. This is assuming the parameter you're creating is using mm for its units.

sqrt((oRingCS/2mm)^2-(oRingGap/2mm)^2)

Mark

[sristic]

Ah, I see. Thanks Mark. That worked. I think I follow the logic now. I've got a solution to my problem but I think I need to play around some more to understand it fully. 

[charlestauber]

This behaviour is nothing short of crazy. 

Here's a simple example. I create a rectangle. I create a parameter called "width" and assign it the unit of inches. I create a driving dimension and assign it the value "width". I want the height of the rectangle to be the square of the width. I create a second driving dimension and assign it a value "width^(2)".

The height doesn't work because the length of that side, per the equation given in the assignment of the height dimension, is in the units of square inches. It doesn't work because a linear measurement (i.e. the length of a rectangle's side) can't be in square inches.  That Fusion is squaring the units, themselves, is a poorly chosen - programmed - behaviour. What should be happening is that Fusion is smart enough to square the VALUE and not the UNITS.

For this to work, I have to manually manage the units, in this case dividing by 1 inch so as to "cancel out" the squared units to get an answer that is in linear inches (i.e. not square inches).

While engineering calculations involve managing of units, to the best of my experience, that has never been the case in CAD modelling work.  It is a ill-conceived behaviour in the context of CAD modelling and adds unnecessary complexity to what should be a simple task.

My immediate use is to layout the spacing of frets for a guitar fingerboard. It is a geometric series in which each fret is a constant times 2 to the exponent n/12, where each term (fret) in the geometric series (n) increases by one. With Fusion's behaviour, that means that each term in the geometric series will need its own "factor" to correct the units of mm^(n/12) (i.e. divide by 1*2^n/12 to obtain a linear measurement). In other CAD systems, this micromanagement isn't necessary.