I am trying to make parameters for a project, using formula to find a right-angled triangle edge length, knowing another edge, and all angles values.
In this particular case:
unknown length = known length * tan(opposite angle)
So lets says, i create:
var1 (the known length)(number : length value)
var2 (the known angle that I will use)(number : angle value)
var3 (the looked for length)(number : length) = var1*tan(var2)
At this point, when I click the green mark to create my formula, nothing happen, no added formula, no error message, no freeze or anything…
I though that ZW3D had trouble getting a [length] from a [length] and an [angle], but if I try and purposedly multiply 2 length var and force the result as [lenght] (rather than [area]), I do get an error message.
Hi Nicolas,
Submit your file for review and we will see what we can learn.
I presume you are using equation manager.
There are two steps, Accept and Apply. No calculation until apply.
Cheers - Paul
Hi guys,
After Cowboy answer, I tried again, straight with varX names, and yes it worked. I was kinda embarrassed. I am kinda sure I faced a situation at which point, the equation manager was still not working even with simple renamed vars.
I dived back into it this morning, and I think I know what happened.
First, the problem seems to come from my vars naming. Then, when I tried with simple names, I must have edited original names that were already bugged out. 2021-03-22.zip (4.0 MB)
I wasn’t able to reproduce the exact same situation, yet this video recorded attempt shows the odd behavior.
For the time being, I will have to name my vars differently. Another problem I inflicted myself…
Hi PDPatel,
So I went even further and got rid of any accent and spaces and underscores.
At one point, my vars are named like this: Epaisseur = 35mm DepouilleLONG =3° DepouilleLONGmm =Epaisseurtan(DepouilleLONG)*
At which point it work.
I had to close part/equation manager back to .Z3 root twice because the accent were coming back.
Then I try to progressively put my original naming back, to try and see at which point the bug occur.
First, I just switch the É in the first var. Épaisseur = 35mm DepouilleLONG =3° DepouilleLONGmm =Epaisseurtan(DepouilleLONG)*
The var call doesn’t update. Any var1 value change doesn’t update the var3 result.
Then i try with renamming the second var using underscore: Épaisseur = 35mm Depouille_LONG =3° DepouilleLONGmm =Epaisseurtan(Depouille_LONG)*
The var call does update.
So I think it is the É that zw3D doesn’t digest ^^ (at least in this case).
What is odd is how the software seems to lose sight of a var once you change its name with an improper character.
Hi Nicholas,
I think the issue is a perception.
We think of names as meaning and description therefor we use them that way. Fair enough.
But the software sees them as part of an equation, this even applies to object names which are part of the variable when it is applied.
So in a mathematical sense the simpler we can keep the names the better as the software simple does not have the scope to accept every and any character as it is processing every character and looking for logical meaning.
So my rules for ALL names are:
NO SPACES - ever.
Underscore is ONLY non alpha Character.
That’s it. You may get away with more as you have done but you might also have difficulties as you have done.
Does that make sense?
Cheers - Paul
I have found Equation Manager to be a bit like a 5 year old child. It does what you expect most of the time but every now and again, it just has a meltdown and what worked yesterday does not work today. It seems worse with lots of equations and multilevel references between assembly and subassembly Managers. I have Equation Managers at project level, assembly level and subassembly level with values being calculated and passed down between levels for parameter driven models. My theory is that it gets overwhelmed and the values it is referring to are not completed calculation before the result is called for. As Paul says, keep names simple and check that your model has actually used the values which should have been calculated.
Jim
