Do Projektu iAutomatyka dołączyli:

Publikacja zgłoszona do 🎁 Konkursu iAutomatyka

Czym jest DeviceNet? Przykład konfiguracji robota Kuka

1133 wyświetleń, autor: Agnieszka P.

DeviceNet to otwarty protokół komunikacyjny stworzony przez firmę Allen Bradley. Mało znany w Europie, szczególnie popularny jest w krajach Ameryki Północnej gdzie łączy miliony urządzeń. Głównym zastosowaniem sieci DeviceNet jest komunikowanie urządzeń przemysłowych (np. sensorów, czy urządzeń wykonawczych) z urządzeniami wyższego poziomu (np. sterowniki PLC).

Skąd się wziął DeviceNet?

Zacznijmy od tego, że DeviceNet oparty jest na protokole CAN, magistrali komunikacyjnej stworzonej w 1986 roku dla rynku motoryzacyjnego. Nowa technologia musiała spełniać wysokie wymagania stawiane przez branżę. To sprawiło, że zainteresował się nią również przemysł.

Niedługo później, bo już na początku lat 90 amerykańskie firmy Cincinnati Milacron, Allen-Bradley i Honeywell rozpoczęły wspólny projekt dla automatyki przemysłowej oparty na CAN. Chociaż ostatecznie przedsięwzięcie upadło, dwie ostatnie firmy kontynuowały pracę samodzielnie. Efektem tego było powstanie dwóch protokołów. Smart Distributed System od Honeywell i właśnie DeviceNet od Allen Bradley.

Reklama


Warto wspomnieć, że w tamtym czasie w USA nowy protokół DeviceNet był technologią wręcz rewolucyjną – wcześniej w automatyce przemysłowej wykorzystywany był praktycznie tylko Modbus RTU ze swoją szeregową komunikacją (wyślij zapytanie, odbierz odpowiedź, idź do następnego urządzenia – i tak w nieskończoność…).

DeviceNet jest standardem otwartym – Allen-Bradley zdecydował o podzieleniu się technologią z innymi. Jej rozwój i promocja nadzorowana jest przez organizację ODVA (z ang. Otwarte Stowarzyszenie Sprzedawców DeviceNet).

Architektura sieci DeviceNet  – model OSI

Aby zrozumieć procesy komunikacyjne zachodzące w opisywanej sieci musimy spojrzeć na jego model OSI (pełna nazwa to ISO OSI RM – z ang. ISO Open Systems Interconnection Reference Model – model odniesienia łączenia systemów otwartych). DeviceNet tak naprawdę łączy wcześniej już wspomniany CAN, który pełni rolę „szkieletu”, i protokół CIP.

Zacznijmy od dołu: dwie pierwsze warstwy to cechy protokołu CAN. Pierwsza z nich, warstwa fizyczna odpowiedzialna jest za fizyczną realizację transmisji danych: określa elektryczne i mechaniczne parametry medium transmisyjnego, prędkość wymiany danych, a także charakterystyki przesyłanych sygnałów (np. poziomy napięć czy wartości prądu). Tu realizowana jest transmisja ciągu zer i jedynek pomiędzy komunikującymi się urządzeniami bez interpretacji znaczenia tych danych i struktury zawartych w nich informacji. Do warstwy fizycznej jeszcze wrócimy.

Warstwa łącza danych nadzoruje jakość przekazywanych przez warstwę fizyczną informacji. Tutaj ciągi danych są pakowane w ramki. Chociaż CAN definiuje kilka różnych typów ramek, DeviceNet używa z nich tylko jednego rodzaju.

Warstwy sesji, prezentacji i aplikacji są warstwami wyższego rzędu i zaimplementowany jest tu protokół CIP. Technologia jest niezależna od niższych warstw modelu i definiuje właściwości urządzeń przemysłowych i metod ich komunikowania. To tutaj są generowane i przygotowywane dane do wysłania. Inaczej niż w innych protokołach, gdzie informacje często są wysyłane w formie rejestrów i bitów, w CIP ich struktura opiera się na obiektach. Mechanizm działania CIP jest kompletnie niezależny od niższych warstw.

