Probleem in vergelijkingen - globale variabele waarde niet herkend

[Cedric_T]

Hallo

 

Ik kom een heel raar geval tegen met vergelijkingen in Solidworks 2018 SP5. Ik heb misschien in alle richtingen met dit alles gerommeld, maar wat mijn vergelijkingen terugdraaien, laat me sprakeloos en meer dan sceptisch ...

Ik wend me tot jou omdat je misschien een verklaring hebt waarom ik niet het juiste doe...

In de afbeelding die ik bijvoeg, zul je zien dat ik 2 tests heb gedaan met twee globale variabelen die anders zijn verkregen: "diametre_bulbe" waarvan de waarde 301 wordt verkregen met behulp van een dimensie uit een schets (regels 16 tot 19) en "diametre_bulbe_mesure" waarvan de waarde ook 301 is deze keer verkregen door rechtstreeks gebruik te maken van het meetinstrument in de vergelijkingen.

Het idee is om een van deze globale variabelen te gebruiken (degene die goed zal werken ;-) )om te kunnen bepalen of herhaalfuncties al dan niet moeten worden verwijderd.

Je zult in de lijnen van de afbeelding die ik bijvoeg zien dat ik verschillende tests doe, maar dat de resultaten verbluffend zijn:

- Met de regels 17 en 21 kunnen we concluderen dat "diametre_bulbe" en "diametre_bulbe_mesure" groter zijn dan of gelijk zijn aan 300,999999999

- Met de regels 18 en 22 kunnen we concluderen dat "diametre_bulbe" en "diametre_bulbe_mesure" kleiner zijn dan 301,00000001

- Met de regels 19 en 23 kunnen we concluderen dat "diametre_bulbe" en "diametre_bulbe_mesure" niet gelijk lijken te zijn aan 301...

 

Ik dacht dat het een probleem was met de eenheden, maar toen ik wat tests deed, leek het er niets mee te maken te hebben.

Ik hoop dat mijn uitleg hierboven in verband met de bijgevoegde afbeelding me in staat stelt mijn bezorgdheid te begrijpen ...

In de hoop dat iemand onder jullie me op het goede spoor kan zetten, me kan uitleggen... of steun me in de pijn die ik voel voor deze meer dan merkwaardige incoherentie ;-)

 

Cédric.T

incoherence_valeur_variable_globale.png

[Sylk]

Hallo, Dit kan te wijten zijn aan een gebrek aan meetnauwkeurigheid.

1e controle, de exacte waarde (voorbij de komma) van uw meting. Om dit te doen, moet u ervoor kiezen om het maximale aantal cijfers achter de komma weer te geven uit de documentopties (zodat de decimalen zichtbaar zijn in de tabel met vergelijkingen) en in de dimensie-eigenschappen om de decimalen op de dimensie weer te geven.

Want als de werkelijke waarde bijvoorbeeld 301.000000000[3] is (d.w.z. een waarde tussen 301 en 301.000000001) maar afgerond op "301" (of zelfs "301.00000000" met de precisie van 8) op het scherm omdat de weergavenauwkeurigheid beperkt is, verklaart dat het resultaat.

Behalve dat zelfs als hij de afgeronde waarde 301.000000000 weergeeft, hij weet dat het niet precies is ... 0 geeft het daarom niet als gelijk, maar de limiet van SW die boven 8 cijfers achter de komma moet worden berekend, verhindert ons om te verifiëren dat de waarde precies is ... 0[3]. (Als ik erover nadenk, denk ik dat SW dit soort waarde moet opslaan als [tussen 16.000000000 en 16.000000001], waarbij hij uitlegt waarom hij weet waar het niet gelijk aan is, wat het hoger is en wat het minder is dan, maar niet weet waar het gelijk aan is)...

Zoals blijkt uit deze screenshot van mijn tests, met de odds waarde "16.0000 0000 3":

