Problem w równaniach - wartość zmiennej globalnej nie jest rozpoznawana

Cédric_T · 20 Lipiec 2022 13:01

Witam

Spotykam się z naprawdę dziwnym przypadkiem równań w Solidworks 2018 SP5. Być może bawiłem się tym wszystkim we wszystkich kierunkach, ale to, co zawracają moje równania, pozostawia mnie bez słowa i więcej niż sceptycznego...

Zwracam się do ciebie, bo może będziesz miał wytłumaczenie, dlaczego nie robię tego, co trzeba...

Na załączonym przeze mnie obrazku zobaczysz , że przeprowadziłem 2 testy z dwiema zmiennymi globalnymi uzyskanymi w różny sposób: "diametre_bulbe", której wartość 301 uzyskuje się przy użyciu wymiaru ze szkicu (linie od 16 do 19) oraz "diametre_bulbe_mesure", której wartość również 301 jest tym razem uzyskiwana bezpośrednio za pomocą narzędzia pomiarowego w równaniach.

Chodzi o to, aby użyć jednej z tych zmiennych globalnych (tej, która będzie działać poprawnie ;-) ), aby móc kontrolować, czy usunąć funkcje powtarzania.

Zobaczysz w liniach obrazu, który załączam, że wykonuję różne testy, ale wyniki są niesamowite:

- Na podstawie wierszy 17 i 21 możemy wywnioskować, że "diametre_bulbe" i "diametre_bulbe_mesure" są większe lub równe 300,999999999

- Z linii 18 i 22 możemy wywnioskować, że "diametre_bulbe" i "diametre_bulbe_mesure" są mniejsze niż 301,00000001

- Z liniami 19 i 23 możemy wywnioskować, że "diametre_bulbe" i "diametre_bulbe_mesure" nie wydają się równać 301...

Myślałem, że to problem z jednostkami, ale kiedy przeprowadziłem kilka testów, nie wydaje się, aby był powiązany.

Mam nadzieję, że moje powyższe wyjaśnienia związane z załączonym obrazem pozwolą mi zrozumieć moje obawy...

Mając nadzieję, że ktoś z Was będzie w stanie naprowadzić mnie na trop, wytłumaczyć mi... lub wesprzyj mnie w bólu, który odczuwam w obliczu tej więcej niż ciekawej niespójności ;-)

Cédric.T

incoherence_valeur_variable_globale.png

Sylk · 20 Lipiec 2022 16:07

Witam, Może to być spowodowane brakiem dokładności pomiaru.

1. sprawdź, dokładna wartość (poza kropką dziesiętną) twojego pomiaru. W tym celu należy wybrać opcję wyświetlania maksymalnej liczby cyfr po przecinku dziesiętnym w opcjach dokumentu (tak, aby ułamki dziesiętne były widoczne w tabeli równań) oraz we właściwościach wymiaru, aby wyświetlić ułamki dziesiętne w wymiarze.

Ponieważ jeśli rzeczywista wartość to na przykład 301.000000000[3] (tj. wartość z przedziału od 301 do 301.000000001), ale zaokrąglona do "301" (lub nawet "301.00000000" z dokładnością do 8) na wyświetlaczu, ponieważ dokładność wyświetlania jest ograniczona, wyjaśnia to wynik.

Tyle tylko, że nawet jeśli wyświetla zaokrągloną wartość 301.0000000000, to wie, że nie jest to do końca... 0 zatem nie daje jej jako równej, ale granica SW do obliczenia poza 8 miejscami po przecinku uniemożliwia nam sprawdzenie, czy wartość jest dokładnie ... 0[3]. (Myśląc o tym, myślę, że SW musi przechowywać tego rodzaju wartość jako [między 16,000000000 a 16,000000001], wyjaśniając, dlaczego wie, czemu nie jest równa, co jest wyższe, a od czego mniejsze, ale nie wie, czemu jest równa)...

Jak dowodzi ten zrzut ekranu z moich testów, z wartością kursu "16.0000 0000 3":

