Problem in equations - global variable value not recognized

Out of category
1

Hello

 

I encounter a really weird case with equations in Solidworks 2018 SP5. I may have fiddled with all this in all directions, but what my equations are turning back leaves me speechless and more than skeptical...

I'm turning to you because maybe you'll have an explanation for why I'm not doing the right thing...

In the image I attach, you will see that I did 2 tests with two global variables obtained differently: "diametre_bulbe" whose value 301 is obtained using a dimension from a sketch (lines 16 to 19) and "diametre_bulbe_mesure" whose value also 301 is this time obtained by directly using the measurement tool in the equations.

The idea is to use one of these global variables (the one that will work properly ;-) ) to be able to control whether or not to remove repeat functions.

You will see in the lines of the image I am attaching that I am doing different tests but that the results are amazing:

- With lines 17 and 21, we can conclude that "diametre_bulbe" and "diametre_bulbe_mesure" are greater than or equal to 300.999999999

- With lines 18 and 22, we can conclude that "diametre_bulbe" and "diametre_bulbe_mesure" are less than 301.00000001

- With lines 19 and 23, we can conclude that "diametre_bulbe" and "diametre_bulbe_mesure" do not seem to equal 301...

 

I thought it was a problem with the units but when I did some tests, it doesn't seem to be related.

I hope that my explanations above associated with the attached image allow me to understand my concern...

Hoping that someone among you will be able to put me on a track, explain to me... or support me in the pain I feel in front of this more than curious incoherence ;-)

 

Cédric.T


incoherence_valeur_variable_globale.png
2

Hello, This may be due to a lack of measurement accuracy.

1st check, the exact value (beyond the decimal point) of your measurement. To do this, you must choose to display the maximum number of digits after the decimal point from the document options (so that the decimals are visible in the table of equations) and in the dimension properties to view the decimals on the dimension.

Because if the real value is for example 301.000000000[3] (i.e. a value between 301 and 301.000000001) but rounded to "301" (or even "301.00000000" with the precision of 8) on display because the display accuracy is limited, that explains the result.

Except that even if he displays the rounded value 301.000000000, he knows that it is not exactly ... 0 therefore does not give it as equal, but the limit of SW to be calculated beyond 8 decimal places prevents us from verifying that the value is precisely ... 0[3]. (Thinking about it, I think SW must store this kind of value as [between 16.000000000 and 16.000000001], explaining why he knows what it's not equal to, what it's higher, and what it's less than, but not knowing what it's equal to)...

As evidenced by this screenshot of my tests, with the odds value "16.0000 0000 3":

By manually entering the value at 301 (or rather 301.00000000000000000000000000000000000000, or better, replace with 300 and then with 301, to make sure to erase any minute decimal) the equation will be consistent with what is displayed.

In short, it would not be the result of the equation that is incorrect, but its interpretation.

To conclude, given that your "301" value seems to be driven by a calculation that will potentially never give a result strictly equal to 301, I believe that the best equation you can write is a variant of my variable "test4" that will give you a tolerance of 301±0.0000000009, or a reaction range of 0.000000018mm. Acceptable it seems to me:

IIF(
 "diametre_bulbe" > 300.99999999 and "diametre_bulbe" < 301.00000001 , "unsuppressed" , "suppressed"
)

Kind regards


equation_fausse_incoherence.png
4 Likes
3

Hello

 

Thank you for that comprehensive answer.

If I put all these decimals in my equations, it was to do the tests and try to identify the problem. But in "normal mode", I don't manipulate all these decimals.

To be more precise, the original dimension of 301, which corresponds to the diameter of a circle in a sketch, is obtained via a family of parts in which the selection of the dimension is limited in a list of defined integer values (201; 251; 301; 351; etc...). And this sketch is located in a skeleton that is recalled in an assembly.

The assembly is where I have the equations and the problem explained earlier.

My global variables are used to link with this skeleton dimension, so that I can do delete/undelete actions in this assembly.

 

I tried to visualize the decimals of my measurement as you suggest at the beginning of your answer, and there are only "0s".

 

The solution of the "test4" line is one that I considered using as a plan B if I don't find anything better, allowing myself more tolerance because I can afford it given the step I have between 2 sides in my list (201; 251; 301; 351; 401; etc...).

It's great that you propose it because it gives it more meaning (I'm not the only one to have had it in mind ;-) ).

 

Thank you for the time you spent doing your tests and responding.

I'll wait a little longer to see if other answers arrive, and if not, I'll validate this post in a few days.

 

Have a nice day.

Cédric

1 Like
4

Hello

I imagine that it must "adjust" the values of your list with the closest "computer" values when retrieving them, which distorts the comparison tests.

So I think that THE best solution, more elegant, shorter, simpler, faster, and safer, would be the following; convert the value from the list to an integer:

IIF( int("diametre_bulbe") = 301 , "unsuppressed" , "suppressed" )

I could have thought of it earlier...

It is also possible to convert the dimension value directly to an integer in the source variable so that you don't have to use it in each test:

"diametre_bulbe" ---> = int("RD3@Annotations")

 

 

Bonus:

In the case where each value in your list must return true (unsuppressed), an alternative that I find more classy than repeating tests or multiplying the OR operators in an equation:

Since your list seems to increment by 50 between each value, a little calculation allows you to validate them all in a single test.

diametre_bulbe ---> = (int("RD3@Annotations")-1) / 50
Repetition ---> = IIF( "diametre_bulbe"=int("diametre_bulbe") and "diametre_bulbe">3 and "diametre_bulbe"<11, "unsuppressed", "suppressed" )

In this example, any dimension value that is an [ integer equal to (50 * i ) +1 ] returns "unsuppressed". Where i is one of the integers in this range, here from 4 to 10. The valid values are therefore (201,251,301,351,401,451,501).

Kind regards

4 Likes
5

Hello again,

 

Yes, there is a chance that he will make this kind of adjustment, which would explain my problem.

 

Indeed, the solution of converting to integer is better. Thank you for proposing it: you may not have thought of it right away, but I hadn't thought of it at all on my side... You're one step ahead of me ;-)

 

Thank you again.

Cédric

1 Like
6

Please. I added a little bonus in my previous message.

7

Thanks for the bonus.

It doesn't fit my need because in my list, I only need one "unsuppressed" and all the others "suppressed". But it could be useful to other members of the community ;-)

1 Like