#### stepalibre

##### Alibre Super User

Yes, and this is often more efficient and faster than generating from scratch every time, even if the features do exist.especially when there are features needed that are not part of the standard API

You should upgrade or use an alternative browser.

- Thread starter Nautilus
- Start date

Yes, and this is often more efficient and faster than generating from scratch every time, even if the features do exist.especially when there are features needed that are not part of the standard API

Units are variables:

View attachment 41298

The OP has a variable named "m" which conflicts with Alibre's "m" variable. Alibre's "m" is 1000 mm which overrides any user variable of the same name.

Equation Dp1 is:

`(m*Z1)/200`

which is actually `(1000 * 58)/200`

which equals `290`

The OP expects:

`(m*Z1)`

to be `(5 * 58)`

which equals `290`

. But the variable `m`

is `1000`

instead of `5`

, so the equation has to be divided by `200 `

to get the correct result because `1000/200 = 5`

.Yep I see. Yes I didn't change the parameter names from the example, I assumed that "m" was intentional and I was trying to point out that units have values exactly the point. Using unit variables as parameter names should be avoided (inside Distance types).

***** ]. If you make a parameter named "m" with a value of 5, "m" should equal 5. The editor should not allow unit variables/constants to be used as parameter names if they cannot be reassigned a new value.

edit: [ * ] Even for Distance types

I would expect "m" to equal 5 as it is assigned a new value [Alibre's "m" is 1000 mm which overrides any user variable of the same name.

edit: [ * ] Even for Distance types

Last edited:

This is the key to the whole problem.

The OP has a variable named "m" which conflicts with Alibre's "m" variable. Alibre's "m" is 1000 mm which overrides any user variable of the same name.

Equation Dp1 is:`(m*Z1)/200`

which is actually`(1000 * 58)/200`

which equals`290`

The OP expects:`(m*Z1)`

to be`(5 * 58)`

which equals`290`

. But the variable`m`

is`1000`

instead of`5`

, so the equation has to be divided by`200`

to get the correct result because`1000/200 = 5`

.

Unit variables can be used as names, but if the parameter type is Distance they will be interpreted as unit constants. I guess so! Now I have a headache thinking about this editor.

Last edited:

Let me give you an example of what I intend to do. In the end I can get the result I want. But you have to apply a number of scale factors that don't make any sense to me.

I have traced the flank of the tooth using Grant's method. As the gear has more than 34 teeth, it can be made with a single radius (RU)

I have used the European modulus system instead of the "diametrical pitch" used in the US and UK

I will study all the information you have kindly provided, to see what I can optimize.

I have traced the flank of the tooth using Grant's method. As the gear has more than 34 teeth, it can be made with a single radius (RU)

I have used the European modulus system instead of the "diametrical pitch" used in the US and UK

I will study all the information you have kindly provided, to see what I can optimize.

I'm pretty sure if you just change that variable "m" to something else it will fix the main issue you are having. I updated the equations as shown and your gear stayed the same. This should at least help the equations be more straightforward.Let me give you an example of what I intend to do. In the end I can get the result I want. But you have to apply a number of scale factors that don't make any sense to me.

I have traced the flank of the tooth using Grant's method. As the gear has more than 34 teeth, it can be made with a single radius (RU)

I have used the European modulus system instead of the "diametrical pitch" used in the US and UK

I will study all the information you have kindly provided, to see what I can optimize.

This shouldn't be required but it is for Alibre's equation editor. I have MathCAD and Smath studio calculations that use "m" that I don't want to change. I can update or have an alias but I'd rather not, they work fine in SolidWorks.I'm pretty sure if you just change that variable "m" to something else it will fix the main issue you are having. I updated the equations as shown and your gear stayed the same. This should at least help the equations be more straightforward.

It's safe to use any parameter name (that is allowed) as long as you don't make it a Distance type which is the cause of other problems as well as this issue.

Last edited:

So your advice is to do all calculations in Scale type parameters and then reference those in Distance type parameters to avoid the units and reserved parameter name issues. This sounds like a good practice. I've always just used Distance and been frustrated when I ran into weird glitches which were only solved by putting units into the equations. This discussion has been helpful, thanks!This shouldn't be required but it is for Alibre's equation editor. I have MathCAD and Smath studio calculations that use "m" that I don't want to change. I can update or have an alias but I'd rather not, they work fine in SolidWorks.

It's safe to use any parameter name (that is allowed) as long as you don't make it a Distance type which is the cause of other problems as well as this issue.

Scale is really just a number and Distance types are dimensions.? Distance types return the unit set in your part. If you need a parameter to return a unit then Distance type would work fine.

It doesn't hurt to quickly create a parameter in Scale and Distance types to test and compare the results if you're not sure. Yes, my approach is to use Scale types for most calcs and Distance only when I need to return a unit which isn't as often. Great to hear this helped!

Very interesting utilities. Your in-depth knowledge of the program is evident ;-)Save some time... Download my gear generator - it's part of the Utilities for Alibre Add-on.

https://www.alibre.com/forum/index.php?resources/utilities-for-alibre.125/

I understand your pain with the equation editor!

David