W przygotowaniu

nr 5-6(25-26) 2017
dostępny
po 29.12.2017

Wydanie aktualne

nr 3-4(23-24) 2017
dostępny w pdf, wydanie flash tutaj

Wydania archiwalne

nr 1-2(21-22) 2017
dostępny w pdf, wydanie flash tutaj

nr 1-2(19-20) 2015
dostępny w pdf, wydanie flash tuta

numer 1(18) 2014
dostępny w pdf, wydanie flash tutaj

numer 1(17) 2013
dostępny w pdf, wydanie flash tutaj

numer 1(16) 2012
dostępny
w archiwum

numer 1(15) 2011
dostępny
w archiwum

numer 4(14) 2010
HD dostępny
w archiwum

numer 3(13) 2010
HD już dostępny
w archiwum

numer 2(12) 2010
dostępny
w archiwum

numer 1(11) 2010 dostępny
w archiwum

numer 9(10) 2009
już dostępny
w archiwum...

Obserwuj @CADblog_pl

Poniedziałek, 27.03.2017 r.

Dogadać się...

Ciężko współpracować z kimś, z kim nie mamy możliwości swobodnego porozumiewania się. Można oczywiście ustalić jakiś kod, system znaków, który w pewnym stopniu rozwiąże problem komunikacji, ale nic nie zastąpi dobrej znajomości danego języka – przynajmniej przez jedną ze stron. Oczywiście idealna sytuacja ma miejsce wtedy, gdy obie strony porozumiewają się w danym języku. Tak jest też w przypadku systemów CAD, CAM, CAE...

Maciej Stanisławski (Artykuł ukazał się w magazynie „STAL. Metale i nowe technologie” wyd. 1-2/2017)

Problem wymiany informacji jest tak stary, jak moment, w którym użytkownik jednego systemu CAD stanął przed koniecznością użycia danych pochodzących z innego systemu. Często jedynym sposobem było nakreślenie od nowa danego rysunku w aktualnym środowisku pracy. Gdy nie było w powszechnym użyciu skanerów pozwalających na przetworzenie narysowanej lub wydrukowanej dokumentacji płaskiej do postaci cyfrowej (narzędzi typu „scantodwg”, „pdftodwg converter” etc.), zastępy „kreślarzy” pracowicie przenosiły papierowe dane do cyfrowego świata. Z kolei już w latach 70. XX wieku zaczęto poszukiwać rozwiązania, które w sposób profesjonalny i całkowicie „cyfrowy” pozwoliłoby na wymianę danych między powstającymi niemalże jak „grzyby po deszczu” systemami CAD.

To właśnie w tym okresie firmy zajmujące się opracowywaniem systemów CAD 2 i 3D zaczęły osiągać coraz większe profity. Na początku lat osiemdziesiątych większość firm (i to nie tylko liczących się potentatów) korzystała z oprogramowania wspomagającego pracę inżynierów-projektantów, zarówno w sektorach automotive i przemyśle lotniczym, ale także elektroniki użytkowej (wtedy jeszcze często „elektryki użytkowej”) i innych. Na rynku konkurowały ze sobą takie programy, jak: Auto-Draft (opracowany przez Auto-trol), Calma, CADDS, CADAM (przejęty od Lockheeda przez IBM), IGDS (M&S Computing) i Unigraphics (firmowany przez McAuto’s, które w 1976 roku wchłonęło firmę United Computing; ten system ewoluował do współcześnie wykorzystywanych rozwiązań NX i Solid Edge).

Obecność na rynku i wykorzystywanie coraz większej liczby systemów spowodowało konieczność poszukiwania pierwszych standardowych formatów zapisu i wymiany danych pomiędzy różnymi systemami. To dzięki współpracy Boeinga, General Electric i NBS (z ang. Narodowe Biuro Standardów) powstał IGES (Initial Graphics Exchange Specification) – skuteczne narzędzie translacyjne, pozwalające na konwertowanie różnych zbiorów krzywych 3D, czy też powierzchni – na jeden format danych czytelny dla innych systemów. O jego popularności może świadczyć fakt, iż przyjęty wtedy format IGES stosowany jest również obecnie.

Skoro mowa o IGES, nie można pominąć milczeniem formatu STEP (Standard for the Exchange of Product data), powstałego w latach osiemdziesiątych. ISO (International Standards Organization), zajmujące się m.in. tworzeniem globalnego standardu dla różnych typów formatów, uznało STEP za ulepszony format IGES.

Era translacji
Na rynku pojawiły się najróżniejszego rodzaju translatory, które z jednej strony pozwalały na zapis natywnych plików do formatów „pośrednich”, „uniwersalnych” etc. (jak wspomniane STEP, IGES), które z większą lub mniejszą dokładnością można było otworzyć w dowolnym systemie CAD, a z drugiej pozwalały na import formatów natywnych bezpośrednio do środowiska danego systemu.