Door handmatig de waarde in te voeren op 301 (of liever 301.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Kortom, het zou niet het resultaat van de vergelijking zijn dat onjuist is, maar de interpretatie ervan.

Tot slot, gezien het feit dat uw "301"-waarde lijkt te worden gedreven door een berekening die mogelijk nooit een resultaat zal opleveren dat strikt gelijk is aan 301, geloof ik dat de beste vergelijking die u kunt schrijven een variant is van mijn variabele "test4" die u een tolerantie van 301±0,0000000009 geeft, of een reactiebereik van 0,0000000018 mm. Acceptabel lijkt mij:

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

Vriendelijke groeten

equation_fausse_incoherence.png

[Cedric_T]

Hallo

 

Dank u voor uw uitgebreide antwoord.

Als ik al deze decimalen in mijn vergelijkingen stopte, was het om de tests uit te voeren en te proberen het probleem te identificeren. Maar in de "normale modus" manipuleer ik niet al deze decimalen.

Om preciezer te zijn, de oorspronkelijke afmeting van 301, die overeenkomt met de diameter van een cirkel in een schets, wordt verkregen via een familie van onderdelen waarin de selectie van de dimensie beperkt is in een lijst van gedefinieerde gehele getallen (201; 251; 301; 351; enz...). En deze schets bevindt zich in een skelet dat in een assemblage wordt herinnerd.

De assemblage is waar ik de vergelijkingen heb en het probleem dat eerder is uitgelegd.

Mijn globale variabelen worden gebruikt om te koppelen aan deze skeletdimensie, zodat ik verwijder-/ongedaan maakacties kan uitvoeren in deze assemblage.

 

Ik heb geprobeerd de decimalen van mijn meting te visualiseren, zoals u aan het begin van uw antwoord suggereert, en er zijn alleen "0-en".

 

De oplossing van de "test4"-regel is er een die ik overwoog te gebruiken als een plan B als ik niets beters vind, mezelf meer tolerantie gunnen omdat ik het me kan veroorloven gezien de stap die ik heb tussen 2 kanten in mijn lijst (201; 251; 301; 351; 401; enz...).

Het is geweldig dat je het voorstelt omdat het meer betekenis geeft (ik ben niet de enige die het in gedachten had ;-) ).

 

Bedankt voor de tijd die je hebt besteed aan het doen van je tests en het reageren.

Ik zal nog even wachten om te zien of er andere antwoorden komen, en zo niet, dan zal ik dit bericht over een paar dagen valideren.

 

Fijne dag.

Cédric

[Sylk]

Hallo

Ik stel me voor dat het de waarden van uw lijst moet "aanpassen" met de dichtstbijzijnde "computer" -waarden bij het ophalen, wat de vergelijkingstests vertekent.

Dus ik denk dat DE beste oplossing, eleganter, korter, eenvoudiger, sneller en veiliger, de volgende zou zijn; Converteer de waarde uit de lijst naar een geheel getal:

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

Ik had het eerder kunnen bedenken...

Het is ook mogelijk om de dimensiewaarde rechtstreeks om te zetten naar een geheel getal in de bronvariabele, zodat u deze niet in elke test hoeft te gebruiken:

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

 

 

Bonus:

In het geval dat elke waarde in je lijst waar (niet onderdrukt) moet teruggeven, een alternatief dat ik stijlvoller vind dan het herhalen van tests of het vermenigvuldigen van de OR-operatoren in een vergelijking:

Aangezien uw lijst tussen elke waarde met 50 lijkt te stijgen, kunt u ze met een kleine berekening allemaal in één test valideren.

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 dit voorbeeld retourneert elke dimensiewaarde die een [ geheel getal gelijk aan (50 * i ) +1 ] is "niet-onderdrukt". Waar i een van de gehele getallen in dit bereik is, hier van 4 tot 10. De geldige waarden zijn dus (201.251.301.351.401.451.501).

Vriendelijke groeten

[Cedric_T]

Hallo weer,

 

Ja, er is een kans dat hij dit soort aanpassingen zal maken, wat mijn probleem zou verklaren.

 

Inderdaad, de oplossing van het converteren naar geheel getal is beter. Bedankt dat je het voorstelt: je hebt er misschien niet meteen aan gedacht, maar ik had er van mijn kant helemaal niet aan gedacht... Je bent me een stap voor ;-)

 

Nogmaals bedankt.

Cédric

[Sylk]

Alstublieft. Ik heb een kleine bonus toegevoegd in mijn vorige bericht.

[Cedric_T]

Bedankt voor de bonus.

Het past niet bij mijn behoefte, want in mijn lijst heb ik er maar één nodig "niet-onderdrukt" en alle andere "onderdrukt". Maar het kan nuttig zijn voor andere leden van de gemeenschap ;-)