Wprowadzając ręcznie wartość 301 (a raczej 301.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Krótko mówiąc, nie byłby to wynik równania, który jest nieprawidłowy, ale jego interpretacja.

Podsumowując, biorąc pod uwagę, że twoja wartość "301" wydaje się być napędzana przez obliczenia, które potencjalnie nigdy nie dadzą wyniku ściśle równego 301, uważam, że najlepszym równaniem, jakie możesz napisać, jest wariant mojej zmiennej "test4", który da ci tolerancję 301±0,0000000009 lub zakres reakcji 0,000000018 mm. Wydaje mi się, że do przyjęcia:

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

Pozdrowienia

equation_fausse_incoherence.png

Cédric_T · 21 Lipiec 2022 08:06

Witam

Dziękuję za tę wyczerpującą odpowiedź.

Jeśli umieściłem wszystkie te ułamki dziesiętne w moich równaniach, to po to, aby wykonać testy i spróbować zidentyfikować problem. Ale w "trybie normalnym" nie manipuluję tymi wszystkimi ułamkami dziesiętnymi.

Mówiąc dokładniej, pierwotny wymiar 301, który odpowiada średnicy okręgu na szkicu, uzyskuje się za pomocą rodziny części, w której wybór wymiaru jest ograniczony na liście zdefiniowanych wartości całkowitych (201; 251; 301; 351; itd...). Szkic ten znajduje się w szkielecie, który jest przywoływany w zespole.

Montaż to miejsce, w którym mam równania i problem opisany wcześniej.

Moje zmienne globalne są używane do łączenia z tym wymiarem szkieletu, dzięki czemu mogę wykonywać akcje usuwania/przywracania w tym zestawie.

Próbowałem zobrazować ułamki dziesiętne mojego pomiaru, jak sugerujesz na początku swojej odpowiedzi, i są tylko "0".

Rozwiązanie linii "test4" to takie, które rozważałem jako plan B, jeśli nie znajdę niczego lepszego, pozwalając sobie na większą tolerancję, ponieważ mogę sobie na to pozwolić, biorąc pod uwagę krok, który mam między 2 stronami na mojej liście (201; 251; 301; 351; 401; itd...).

Świetnie, że go proponujesz, bo nadaje mu to więcej znaczenia (nie tylko ja miałem to na myśli ;-) ).

Dziękujemy za czas spędzony na przeprowadzaniu testów i udzielaniu odpowiedzi.

Poczekam jeszcze trochę, aby zobaczyć, czy nadejdą inne odpowiedzi, a jeśli nie, zweryfikuję ten post za kilka dni.

Miłego dnia.

Cédric powiedział:

Sylk · 21 Lipiec 2022 12:37

Witam

Wyobrażam sobie, że musi "dostosować" wartości Twojej listy do najbliższych "komputerowych" wartości podczas ich pobierania, co zniekształca testy porównawcze.

Myślę więc, że najlepszym rozwiązaniem, bardziej eleganckim, krótszym, prostszym, szybszym i bezpieczniejszym, byłoby następujące; Przekonwertuj wartość z listy na liczbę całkowitą:

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

Mogłem o tym pomyśleć wcześniej...

Możliwe jest również przekonwertowanie wartości wymiaru bezpośrednio na liczbę całkowitą w zmiennej źródłowej, dzięki czemu nie trzeba jej używać w każdym teście:

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

Premia:

W przypadku, gdy każda wartość na liście musi zwracać wartość true (unsuppressed), alternatywa, którą uważam za bardziej klasyczną niż powtarzanie testów lub mnożenie operatorów OR w równaniu:

Ponieważ Twoja lista wydaje się zwiększać o 50 między każdą wartością, małe obliczenia pozwalają zweryfikować je wszystkie w jednym teście.

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

W tym przykładzie dowolna wartość wymiaru, która jest liczbą całkowitą równą (50 * i ) +1 ] zwraca wartość "unspressed". Gdzie i jest jedną z liczb całkowitych w tym zakresie, tutaj od 4 do 10. Prawidłowe wartości to zatem (201,251,301,351,401,451,501).

Pozdrowienia

Cédric_T · 21 Lipiec 2022 13:01

Witam ponownie,

Tak, jest szansa, że dokona tego rodzaju korekty, co wyjaśniałoby mój problem.

Rzeczywiście, rozwiązanie polegające na konwersji na liczbę całkowitą jest lepsze. Dziękuję, że to zaproponowałeś: może nie pomyślałeś o tym od razu, ale ja w ogóle o tym nie pomyślałem z mojej strony... Jesteś o krok przede mną ;-)

Jeszcze raz dziękuję.

Cédric powiedział:

Sylk · 21 Lipiec 2022 13:45

Proszę. Dodałem mały bonus w mojej poprzedniej wiadomości.

Cédric_T · 22 Lipiec 2022 07:12

Dzięki za bonus.

Nie pasuje to do moich potrzeb, ponieważ na mojej liście potrzebuję tylko jednego "niestłumionego" i wszystkich innych "stłumionych". Ale może się przydać innym członkom społeczności ;-)