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.
Trigonometric Functions in the Equation Editor
- Thread starter Nautilus
- Start date
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 290The 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.
stepalibre
Alibre Super User
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).
edit: [ * ] Even for Distance types
I would expect "m" to equal 5 as it is assigned a new value [ * ]. 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
Last edited:
stepalibre
Alibre Super User
I never see issues like this because I always perform calculations inside Scale types. "m" as a Scale will equal 5 or whatever value you set. Distance types interpret "m" as a meter. I avoid using Distance types for calculations, Scale instead.
stepalibre
Alibre Super User
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.
stepalibre
Alibre Super User
View my file. I've updated it to use Scales instead. Check my work but I believe the result is exactly the same as yours.
My version:
Your version:
My version:
Your version:
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.
Attachments
stepalibre
Alibre Super User
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.
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!
stepalibre
Alibre Super User
The terms used are confusing.
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!
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 ;-)