Do Projektu iAutomatyka dołączyli:

https://iautomatyka.pl/wp-content/uploads/2019/05/degvicenet-wyroznione.jpg

Czym jest DeviceNet? Przykład konfiguracji robota Kuka

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.

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.


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.


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ć.


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.

 



Utworzono: / Kategoria: , ,

Reklama

Newsletter

Zapisz się i jako pierwszy otrzymuj nowości!



PRZECZYTAJ RÓWNIEŻ



NAJNOWSZE PUBLIKACJE OD UŻYTKOWNIKÓW I FIRM

Reklama



POLECANE FIRMY I PRODUKTY
  • Ekonomiczne monitorowanie i sterowanie, teraz także dzięki panelom 2 generacji. Dzięki odpowiedniemu doborowi funkcji HMI, panele Basic 2 generacji stanowią doskonałe rozwiązanie przy produkcji maszyn lub w małych aplikacjach przemysłowych....
  • Seria EX-Z Czujniki z serii EX-Z to jedne z najmniejszych urządzeń tego typu na świecie. Najcieńszy model posiada grubość jedynie 3 mm co zostało osiągnięte przez zastosowanie nowych półprzewodników i dzięki temu wyeliminowanie przewodów. B...
  • Urządzenia XV300 wyposażone są w przemysłowe wyświetlacze wysokiej rozdzielczości z technologią wielodotyku. To, w połączeniu z precyzyjnym i intuicyjnym interfejsem użytkownika, umożliwia operatorom pracę od zaraz. Dodatkowo te wysoko wyda...
  • Urządzenia firmy FATEK istnieją na rynku polskim od 2004 roku i stały się alternatywą dla już istniejących rozwiązań i urządzeń. Niezawodność, korzystna cena i możliwości sterowników PLC sprawiły, że zyskały one ogromne zainteresowanie prog...
  • Rozwiązania wizyjne nadają się idealnie do zautomatyzowanych zadań kontrolnych i pomiarowych. Kamery wizyjne 2D i 3D firmy SICK sprawdzają się w ogromnej ilości aplikacji, polegających na pomiarze, lokalizacji, kontroli i identyfikacji. Nas...
  • Systemy RFID są ekonomiczne, uniwersalne i zapewniają niezawodność procesów, np. w intralogistyce. Zadania związane z identyfikacją stały się teraz łatwiejsze, szczególnie gdy potrzebna jest duża liczba punktów identyfikacji, dzięki  głowic...