Souci dans les équations - valeur de variable globale non reconnue

[Cédric_T]

Bonjour,

 

Je rencontre un cas de figure vraiment bizarre avec les équation dans Solidworks 2018 SP5. J'ai beau avoir trituré tout ça dans tous les sens, ce que me retourne mes équations me laisse sans voix et plus que sceptique...

Je me retourne vers vous car peut-être que vous aurez une explication sur ce que je ne fais pas comme il faut...

Dans l'image que je joins, vous verrez que j'ai fait 2 tests avec deux variables globales obtenues différemment : "diametre_bulbe" dont la valeur 301 est obtenue en utilisant une cote d'une esquisse (lignes 16 à 19) et "diametre_bulbe_mesure" dont la valeur également 301 est cette fois obtenue en utilisant directement l'outil de mesure dans les équations.

L'idée est d'utiliser une de ces variables globales (celle qui voudra bien fonctionner correctement ;-) )pour pouvoir piloter la suppression ou non de fonctions de répétitions.

Vous verrez dans les lignes de l'image que je joins que je fais différents tests mais que les résultats sont étonnants :

- Avec les lignes 17 et 21, on peut conclure que "diametre_bulbe" et "diametre_bulbe_mesure" sont supérieures ou gales à 300.99999999

- Avec les lignes 18 et 22, on peut conclure que "diametre_bulbe" et "diametre_bulbe_mesure" sont inférieure à 301.00000001

- Avec les lignes 19 et 23, on peut conclure que "diametre_bulbe" et "diametre_bulbe_mesure" ne semblent pas égales à 301...

 

J'ai pensé à un souci avec des unités mais en faisant des tests, cela ne semble pas lié.

J'espère que mes explications ci-dessus associées à l'image jointes permettent de cerner mon souci...

En espérant que quelqu'un parmi vous saura me mettre sur une piste, m'expliquer... ou me soutenir dans la douleur que je ressens devant cette incohérence plus que curieuse ;-)

 

Cédric.T

incoherence_valeur_variable_globale.png

[Sylk]

Bonjour, C'est peut-être dû à un manque de précision de la mesure.

1ère vérification, la valeur exacte (au délà de la virgule) de ta mesure. Pour cela il faut choisir d'afficher le maximum de chiffres après la virgule depuis les options du document (pour que les décimales soient visibles dans la table des équations) et dans les propriétés de cotation pour visualiser les décimales sur la cotation.

Car si la valeur réelle est de par exemple 301.00000000[3] (soit une valeur entre 301 et 301.00000001) mais arrondie à "301" (ou même "301.00000000" avec la précision de 8) à l'affichage parce que la précision d'affichage est limitée ça explique le résultat.

Sauf que voilà, même s'il affiche la valeur arrondie 301.00000000, il sait qu'elle n'est pas pile poil ...0 donc ne la donne pas comme égale, mais la limite de SW à calculer au délà de 8 décimales nous empêche de vérifier que la valeur est précisément ...0[3]. (En y réfléchissant, je pense d'ailleurs que SW doit stocker ce genre de valeur comme [comprise entre 16.00000000 et 16.00000001], expliquant pourquoi il sait à quoi ce n'est pas égal, à quoi c'est supérieur, et à quoi c'est inférieur, mais sans savoir à quoi c'est égal)...

Comme en témoigne cette capture de mes tests, avec la valeur de cote "16.0000 0000 3" :

En saisissant la valeur manuellement à 301 (ou plutôt 301.00000000000000000000000000000, ou mieux, remplacer par 300 puis par 301, pour s'assurer d'effacer toute décimale infime) l'équation sera cohérente avec ce qui est affiché.

En somme ce ne serait pas le résultat de l'équation qui est incorrect, mais son interprétation.

Pour conclure étant donné que ta valeur "301" semble pilotée par un calcul qui ne donnera potentiellement jamais un résultat strictement égal à 301, je crois que la meilleure équation que tu puisses écrire est une variante de ma variable "test4" qui te donnera une tolérance de 301±0.000000009, soit une plage de réaction de 0.000000018mm. Acceptable il me semble :

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