DeviceNet jest siecią typu Producent-Konsument. Podstawą tego modelu jest przesyłanie danych przy użyciu mechanizmu multicast. Pozwala to na równoczesne odbieranie przez wiele urządzeń sieci tych samych danych, od jednego producenta. Każda ramka danych posiada identyfikator pozwalający na stwierdzenie, czy dana informacja jest ważna dla danego urządzenia, czy może należy ją zignorować. Model Producent-Konsument dzięki możliwości przekazywania danych tylko wtedy, kiedy się zmieniają, pozwala także na efektywniejsze wykorzystanie sieci.

Warstwa fizyczna

Medium transmisyjne stanowią dwie skręcone pary przewodów w ekranie. Ogromną zaletą jest tutaj fakt, że linie sygnałowe i zasilanie (24 VDC) dostarczane są w jednej wiązce. Jedna para żył służy do zasilania (czerwony i czarny), druga para wykorzystywana jest do komunikacji pomiędzy urządzeniami (biały i niebieski). Takie rozwiązanie upraszcza i obniża cenę okablowania.

W DeviceNecie istnieje możliwość ustawienia 3 wartości prędkości transmisji danych (125, 250 i 500 Kbps). Istotne jest przy tym przestrzeganie dopuszczalnych odległości. Wybór prędkości równocześnie definiuje maksymalną długość sieci (przy 125Kbps wynosi 500m).

Komunikacja może odbywać się w formie peer to peer, multimaster i master – slave. W jednej sieci mogą wymieniać informacje maksymalnie 64 urządzenia – węzły. Każdemu z nich przypisywany jest indywidualny adres od 0 do 63, nazwany tu MAC ID.  Nowe urządzenia zazwyczaj mają fabrycznie nadany adres 63, więc w celu uniknięcia niepotrzebnych błędów i pytań o to, co znowu nie działa, warto konfigurując sieć na wszelki wypadek zostawić go wolnym.

Topologia sieci opiera się na technologii trunk/drop – na magistrali mogą występować odgałęzienia. Maksymalna suma odgałęzień zależy od prędkości transmisji i wynosi 156m, a jedno odgałęzienie może wynosić do 6 metrów. Urządzenia mogą być dołączane i odłączane bez konieczności wyłączania napięcia.

Reklama


Na każdym z zakończeń magistrali muszą znaleźć się terminatory, które zapobiegają zjawisku odbijania się sygnałów docierających do tych miejsc i w konsekwencji powstawaniu zakłóceń. W przypadku DeviceNetu wymagane są te o wartości 121 Ohm (1%, 0.25 W) lub większe. Terminatory wpina się pomiędzy niebieski i biały przewód. Bez nich komunikacja nie będzie działać prawidłowo.

DeviceNet i robot Kuka 

W tej części pokażę jak skonfigurować połączenie opisywanego protokołu na przykładzie robota Kuka KRC2. Skomunikuję go z DeviceNetowym hubem I/O firmy Balluff. Kuka będzie w tym przypadku pełnić funkcję Mastera, a moduł skonfigurujemy jako Slave’a.

Zacznijmy od warstwy fizycznej. W przypadku robota producent oferuje dwie możliwości połączenia: standardową przez slot na karcie MFC, który jest w standardzie tego robota lub poprzez dodatkową kartę DeviceNetową. Korzystam z pierwszej, która ma jednak pewne ograniczenia: karta zawsze pełni rolę Mastera z MAC ID równym 0. Złącze znajduje się w drzwiach szafy robota i ma numer X801.

To 5 pinowy Phoenix, który podpinam zgodnie z opisem dostępnym w dokumentacji technicznej robota. Pamiętam przy tym o dołączeniu terminacji. Na skrajne piny dostarczam zasilanie 24V. W piny sygnałowe (2 i 3) podłączam żyły, które następnie połączę z odpowiadającymi im w module Balluffa.

