FSoE – integracja i wykorzystanie z AS-Interface – artykuł gościnny
|
|
Wstęp
Z trapezopodobnym żółtym przewodem, na którym zostało „powieszone” mnóstwo pudełek z wtyczkami czujnikowymi zetknąłem się ponad dekadę temu, jako żółtodziób działu utrzymania ruchu jednej z dużych firm branży drzewnej. Po zgłębieniu systemu o nazwie „Actuator Sensor Interface” przypadł mi on do gustu tak mocno, że z sukcesem wdrożyłem go w jednym ze swoich projektów, a nie rzadko miałem okazję pojawiać się przy okazji mniejszych lub większych awarii tego systemu magistrali I/O.
Pomysł na sklecenie kilku poniższych zdań pojawił się przypadkowo, gdy szukając rozwiązania problemu postawionego przez jednego z potencjalnych klientów napatoczyła mi się bramka tłumacząca wyżej wymienione AS-i na protokół EtherCAT, ale z ramką FSoE włącznie. O ile sam Beckhoff posiada w swoim portfolio moduł tłumaczący AS-i na E-Cat i z powrotem, o tyle integracja bezpośrednio w ekosystemie Beckhoffa „Safety at Work” wydawała mi się niemożliwa, a tu proszę. Przy okazji napomnianego już projektu konieczne okazało się zaczerpnięcie wiedzy u kogoś bardziej doświadczonego i tak padła idea wypożyczenia zestawu do zintegrowania obu tych światów.
Zarówno EtherCat jak i AS-i liczą już ponad dwie dekady i dzięki obu stowarzyszeniom, trzymającym pieczę nad ich standaryzacją i certyfikacją, są protokołami na tyle dojrzałymi, że w zasadzie nie ma się nad czym rozpisywać. Jeżeli jednak ktoś czuje konieczność rozszerzenia/uzupełnienia wiedzy to odsyłam do stron jednostek sprawujących opiekę nad danym protokołem, gdyż nie to jest celem tego artykułu.
Po uzgodnieniu szczegółów z firmą Bihl+Wiedemann otrzymałem paczkę, która zawierała bramkę AS-i/EtherCAT, E-Stop, klawiaturę z dwoma podświetlanymi przyciskami, aktywny dystrybutor z podłączoną blokadą firmy Schmersal, moduł dwóch bezpotencjałowych wejść bezpiecznych oraz tymczasową licencję oprogramowania ASIMON360. Oprogramowanie jest niestety niezbędne żeby przygotować bramkę komunikacyjną do pracy z telegramami FSoE niezbędnymi w systemie TwinSAFE.
Od strony Beckhoffa całość „napędza” budżetowy panel CP6606 pracujący pod kontrolą Windows CE ze zintegrowanym sterownikiem PLC. Logika systemu bezpieczeństwa została oparta o procesor EL2911 który dodatkowo agreguje cztery wejścia bezpieczne oraz jedno bezpieczne wyjście z obciążalnością 10A max!
Rys.1. Widok testowanego zestawu
Z prowadzonych przez siebie projektów została mi jeszcze widoczna na zdjęciu kaseta sterownicza firmy Schmersal którą postanowiłem również podłączyć do układu, aby pokazać że AS-i jest przestrzenią, gdzie może się spotkać wielu producentów, których ciężko byłoby posądzić o kompatybilność w pierwszym odruchu. Po zaadresowaniu urządzeń pozostało włączyć zasilanie i zmusić bramkę AS-i do tego, aby przestała mnie bombardować komunikatami błędów od strony AS-i. Służy do tego wymienione wyżej oprogramowanie, któremu, moim zdaniem, należy się także kilka zdań. Miałem okazję pracować na poprzedniej wersji wyżej wymienionego pakietu oprogramowania, a także uruchamiać systemy komunikacji AS-i przy pomocy oprogramowania innych producentów i dla mnie obecny „ASIMON” jest numerem jeden. Na to wrażenie składają się przede wszystkim narzędzia konfiguracyjne, które dostaje do wirtualnej ręki osoba uruchamiająca system. Są to kreatory, które nie tylko prowadzą za rękę przez proces uruchomienia systemu, ale także swoim „okiem” zaglądają przez ramie nienachalnie przypominając w stosownym momencie, że o czymś zapomnieliśmy i warto byłoby taką rzecz zrobić
Rys.2. Menadżer urządzeń w ASIMON360
Doceni to z pewnością ten kto uruchamiał technologię bezpieczeństwa, gdzie trzeba mieć świadomość kilku zależności, w przeciwnym razie skończy się to brakiem reakcji na urządzenia bezpieczeństwa, nie generując przy tym żadnych błędów systemu – cóż taki urok. Prace związane z uruchomieniem sieci AS-i zamyka aktywowanie przygotowanej konfiguracji na bramce Mastera systemu AS-i i tutaj także można skorzystać z pomocy stosownego kreatora, który nie tylko sprawdzi istotne rzeczy w przygotowanej konfiguracji, ale przede wszystkim „scali” komunikację bezpieczną, podróżującą między obiema sieciami, dodając za nas odpowiednie połączenia wirtualnych urządzeń.
Rys.3. Połączenia pomiędzy AS-i EtherCAT – automatycznie stworzone zależności
ASIMON360
Jak wiadomo każdemu praktykowi któremu przypadło integrowanie różnych producentów, katalog aparatów dostarczanego oprogramowania kończy się na jego własnych produktach, potem zostaje „wyklikanie” interesującego nas urządzenia, bazując na jakimś typie ogólnym – tutaj niestety też nie chce być inaczej. Jeśli czegoś nie ma w menadżerze sprzętowym musimy dodać urządzenie uniwersalne (co jest możliwe z uwagi na samą konstrukcję modułów AS-i). ASIMON360 jednakże charakteryzuje się dwoma wyjątkami. Z jednej strony daje nam możliwość dodawania do katalogu elementów które użytkownik sparametryzował własnoręcznie, bazując na dokumentacji uruchamianego urządzenia i co najważniejsze tak zdefiniowany aparat jest dostępny z poziomu środowiska, a nie tylko wewnątrz projektu w którym został stworzony – dla mnie rewelacja! Ponadto sam menadżer sprzętowy zawiera pokaźną, cały czas rozwijaną, bazę urządzeń innych producentów, co znacznie ułatwia konfigurację sieci.
Rys.4. Dodawanie urządzeń AS-i w Menadżerze Urządzeń ASIMON360
Bardzo fajną funkcjonalnością ASIMON360 jest możliwość przeprowadzenia testów IO bez konieczności posiadania sterownika PLC, gdzie korzystając z zakładek diagnostycznych danego uczestnika sieci AS-i jesteśmy w stanie podejrzeć status wejść, wymusić stan wyjść a także obserwować jak przebiega komunikacja na magistrali AS-i:
Rys.5. Podgląd danych i parametrów urządzenia
Rys.6. Poziom jakości transmisji z urządzeniem
Ostatnią rzeczą która pozostaje jest zatwierdzenie wgranej komunikacji i w zasadzie jest to koniec prac po stronie magistrali AS-i, teraz zostaje skomunikowanie się sterownikiem PLC z bramką AS-i.
TwinCAT
Po dodaniu pliku opisu i skonfigurowaniu topologii magistrali EtherCAT pozostaje skonfigurowanie projektu TWINsafe i odwoływanie się do obszarów przestrzeni adresowej, gdzie podczas konfiguracji konwertera AS-i/EtherCAT umieszczono interesujące nas urządzenia. Niestety, ale cała przestrzeń adresowa jest importowana z dołączanego pliku ESI i na barkach programisty systemu spoczywa odwołanie się do właściwych urządzeń, bo na wyrafinowane nazewnictwo nie ma co tutaj niestety liczyć.
Rys.7. Przestrzeń adresów bezpiecznych AS-i w TwinSAFE
Tak dodane urządzenia pozostaje połączyć w programie safety korzystając z nich jak z każdego innego wejścia/wyjścia przeznaczonego do pracy w tych systemach. Dodatkowo warto pamiętać, że w „pakiecie” z bramką dostajemy sześć kanałów wejść standardowych, mogących pracować z sygnałami testowymi które można skonfigurować do pracy w trybie 3×2 wejścia bezpieczne, a także sześć kanałów cyfrowych wyjść bezpiecznych, które pomimo tego, że nie są podpięte do magistrali AS-i są do dyspozycji w oprogramowaniu sterownika bezpieczeństwa.
Idzie nowe!
Pierwsza implementacja protokołu AS-i została wprowadzona na rynek na przełomie lat 80/90 minionego wieku, jako rozwiązanie upraszczające zbieranie informacji z czujników i sterowanie prostymi aktorami systemów automatyki. Koncepcja ta z resztą znajdowała odzwierciedlenie w „upychaniu” czipów AS-i do chociażby pojedynczych czujników indukcyjnych! Jakby nie patrzyć od momentu wprowadzenia protokołu na rynek ilość czujników instalowanych w maszynach „nieco” wzrosła, nie mówiąc już o tym, że objętość danych przesyłanych między czujnikami a systemami sterowania również wzrosła lawinowo co sprawiło, że AS-i, ze swoimi czterema bitami na obszar wejść/wyjść przypisanymi poszczególnym uczestnikom, zaczęło zwyczajnie trącić myszką. Gdy dołożymy do tego na stałe zadeklarowane kierunki portów to sumarycznie cały system w ogóle traci na atrakcyjności. Na szczęście ktoś w konsorcjum trzymał rękę na pulsie i tak w 2018 roku dostaliśmy implementację protokołu oznaczoną „AS-i5”. Wraz z nowym protokołem dostaliśmy możliwość nie tylko zwiększenia ilości przesyłanych danych, ale także prędkości ich transferu i to wszystko przy pomocy niezmienionego okablowania oraz zasilaczy dedykowanych do systemu AS-i! A więc skoro bramka wspiera najnowszy standard to czemu nie skorzystać z okazji i nie zobaczyć? Moduły cyfrowych wejść/wyjść, pomimo zmian na lepsze, – nic specjalnego. Zobaczmy natomiast jak się spisze mieszanina dużego wolumenu, latających po nieskomplikowanym kablu bitów z ramkami systemu bezpieczeństwa, który jeńców w zakresie komunikacji nie bierze, a więc IO-link. Firma Bihl+Wiedemann znowu wykazała się życzliwością i udostępniła moduł BW4067 (Slave ASi-5 będący Masterem IO-Link), który ma zabudowane dwa porty M12 w klasie A oraz dwa w klasie B, co umożliwiło bezpośrednie podłączenie wyspy zaworowej przy pomocy kabla czujnikowego z pięcioma żyłami. Poinformowanie IO-link mastera o tym z kim będzie na danym porcie „rozmawiał” sprowadziło się do wgrania odpowiedniego pliku IODD i aktywowania konfiguracji bramki AS-i. Tylko tyle i aż tyle, zaworki ładnie klikają E- Stopy działają – nic dodać nic ująć. Dla mnie największym atutem jest to, że oba protokoły mogą koegzystować na jednym kablu, przy czym należy pamiętać o ograniczeniu długości magistrali AS-i5 do 200m włącznie i braku możliwości używania wzmacniaczy znanych z standardu AS-i 3 (wzmacniacze można dalej stosować, ale, z uwagi na separację galwaniczną, za nimi nie można już instalować modułów AS-i5 coś za coś.
Rys.8. Konfiguracja urządzenia IO-link.
Podsumowanie
Jako praktyk wielokrotnie spotykałem się z nowymi instalacjami, gdzie obsługa pomstowała na niestabilnie działający system generujący ogrom problemów, czemu w zasadzie nie było co się dziwić, skoro instalacja była emanacją rozdziału poradnika instalatora pod tytułem „tego robić nie należy”. Na drugim biegunie zaś były instalacje o których dowiadywano się, że tam pracują dopiero w momencie gdy przestawały działać i nie bardzo było wiadomo „co to za żółty kabel jest”. Samemu udało mi się wdrożyć system na którym uruchomiono trzy sieci AS-i i pomimo upływu lat nie ma z nimi żadnych problemów natury eksploatacyjnej, bo jeżeli to dobrze wykonamy będzie po prostu działać. Zachęcającym do używania jest także fakt, że oprócz modułów IO mamy dostęp również do całego ogromu modułów specjalizowanych jak chociażby zawory pneumatyczne czy wieże sygnalizacyjne. Wraz z pojawieniem się wersji piątej magistrali warto zwrócić uwagę na nowe możliwości w zakresie koncentracji sygnałów – gdzie dla pojedynczego adresu możemy uzyskać 16 kanałów w pełni konfigurowalnych w zakresie kierunku lub, skorzystać z modułów samo-konfigurowalnych (więcej o nich można się dowiedzieć TUTAJ). Całość konfiguracji przechowywana jest w bramce, co upraszcza ewentualne czynności serwisowe do minimum – szczególnie w zakresie bardziej skomplikowanych urządzeń, jak chociażby wspomniane moduły IO-Link.
Jakie minusy znalazłem podczas okresu testowania prezentowanego zestawu? Największy to zadeklarowanie danych w obszarze wejść/wyjść bramki komunikacyjnej w formie ciągłej, gdzie jesteśmy zmuszeni, z poziomu sterownika PLC, wyłuskiwać interesujące nas bity nie mając dostępu „na wprost”, dającego nam możliwość podpięcia ich pojedynczo z jasno opisującym przeznaczeniem. Przekłada się to znacząco na czytelność w przypadku serwisu itp. Miejmy nadzieję, że producent pokusi się o wprowadzenie zmian w tym zakresie, modyfikując plik urządzenia i dając nam większą elastyczność.
Drugim czego mi brakuje, zwłaszcza w przypadku użycia systemów sterowania opartych o systemy operacyjne czasu rzeczywistego, to brak wparcia technologii „Ethernet Over Ethercat”. Uprościłoby to znacznie okablowanie strukturalne w przypadku bramek komunikacyjnych zainstalowanych poza szafą sterowniczą z komputerem głównym, który może przejąć rolę lokalnego narzędzia serwisowego, lub korzystając z mechanizmów tunelowania wbudowanych w systemy Windows umożliwić zdalny dostęp inżynierowi diagnozującemu system I/O. Nie jest to bez znaczenia, uwzględniając zwłaszcza, że port serwisowy bramki nie posiada wbudowanego przełącznika sieciowego. Kolejną rzeczą jest konieczność fizycznego odłączania magistrali komunikacyjnej w przypadku określonych czynności wykonywanych z bramką, co mając na względzie szeregowy charakter magistrali EtherCAT spowoduje przerwanie komunikacji z węzłami sieciowymi umieszczonymi za bramką komunikacyjną.
Konkludując należy pamiętać, że nie ma rzeczy uniwersalnych i stojąc przed doborem systemu wejść/wyjść dla automatyzowanego przez siebie procesu należy postawić sobie pytanie co i jak potrzebujemy zrobić. Rozważyć system kompleksowo, bo praktyka zawodowa pokazała mi nie raz, że zakup samego modułu wejść/wyjść to dopiero początek, a doposażenie go w wymagane złącza czy okablowanie nie rzadko zaczyna czynić wdrożenie systemu nieopłacalne ekonomicznie, ponieważ najzwyczajniej nie wykorzystamy pełnego potencjału oferowanego przez wybraną technologię. W aspekcie kosztów należy także mieć na uwadze budżet, który pochłonie instalacja wybranego przez siebie rozwiązania, co akurat w przypadku AS-i nie wymaga wysoko wykwalifikowanej kadry inżynierskiej – w dzisiejszych czasach na plus.
Dane kontaktowe autora artykułu:
fi automation
Krystian Czyżewski
Email: krystian.czyzewski@fiautomation.pl
Telefon: +48 696 025 192