Co ciekawe, niektóre narzędzia translacji okazały się niezbędne nawet do odczytu plików w obrębie rodziny systemów CAD pochodzących od jednego producenta, ale różniących się wersjami; zakres dokonanych usprawnień i zmian powodował, iż oprogramowanie traciło tzw. kompatybilność wsteczną i pliki przygotowane w nowszej wersji nie były rozpoznawane przez starszy system, a czasem także odwrotnie...

Okazuje się zatem, że nawet wykorzystywanie pełnego pakietu oprogramowania pochodzącego od jednego producenta nie ustrzeże całkowicie użytkownika od problemów związanych z wymianą danych. Zwłaszcza, że prędzej czy później stanie od przed koniecznością wykorzystania danych od partnera, dostawcy zewnętrznego, który może korzystać z zupełnie innego systemu CAD...

Era multiCAD
Powiedzmy sobie szczerze, że większość osób zgodzi się ze stwierdzeniem, iż nie można wskazać jednego najlepszego rozwiązania CAD (i pochodnych) dostępnego na rynku. Tyle jest najlepszych rozwiązań, ile branż lub ile zastosowań; najprościej rzecz ujmując, różne systemy sprawdzają się lepiej lub gorzej w zależności od rodzaju i złożoności zadania projektowego, które jest z ich pomocą realizowane. Stąd już tylko krok od uświadomienia sobie, jak ważne/istotne znaczenie ma wymiana danych w środowiskach multiCAD (słusznie lub niesłusznie określanych czasem skrótem mCAD, który raczej oznacza coś zupełnie innego – przyp. redakcji).

Wszyscy uznani producenci rozwiązań CAD są tego w pełni świadomi. I chociaż w ich przypadku, tworzenie własnych „natywnych” formatów plików było najprostszym sposobem na promowanie swoich rozwiązań (i „przywiązywanie” do nich klienta), o tyle od kilku lat zaczynamy mieć do czynienia z odwróceniem tego trendu. Teraz przewagę może zdobyć producent, które rozwiązanie bez problemu poradzi sobie z odczytem danych pochodzących z innych systemów i to bez potrzeby uciekania się do jakichś „zewnętrznych” narzędzi translacyjnch, czy uciekania się do zapisu i odczytu danych z formatów pośrednich.

W przypadku systemów PDM (Product Data Management) i PLM (Product Lifecycle Management) jesteśmy tego świadkami od dawna; czym zresztą byłyby rozwiązania z definicji mające zarządzać danymi, gdyby potrafiły obsługiwać jedynie wybrane formaty plików? Dlatego powszechnie np. systemy klasy Teamcenter (Siemens PLM Software) nadzorują pliki CAD pochodzące z CATIA i SOLIDWORKS (Dassault Systemes), podobnie zresztą jak platforma 3DEXPERIENCE (Dassault Systemes) pozwala na zarządzanie danymi z systemów NX i Solid Edge.

Co jednak w przypadku środowiska CAD?

Nie tylko Synchronous Technology
Zaimplementowanie przez Siemens PLM Software do swoich rozwiązań nowości, jaką była Technologia Synchroniczna, udowodniło malkontentom, że możliwy jest import plików natywnych z systemów pochodzących od różnych producentów bezpośrednio do środowiska pracy – w tym przypadku chodziło konkretnie o – Solid Edge i NX. Bez uciekania się do zewnętrznych translatorów, bez potrzeby zapisywania danych do formatów neutralnych.

Modele części pochodzące z innych systemów (1), dzięki zastosowaniu Synchronous Technology
mogą być edytowane tak, jak natywne pliki (2)...

Źródło: Cadalyst

I przez kilka lat po wprowadzeniu Synchronous Technology, w powszechnym odbiorze kojarzona była ona właśnie z możliwościami teoretycznie bezproblemowego importu danych z systemów zewnętrznych – a przecież stanowiło to jedynie wycinek możliwości drzemiących w Technologii Synchronicznej. Ta sytuacja dobitnie pokazuje, jakiego znaczenia nabrała możliwość swobodnej wymiany danych.

Na działania ze strony innych producentów rozwiązań CAD przyszło trochę poczekać, ale również oni postarali się, aby ich systemy potrafiły „dogadywać się” między sobą.

Jesienią ubiegłego roku na portalu SolidSmack.com ukazał się artykuł, którego Autor (Adam Ohern) sprawdził, czy nową, bardzo przydatną funkcjonalność dostępną w SOLIDWORKS 2017 (mowa o SOLIDWORKS Interconnect – czytaj także tutaj), można odnaleźć także w innych systemach CAD. Okazuje się, że przeprowadzone przez niego „śledztwo” wykazało, że... owszem. Jak można się domyśleć, funkcjonalność owa to możliwość odczytywania danych z innych systemów.