Przejdźmy teraz do konfiguracji modułu Balluffa. Jest to model BNI0003 posiadający 16 wejść/wyjść cyfrowych. Na zdjęciu znajduje się również dedykowany dla modułu terminator.

W jego górnej części hub’a znajduje się kilka ważnych elementów:

  1. Złącze do zasilania (na sensory i aktuatory);
  2. BUS IN;
  3. Switch do ustawienia prędkości transmisji;
  4. Switche do ustawienia adresu MAC ID;
  5. BUS OUT;

Wykorzystując switche, nadaję modułowi MAC ID 8 i prędkość transmisji 500 kBaud. Dokładnie te same wartości ustawię później w robocie. Zasilam złącze 1 (AUX Power) i dołączam kabel komunikacyjny do połączenia nr 5 (DeviceNet OUT). Wchodzą tu wiązki sygnałowe z robota oraz dodatkowe zasilanie. W złącze 2 wpinam terminator.

Reklama


Od strony hardware’owej wszystko już gotowe – czas przejść do konfiguracji software’owej z poziomu robota. Zadanie okazuje się niezbyt skomplikowane: należy odblokować odpowiedni driver, zmapować I/O oraz ustawić parametry transmisji. Aby mieć dostęp do tych parametrów wybieram Expert User Group .

Następnie przechodzę do odblokowania drivera. Jego zadaniem jest cykliczne sprawdzanie i aktualizowanie stanu IO magistrali. Poleceniem Configure -> IO -> Edit Config otwieram plik iosys.ini.

W sekcji [DRIVERS] uaktywniam sterownik Devnet odkomentowując 14 linijkę kodu.

Poniżej tej sekcji znajdują się pola służące do przypisania konkretnych I/O robota dla wybranych rodzajów komunikacji. O tym, jak ustawić to pole dowiaduję się z dokumentacji technicznej wykorzystanego modułu:

Muszę zatem zadeklarować 7 bajtów wejść i 4 bajty wyjść. W 58 linijce pliku iosysy.ini znajduję pole dla naszego połączenia. Składnia wygląda następująco:

IN/OUTx00 = START,N

Gdzie:

  • x – rodzaj wymienianych danych (np. B – bajt, W – word, DW – double word),
  • 00 – adres w robocie do którego mają być przypisane dane,
  • START – to offset przypisywanych danych,
  • N – ilość danych do zmapowania.

Zgodnie z tym konfiguruję odpowiednio pole [DEVNET].

Uwaga: należy zwrócić szczególną uwagę, aby zmapowane przez nas IO nie pokrywały się z bitami systemowymi robota (można to sprawdzić w monitorze I/O, o którym jeszcze będzie mowa). W tym przypadku dla wejść tak się stało, przez co komunikacja nie działała poprawnie. W późniejszym etapie poprawiłam na znacznie większy adres 35 zarówno dla wejść, jak i wyjść.

Następnie przechodzę do pliku devnet.ini (C:KRCROBOTERINIT) gdzie ustawiam parametry transmisji. Jest to plik konfiguracyjny wcześniej odblokowanego drivera.

W polu [krc] ustawiam prędkość transmisji jak na switchu, a w polu [1] (oznaczającym, że opisuję pierwszego slave’a) adres MACID. Wartości te muszą być dokładnie takie same jak ustawione wcześniej na switchach. Adresu Kuki (0) nie trzeba dodatkowo konfigurować.

Reklama


Na koniec wszystkie zmiany zapisuję, dokonując rekonfiguracji.

I gotowe! Po załączeniu zasilania o poprawności połączenia informują zielone LEDy na module. Spróbujmy zatem wysterować wyjścia i sprawdzić wejścia.

W tym celu uruchamiam wcześniej wspomniany monitor zmiennych (zakładka MONITOR w ekranie głównym). Jako że wcześniej adresy danych dla wejść i wyjść ustawiłam na 35, to dla robota będą to adresy od 281 (ilość bajtów*8+1). Nadaję im nazwy obsługiwanych portów w module.

Wysterowuję 8 pierwszych wyjść – efekt jest widoczny na module.Następnie stan wysoki ustawiam na porty parzyste.Na koniec symuluję  stan wysoki na wejściach modułu. W tym przypadku również połączenie działa poprawnie.

Podsumowanie

W tekście przedstawiłam najważniejsze informacje dotyczące protokołu DeviceNet z którym niedawno miałam okazję pracować. Protokół, obok znacznie bardziej znanego w Europie CANopen, należy do najczęściej stosowanych sieci działających w oparciu o CAN. Do słabszych stron tej technologii należą: niewielka maksymalna długość połączenia oraz stosunkowo niska prędkość wymiany danych. Z drugiej strony niewątpliwie zaletami są prostota wdrażania, możliwość dołączania urządzeń do sieci w trybie plug-and-play oraz oszczędność (miejsca i pieniędzy) dzięki specyfice medium transmisyjnego. Te cechy oraz niezawodność komunikacji powodują, że wciąż jest to jedna z najczęściej spotykanych sieci przemysłowych w Ameryce Północnej.

Źródła

Grafiki wykorzystane w pracy pochodzą ze strony https://realpars.com/devicenet/, materiałów ODVA i producentów sprzętu (fragmenty instrukcji). Przygotowując artykuł korzystałam także z:

Artykuł został nagrodzony w Konkursie iAutomatyka – edycja Maj 2019

Nagrodę Kurs online programowania sterownika easyE4 + torba na laptop + kubek dostarcza ambasador konkursu, firma iAutomatyka.pl.

 

Newsletter

Zapisz się i jako pierwszy otrzymuj nowości!

Zapoznałem się i akceptuję klauzulę informacyjną.
29 maja 2019 / Kategoria: , ,

Reklama

NAJNOWSZE PUBLIKACJE OD UŻYTKOWNIKÓW I FIRM

>KLIKNIJ<

Aktualizacja Therm od Rittal – obliczanie parametrów doboru klimatyzacji

Aktualizacja Therm od Rittal – obliczanie parametrów doboru klimatyzacji

>KLIKNIJ<

Poznaj funkcje SEE Electrical, które przyspieszają rysowanie schematów elektrycznych

Poznaj funkcje SEE Electrical, które przyspieszają rysowanie schematów elektrycznych

>KLIKNIJ<

Implementacja wymiany danych przy pomocy JSON API na przykładzie przekaźnika easyE4

Implementacja wymiany danych przy pomocy JSON API na przykładzie przekaźnika easyE4

>KLIKNIJ<

Publikuj artykuły razem z iAutomatyka.pl – Integrujemy Ludzi z Automatyką!

Publikuj artykuły razem z iAutomatyka.pl – Integrujemy Ludzi z Automatyką!

>KLIKNIJ<

Firma RENEX odznaczona tytułem Gazeli Biznesu

Firma RENEX odznaczona tytułem Gazeli Biznesu

>KLIKNIJ<

Kompaktowy sterownik z oprogramowaniem TwinCAT 3: większa skalowalność, większe możliwości!

Kompaktowy sterownik z oprogramowaniem TwinCAT 3: większa skalowalność, większe możliwości!

>KLIKNIJ<

Świat według automatyka – wywiad ze sterownikiem easyE4

Świat według automatyka – wywiad ze sterownikiem easyE4

>KLIKNIJ<

Akademia PLC #1 – Sterowniki Unitronics serii UniStream

Akademia PLC #1 – Sterowniki Unitronics serii UniStream

>KLIKNIJ<

5 porad, jak odnieść sukces w branży automatyki przemysłowej na przykładzie firmy MPL Techma

5 porad, jak odnieść sukces w branży automatyki przemysłowej na przykładzie firmy MPL Techma

>KLIKNIJ<

Szkolenia z 75% rabatem od Mitsubishi Electric

Szkolenia z 75% rabatem od Mitsubishi Electric

>KLIKNIJ<

Czym są przekaźniki instalacyjne i jak ich używać?

Czym są przekaźniki instalacyjne i jak ich używać?

>KLIKNIJ<

Cyberbezpieczeństwo i Chmura – bezpłatne seminaria z ELMARK w 6 miastach

Cyberbezpieczeństwo i Chmura – bezpłatne seminaria z ELMARK w 6 miastach

>KLIKNIJ<

Sensory i czujniki w maszynach i obiektach automatyki – wywiad z Pepperl+Fuchs

Sensory i czujniki w maszynach i obiektach automatyki – wywiad z Pepperl+Fuchs

>KLIKNIJ<

Maszyna do napełniania i zamykania z LinMot

Maszyna do napełniania i zamykania z LinMot

>KLIKNIJ<

Meble przemysłowe ESD – przegląd cech dostawcy i produktu

Meble przemysłowe ESD – przegląd cech dostawcy i produktu

>KLIKNIJ<

Pierwsze w pełni zintegrowane rozwiązanie Machine-Centric Robotics – B&R i ABB

Pierwsze w pełni zintegrowane rozwiązanie Machine-Centric Robotics – B&R i ABB

>KLIKNIJ<

Programowanie PLC od podstaw – kurs dla automatyków i elektryków odc.1 – Wprowadzenie

Programowanie PLC od podstaw – kurs dla automatyków i elektryków odc.1 – Wprowadzenie

>KLIKNIJ<

KONKURS IAUTOMATYKA STYCZEŃ 2020

KONKURS IAUTOMATYKA STYCZEŃ 2020

>KLIKNIJ<

Przekaźnik elektromagnetyczny – co to jest i jak działa?

Przekaźnik elektromagnetyczny – co to jest i jak działa?

>KLIKNIJ<

Walka człowieka z robotem lutowniczym REECO na Polskiej Wystawie Gospodarczej

Walka człowieka z robotem lutowniczym REECO na Polskiej Wystawie Gospodarczej





MOŻESZ SIĘ TYM ZAINTERESOWAĆ

  • Przeznaczony do pracy na wolnym powietrzu EMC / ekranowany Zakres zastosowania Budowa instalacji przemysłowychBudowa maszynTechnika grzewcza i klimatyzacyjnaElektrownie Dla przemiennika częstotliwości zasilającego 3 – fazowe silniki A...
  • Zaprojektowane, aby zwiększyć wydajność Sterowniki FX5U/FX5UC zapewniają rodzinie FX wyższą wydajność oraz dodają nowe cechy, które wyznaczają standardy w klasie kompaktowych sterowników PLC. Pozwala to użytkownikom na tworzenie bardziej zł...
  • EW1xxBD to panele webowe serii Esaware firmy ESA z wbudowaną przeglądarką internetową obsługującą technologię HTML5. Dostępne w dwóch wersjach – z systemem operacyjnym Android lub Linux (dzięki obsłudze CODESYS Web Visu, urządzenia wyświetl...
  •   RPC-2A-UNI  przekaźnik czasowy – Działający po zaniku napięcia zasiania, przy załączonym przekaźniku wykonawczym.     Przekaźnik przeznaczony do stosowania w instalacjach niskiego napięcia w automatyce przemysłowej, w automatyce bud...
  • Szybki i bezpieczny dostęp do maszyn i fabryk Usługa u-link gwarantuje szybki i bezpieczny dostęp do maszyn i fabryk, co ułatwia zdalne utrzymanie ruchu, jednocześnie pozwalając na wydajne zarządzanie zakładami produkcyjnymi i stacjami klie...
  • Pomiar odległości to jedna z podstawowych dziedzin w technologii czujników. Do określania położenia w różnorodnych zastosowaniach wykorzystywana jest szeroka gama procesów. Firma Pepperl+Fuchs już teraz – w odróżnieniu od konkurencji ...