Cordialement

equation_fausse_incoherence.png

[Cédric_T]

Bonjour,

 

Merci pour cette réponse complète.

Si j'ai mis toutes ces décimales dans mes équations, c'était pour faire les tests et tenter de cerner le problème. Mais en "mode normal", je ne manipule pas toutes ces décimales.

Pour être plus précis, la cote de 301 originale, qui correspond au diamètre d'un cercle dans une esquisse, est obtenue via une famille de pièces dans laquelle la sélection de la cote est bridée dans une liste de valeurs entières définie (201;251;301;351;etc...). Et cette esquisse est située dans un squelette qui est rappelé dans un assemblage.

L'assemblage est le lieu où j'ai les équations et le problème expliqué précédemment.

Mes variables globales servent à faire le lien avec cette cote de squelette, pour pouvoir faire des actions de suppression/annulation de suppression dans cet assemblage.

 

J'ai essayé de visualisé les décimales de ma mesure comme tu le suggères au début de ta réponse, et il n'y a que des "0".

 

La solution de la ligne "test4" est une que j'ai envisagée d'utiliser en plan B si jamais je ne trouve pas mieux, en me permettant plus de tolérance car je peux me le permettre vu le pas que j'ai entre 2 cotes dans ma liste (201;251;301;351;401;etc...).

C'est chouette que tu la propose car ça lui donne plus de sens (je ne suis pas seul à l'avoir eu en tête ;-) ).

 

Merci pour le temps que tu as passé à faire tes tests et à répondre.

Je vais attendre encore un peu voire si d'autres réponses arrivent, et sinon, je validerai ce poste dans quelques jours.

 

Bonne journée.

Cédric

[Sylk]

Bonjour,

J'imagine qu'il doit "ajuster" les valeurs de ta liste avec les valeurs "informatiquement" les plus proches au moment de les récupérer ce qui fausse les tests de comparaison.

Du coup je crois que LA meilleure solution, plus élégante, plus courte, plus simple, plus rapide, et plus sûre, serait la suivante ; convertir en entier la valeur issue de la liste :

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

J'aurais pu y penser plus tôt...

Il est aussi possible de convertir en entier directement la valeur de cotation dans la variable source pour ne pas avoir à l'utiliser dans chaque test :

"diametre_bulbe" ---> = int("RD3@Annotations")
"RepetitionX" ---> = IIF( "diametre_bulbe" = 301 , "unsuppressed" , "suppressed" ) 

 

 

Bonus:

Dans le cas où chaque valeur de ta liste doit retourner true (unsuppressed), une alternative que je trouve plus classe que de répéter des tests ou multiplier les opérateurs OR dans une équation :

Puisque ta liste semble s'incrémenter de 50 entre chaque valeur, un petit calcul permet de toutes les valider en un seul 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" )

Dans cet exemple toute valeur de cotation qui est un [ entier égal à (50 * i ) +1 ] retourne "unsuppressed". Où i est l'un des entiers de ce range allant, ici, de 4 à 10. Les valeurs valides sont donc (201,251,301,351,401,451,501).

Cordialement

[Cédric_T]

Re-Bonjour,

 

Oui il y a des chances qu'il fasse ce genre d'ajustement, ce qui expliquerait mon souci rencontré.

 

En effet, la solution de convertir en entier est meilleure. Merci de l'avoir proposée : tu n'y as peut-être pas pensé de suite, mais je n'y avais pas pensé du tout de mon côté... Tu as pris un train d'avance sur moi ;-)

 

Encore merci.

Cédric

[Sylk]

Je t'en prie. J'ai rajouté un petit bonus dans mon message précédent.

[Cédric_T]

Merci pour le bonus.

Il ne correspond pas à mon besoin car dans ma liste, je n'ai besoin que d'un "unsuppressed" et tous les autres "suppressed". Mais il pourrait servir à d'autres membres de la communauté ;-)