Istotnie, nowy SOLIDWORKS pozwala użytkownikowi na import zarówno części, jak i złożeń pochodzących z CATIA, NX, Creo PTC, Solid Edge i Autodesk Inventor bezpośrednio do środowiska SOLIDWORKS. Co więcej – razem z geometrią, wiązaniami i relacjami, charakterystyką zdefiniowanych wcześniej materiałów i pełną strukturą (hierarchiczną) importowanego złożenia. O tym, jak jest to wygodne, nie trzeba przekonywać nikogo pracującego na co dzień ze złożeniami. Autor artykułu (korzystający z rozwiązania DS SolidWorks) z zadowoleniem odnotowuje fakt, iż obecnie, współpracując z inżynierem projektującym w Creo, nie musi korzystać z formatów pośrednich (wymieniony zostaje tutaj wspomniany wcześniej STEP) i tracić czasu na odbudowanie wszystkich informacji utraconych w procesie translacji. Po wczytaniu złożenia ma natychmiastowy dostęp do wszystkich danych.

SOLIDWORKS 3D Interconnect umożliwia tworzenie wiązań i projektowanie z wykorzystaniem „importowanych” danych,
analogicznie do standardowych komponentów SOLIDWORKS...

Źródło: DPS Software

Podkreśla także fakt, iż może bez problemu przebudowywać geometrię elementów zaimportowanego złożenia. Co więcej, nie polega to na tym, iż system udostępnia użytkownikowi parametryczną historię danego elementu/złożenia, ale automatycznie tworzy na jego podstawie natywny plik SOLIDWORKS (wykorzystując w tym celu funkcjonalność Insert Part).

Okazuje się jednak, że podobne funkcjonalności można znaleźć... w Creo (Creo Unite, dostępne od ok. 2014 roku), a także w Inventorze 2016 (AnyCAD).

Funkcjonalność Creo Unite jest bardzo zbliżona do tej obecnej w najnowszej edycji SOLIDWORKS, ale obejmuje tylko import z CATIA, NX i SOLIDWORKS (jedynie częściowo obsługuje formaty natywne Inventora i Solid Edge). Autor artykułu zamieszczonego na SolidSmack stawia mimo to niemalże znak równości między „SOLIDWORKS 2017 Interconnect”, a o trzy lata wcześniejszym Creo Unite. Dlaczego? Oba rozwiązania śledzą BREP importowanych złożeń, w obu można poddawać importowane złożenia i komponenty edycji – z zachowaniem zdefiniowanych zależności, wiązań etc. Wiele wskazuje na to, że w przypadku funkcjonalności AnyCAD (Inventor) – jest podobnie.

Moduł Communicator umożliwia użytkownikowi systemu BricsCAD Platinum w miarę wygodną pracę
na importowanych plikach części i złożeń...

Artykuł o BricsCAD Communicator dostępny tutaj

Tymczasem także producenci rozwiązań CAD z niższej półki cenowej skutecznie wprowadzają podobne możliwości także do swoich systemów. Znakomitym przykładem może być tutaj BricsCAD (od wersji V16), doposażony w moduł Communicator. W swej bazowej postaci BricsCAD pozwalał na import danych z zewnętrznych formatów (np. Inventor, SOLIDWORKS), ale użytkownik otrzymywał jedynie bryłę, uproszczoną geometrię – i czekał go żmudny proces jej odtworzenia w swoim środowisku pracy. Zainstalowanie modułu Communicator (warto wspomnieć, że wersja instalacyjna owego modułu zajmuje więcej miejsca, niż kompletny system CAD 2D/3D, jakim jest BricsCAD) sprawia, iż otwarcie pliku w natywnym formacie nie oznacza, że importujemy samą geometrię modelu/złożenia; z modułem Communicator uzyskujemy dostęp do całej struktury modelu (tylko wersja BricsCAD Platinum) i w łatwy sposób możemy modyfikować poszczególne, interesujące nas komponenty.

Praca w środowisku multiCAD staje się powoli „znakiem czasu”, stąd zrozumiała chęć producentów i dostawców rozwiązań CAD do maksymalnego usprawnienia procesów wymiany danych między różnymi systemami. Kto na tym korzysta? Końcowy użytkownik, pozostaje więc cieszyć się z takiego stanu rzeczy...

(ms)

(Artykuł ukazał się w magazynie
„STAL. Metale i nowe technologie” wyd. 1-2/2017)

 [ powrót na stronę główną ]

reklama

Blog monitorowany przez: