W rozmowach z konstruktorami (także na forach internetowych) bardzo często poruszany jest temat definicji mechanizmów w systemie CATIA V5. Wielu z tych, którzy tworzą swoje projekty w tym systemie i ma doświadczenie z pracy w innych systemach nie zdaje sobie sprawy z tego, że definicja relacji pomiędzy komponentami oraz ich wzajemne położenie (polecenia z grupy Assembly Constraints w środowisku Assembly Design) nie są równoważne z definicją mechanizmu!
Andrzej Wełyczko
Relacje typu Assembly Constraints pozwalają „jedynie” na zdefiniowanie wzajemnego położenia poszczególnych komponentów projektowanego wyrobu w przestrzeni 3D, na przykład współosiowość, zgodność (przyleganie płaszczyzn), odległość, kąt, itd. Oczywiście można zadać pytanie: skąd takie „ograniczenia” i dlaczego system nie tworzy w tym samym czasie par kinematycznych pomiędzy wskazanymi komponentami? Odpowiedzi należałoby szukać u twórców systemu. A ta pewnie byłaby zbliżona do mojej: nie każdy projekt musi zawierać definicję mechanizmu oraz możliwość symulacji jego ruchu i różnego typu analiz. Jeśli po zdefiniowaniu relacji typu Assembly Constraints trzeba sprawdzić kinematykę projektowanego wyrobu, to w systemie CATIA V5 definicję mechanizmu (czyli określenie par kinematycznych, a nie tylko wzajemnego położenia komponentów) wykonujemy w środowisku DMU Kinematics i co ważne, definicja par kinematycznych może być wykonana automatycznie na podstawie istniejących relacji typu Assembly Constraints.
Rys. 1
Rozważmy przykład mechanizmu krzywka-popychacz (Rys. 1), który w najprostszym wariancie może być zbudowany z trzech komponentów (Korpus, Popychacz i Krzywka), a do definicji par kinematycznych wystarczy przygotować podstawowe elementy geometryczne (punkt, linia, krzywa, płaszczyzna, itp.). W każdym z tych komponentów trzeba zdefiniować wymagane elementy podstawowe (tu linie, krzywe, płaszczyzny oznaczone kolorem przypisanym do każdego komponentu). Trzeba także ustalić wzajemne położenie tych komponentów za pomocą poleceń z grupy Assembly Constraints:
- Fix.1 – Sztywne ustalenie położenia Korpusu w przestrzeni projektowej:
- Korpus ma odebrane wszystkie stopnie swobody,
- Coincidence.2 – Współosiowość osi wałka Krzywki (żółta linia) z osią otworu w Korpusie (szara pozioma linia):
- Krzywka może się obracać względem osi otworu w Korpusie,
- Krzywka może się przesuwać wzdłuż osi otworu w Korpusie,
- Offset.3 – Ustalenie położenia Krzywki względem Korpusu:
- Krzywka nie może się przesuwać wzdłuż osi otworu w Korpusie,
- Zamiast relacji Offset można zastosować relacje typu Coincidence – na przykład pomiędzy dwoma płaszczyznami zdefiniowanymi odpowiednio w modelu Krzywka i w modelu Korpus (płaszczyzna konturu Krzywki musi być w tym samym miejscu w przestrzeni 3D, w którym znajduje się oś Popychacza),
- Coincidence.4 – Współosiowość osi Popychacza (fioletowa linia) z osią otworu w Korpusie (szara pionowa linia):
- Popychacz może się obracać względem osi otworu w Korpusie,
- Popychacz może się przesuwać wzdłuż osi otworu w Korpusie.
I tu dla niektórych pierwsze „rozczarowanie”: jak zdefiniować wzajemne powiązanie krzywki z popychaczem? W środowisku Assembly Design nie ma możliwości zdefiniowania relacji typu punkt ślizgający się po krzywej, krzywa ślizgająca się po krzywej czy krzywa tocząca się po innej krzywej – wszystkie te relacje są specyficzne dla definicji mechanizmu. Na przykład próba zastosowania relacji typu Coincidence nie daje oczekiwanego rezultatu, bo system pozwala na wskazanie punktu, linii lub płaszczyzny (Rys. 2) – nie można wskazać dwóch ślizgających lub toczących się po sobie krzywych.
Rys. 2
Jeśli zadaniem konstruktora jest definicja mechanizmu, to kolejne kroki trzeba wykonać w środowisku DMU Kinematics. Zdefiniowane wcześniej relacje typu Assembly Constraints mogą być podstawą do definicji par kinematycznych – dlatego zastosowano polecenie Assembly Constraints Conversion (Rys. 3). Zanim jednak system zdefiniuje pary kinematyczne musi być zdefiniowany mechanizm – tu Mechanism.1.
Rys. 3
Na podstawie Assembly Constraints system może rozpoznać dwie pary kinematyczne (Unresolved pairs: 2/2). Na tym etapie konstruktor musi zdecydować czy chce wykonać to rozpoznanie automatycznie (Rys. 4) czy ręcznie (Rys. 5).
Rys. 4
Rys. 5
Jeśli definicja par kinematycznych ma być wykonana ręcznie, to dla każdej pary komponentów (tu Korpus.1–Krzywka.1) system prezentuje listę relacji typu Assembly Constraints zdefiniowanych dla tych komponentów oraz proponuje parę kinematyczną (tu dla Offset.3 i Coincidence.2 system sugeruje parę typu Revolute).
Na tym etapie definicji mechanizmu nie jest możliwa symulacja jego ruchu (Rys. 6) – system podpowiada, że konieczne jest zdefiniowanie przynajmniej jednego polecenia (lub poleceń) napędzającego ten mechanizm.
Rys. 6
Po wykonaniu analizy mechanizmu (Rys. 7) widać wyraźnie, że zdefiniowane są tylko dwie (Number of joints: 2) pary kinematyczne (Revolute.1 (Krzywka.1, Korpus.1) i Cylindrical.2 (Popychacz.1, Korpus.1)), rozpoznane na podstawie wcześniej zdefiniowanych relacji typu Assembly Constraints (Number of joints: 2) – brakuje pary kinematycznej Krzywka-Popychacz, czyli powiązania ruchu krzywki z ruchem popychacza.
Rys. 7
Jak napędzać taki mechanizm? Odpowiedź jest prosta: trzeba zapewnić obrót Krzywki względem Korpusu. Która para kinematyczna łączy Krzywkę z Korpusem? Oczywiście: Revolute.1 (Krzywka.1, Korpus.1). Definicja pary Revolute.1 musi być zmodyfikowana w taki sposób, aby system „wiedział”, że obrót wałka krzywki (aktywna opcja Angle driven dla Revolute.1 – Rys.8) jest funkcją napędową tego mechanizmu. Po zdefiniowaniu polecenia napędowego stopień swobody mechanizmu został zredukowany z DOF=3 do DOF=2.
Rys. 8
Trzeba jeszcze zdefiniować parę kinematyczną typu Slide Curve (Rys. 9), aby powiązać obrót krzywki z ruchem popychacza. Po zaakceptowaniu tej definicji mechanizm ma 0 stopni swobody (DOF=0) i można wykonać symulację jego ruchu (Rys. 10).
Rys. 9
Rys. 10
Możliwość obrotu popychacza została odebrana po zdefiniowaniu pary Slide Curve.3, bo krzywe tworzące tę parę kinematyczną (fioletowy łuk popychacza i żółty kontur krzywki) leżą na jednej płaszczyźnie i są do siebie styczne. Gdyby ten warunek geometryczny nie był spełniony to definicja pary kinematycznej typu Slide Curve nie byłaby możliwa (Rys. 11).
Rys. 11
Mechanizm został zdefiniowany i za pomocą polecenia Simulation with Commands można sprawdzić czy działa poprawnie (Rys. 12). Definicja mechanizmu to jednak nie tylko możliwość symulacji jego ruchu, bo w środowisku DMU Kinematics można przeanalizować poprawność przemieszczania poszczególnych komponentów, śledzić zmiany wartości wybranych parametrów, wygenerować trajektorię ruchu wybranych punktów, itd. To jednak za dużo na artykuł o ograniczonej objętości. Zainteresowanych odsyłam do dokumentacji systemu CATIA V5 lub literatury książkowej – jest nawet książka na ten temat napisana po polsku!
Rys. 12
Model wyrobu, w którym zdefiniowano mechanizm można oczywiście wzbogacić o elementy bryłowe (Rys. 13) i/lub powierzchniowe, oraz wykonać kolejne analizy poprawności projektowania, na przykład analizę kolizji podczas ruchu.
Rys. 13
Andrzej Wełyczko
ps.
W systemie CATIA V6 zagadnienie definiowania mechanizmów jest znacznie prostsze, bo omówione powyżej relacje typu Assembly Constraints i Kinematics Joints są jednocześnie tworzone podczas definicji relacji Engineering Connection.
artykuł pochodzi z wydania 7/8 (82/83) lipiec/sierpień 2014
