Aktualności arrow Profinews
21.04.2018.
 
Profinews
Profinews137
Organizacja PI rozpoczyna certyfikację enkoderów.

W celu upewnienia się, że w technologii napędów wszystko działa płynnie, wymagane są jasne wymagania na interfejsy między wszystkimi komponentami sieci. Ugruntowany proces certyfikacji organizacji PI PROFIBUS i PROFINET International) zapewnia to, że wszyscy użytkownicy na całym świecie mogą polegać na jednolitych interfejsach komunikacyjnych i aplikacyjnych. W celu dalszego zapewnienia spójności aplikacji napędów i motion control od teraz będzie możliwa certyfikacja produktów procujących zgodnej z profilem enkoderów.

Profil enkodera należy do klasy profilów aplikacji i razem z profilem PROFIdrive definiuje spójne interfejsy aplikacyjne dla różnych zastosowań technologii napędów i motion control opartych o PROFINET i PROFIBUS.

Aby zapewnić pełne zautomatyzowanie testów, wliczając w to automatyzację oceny, do certyfikacji enkoderów wykorzystany zostanie sprawdzony tester profilu PROFIdrive. Został w tym celu przygotowany specjalny skrypt zgodny z ostatnią wersją testera profili. Skrypt kontroluje sekwencją wykonywanego testu oraz samą oceną zgodności zachowania badanego urządzenia z profilem. Takie rozwiązanie wpływa na zwiększenie jakości, pozwalając jednocześnie na zmniejszenie kosztów związanych z testowaniem i certyfikacją urządzeń.

Podobnie jak w przypadku PROFINET, tester profilu PROFIdrive ze skryptem przygotowanym dla profilu enkoderów jest dostępny dla członków organizacji PI za darmo. Można go ściągnąć ze strony organizacji. Producenci enkoderów mają możliwość korzystania z systemu testowego jeszcze na etapie badań, tak więc certyfikacji może zostać poddane urządzenie już wstępnie przetestowane. Testy certyfikacyjne po stronie PI będą wykonywane przez specjalistów w laboratoriach testowych PROFIdrive.

Więcej informacji na temat PROFIBUS i PROFINET znajdziecie Państwo w najnowszym numerze Profinews137.
 
Profinews136
Czy wiecie, że IO-Link jest wstecznie kompatybilny z czujnikami binarnymi?

Interfejs IO-Link jest znormalizowany w normie międzynarodowej IEC 61131-9. Jednym z pierwszych celów inicjatywy standaryzacji podjętej przez wiele współpracujących ze sobą firm było stworzenie interfejsu, który bierze pod uwagę istniejące architektury oraz typowe rodzaje połączeń na niższych poziomach sieci. Połączenie typu point-to-point było po prostu przejęte przez IO-Link razem ze sposobem standardowego okablowania.

Co więcej, poza trybem komunikacji (COM), norma definiuje także standardowy tryb I/O (SIO). W trybie pracy SIO master IO-Link może dodatkowo obsługiwać funkcje cyfrowych wejść i wyjść zgodnie z normą IEC 61131-2 typu 1. Binarne czujniki IO-Link przełączają sygnały na wyjściach cyfrowych zgodnie z IEC 60947-5-2 po włączeniu przy użyciu połączenia C/Q obsługiwanego przez komunikację IO-Link.

Korzyści są oczywiste: na niższych poziomach sieci możemy używać połączeń jeden do jednego, bez ograniczeń dla ilości połączeń IO-Link i sygnałów binarnych. Ponadto możemy osiągnąć lepszy stopień wykorzystania sterownika IO-Link ze względu na to, że urządzenia IO-Link oraz czujniki binarne mogą być podłączone do modułu sterownika w mieszanym trybie pracy. Z drugiej strony czujniki binarne IO-Link mogą pracować jako standardowe wejścia cyfrowe.

Czy w takim razie ma sens używanie czujnika IO-Link pracującego jako zwykły czujnik binarny? Tak, przykładowo IO-Link jest używany jako interfejs ze parametrami zdefiniowanymi przez normę. Dla każdego urządzenia IO-Link dostępne są uniwersalne narzędzia oraz opis urządzenia IODD. Dlatego możliwe jest wprowadzenie ustawień czujnika lub ich sklonowanie poza aktualną aplikację. W ten sposób urządzenie z predefiniowanymi parametrami może być zintegrowane w aplikacji innej niż IO-Link bez konieczności manualnego ustawiania parametrów.

W najnowszym numerze Profinews136 znajdziecie Państwo artykuły na temat PROFINET of Things i IIoT, informacje o nowych produktach, szkoleniach oraz aktualności ze świata PROFBUS i PROFINET.
 
Profinews135
PROFINET idealnie nadaje się do łączenia danych procesowych przechowywanych w systemach sterowania i urządzeniach polowych. Dla PI był to wystarczający powód by połączyć dwie wiodące na rynku technologie w jedno, zorientowane na przyszłość rozwiązanie, które pozwoli operatorom obiektów na dalsze korzystanie ze sprawdzonych technologii, a jednocześnie na dostęp do najnowszych technologii i Industry 4.0.

W celu osiągnięcia tego celu organizacja PI uruchomiła wielofazowy projekt wspierany przez grupę znanych użytkowników. Projekt ma za zadanie sięgnięcie przez PROFINET we wszystkich sektorach przemysłu procesowego aż do poziomu urządzeń polowych. Można powiedzieć, że z jednej strony cele projektu są średnioterminowe i polegają na zaadaptowaniu standardu do technologii używanych obecnie lub do tych, do których powstała już dokumentacja. Z drugiej zaś strony PROFINET jest już rzeczywistym rozwiązaniem w aplikacjach procesowych, które nie wymagają ochrony przeciwwybuchowej (takich jak woda, ścieki, czy sektor żywnościowy). W tym wypadku PROFINET jako magistrala systemowa nie tylko pełni funkcję szkieletu, ale także rozciąga się w dół do poziomu urządzeń polowych, gdzie udostępnia także funkcje takie jak diagnostyka, czy wykrywanie topologii sieci. Obecnie są już objęte normą, a więc można założyć, że wkrótce będą dostępne także na rynku produkty i rozwiązania, gdzie urządzenia PROFIBUS PA będą podłączone do PROFINET za pomocą inteligentnych linków (wykorzystujących technologie proxy) przy niewielkim wysiłku inżynierów. Obecnie trwają prace nad aktualizacją profilu dla urządzeń PA, który umożliwi bezpośrednie połączenie urządzeń polowych z siecią PROFINET, a także bezpośrednie mapowanie w obszarach innych niż niebezpieczne. Za wyjątkowo abitny cel postawiono sobie użycie rozwiązań ethernetowych w obszarach niebezpiecznych oraz w sieciach o dużych dystansach. W tym temacie prowadzone są już bardzo intensywne prace.

Industry 4.0 wymaga ethernetu przemysłowego jako podstawy, a PROFINET nadaje się do tego idealnie. Projekt zainicjowany przez PI połączy PROFIBUS PA i PROFINET w pierwszej fazie wykorzystując istniejące rozwiązania PA, a później za pomocą tworzonych stopniowo urządzeń PROFINET specjalnie pod rozwiązania PROFIBUS PA. W ten sposób PROFIBUS PA stanie się podstawą technologii procesowej zastosowanej w Industry 4.0.

Więcej na temat PROFINET i PROFIBUS znajdziecie Państwo w najnowszym numerze Profinews135.
 
Profinews134
Szanowni Państwo,

Alarmy zdefiniowane w normie PROFIBUS w wersji DPV1 możemy traktować jako szczególną część diagnostyki rozszerzonej. W porównaniu z diagnostyką rozszerzoną alarmy wymagają dodatkowej wymiany danych pomiędzy kontrolerem PLC lub DCS a urządzeniem typu Slave.

Aby można było skorzystać z funkcjonalności alarmów w sieci PROFIBUS, muszą zostać spełnione następujące warunki:
- Master musi obsługiwać alarmy
- Funkcjonalność alarmów musi być włączona
- Licznik alarmów nie może być przekroczony
- Slave musi obsługiwać alarmy
- Slave musi być w trybie wymiany danych ze stacją Master

Należy zaznaczyć, że urządzenia nie obsługujące tej funkcjonalności mogą normalnie pracować w sieci, w której część urządzeń używa alarmów.

Wiele urządzeń typu Slave obsługujących rewizję DPV1 pozwala na to, aby kontroler sieci mógł określić czy urządzenie będzie zwracać alarm wymagający potwierdzenia, czy też dane diagnostyczne bez potwierdzenia. Jest to zwykle ustawiane parametrem podczas konfiguracji urządzenia. Ten parametr jest zdefiniowany w pliku GSD urządzenia Slave i jest ustawiany za pomocą narzędzia konfiguracyjnego stacji Master.

Rodzaje alarmów określone przez PI International to alarmy diagnostyczne (Diagnostic), procesowe (Process), Pull, Plug, Status i Update. Dodatkowo oprócz alarmów standardowych, do dyspozycji producentów urządzeń pozostają wolne 94 kody alarmowe, które mogą zostać użyte do zdefiniowania własnych alarmów. Specyficzne alarmy producenta wraz z odpowiadającymi im kodami są zdefiniowane w pliku GSD oraz dokumentacji urządzenia.

Więcej na temat alarmów w PROFIBUS znajdziecie Państwo w najnowszym Profinews134.

Dodatkowo w numerze artykuły na temat IO-Link, IIoT, a także porównanie pętli 4-20mA z Profibusem.

Serdecznie zapraszamy do lektury Profinews134.
 
Profinews133
Czy wiesz, że IO-Link może przesyłać do 32 bajtów w jednym cyklu?

Interfejs IO-Link opisany normą IEC 61131-9 jest oparty na prostej szeregowej transmisji danych, która jest realizowana za pomocą konwencjonalnych przewodów. Takimi przewodami wymieniane są cykliczne pakiety danych pomiędzy sterownikiem IO-Link a urządzeniami. W języku IO-Link takie pakiety danych są nazywane jako "M-sequences". Informacja zawarta w pakietach danych jest definiowana dla IO-Link, ale w dużym stopniu może być skalowalna. Całość danych procesowych jest przesyłana cyklicznie, w każdym pakiecie danych w celu zagwarantowania określonego czasu odpowiedzi w aplikacji. Z drugiej strony parametry oraz informacje o zdarzeniach podlegają mniej rygorystycznym wymaganiom czasowym. Dlatego są one przekazywane podzielone na kilka pakietów danych.

Dla procesowych danych wejściowych (np. z czujników), lub danych wyjściowych (np. danych sterujących siłownika) wielkość danych może być zdefiniowana w każdym przypadku w zakresie od 1 do 32 bajtów (256 bitów). Ma to wpływ na ustalenie zoptymalizowanego czasu cyklu, przy założeniu stałej prędkości transmisji. Dotyczy on wszystkich urządzeń włączonych do sieci - niezależnie czy jest to czujnik indukcyjny dostarczający tylko 1-bitową informację, tablica świetlna przesyłająca stan każdego z ponad 200 obsługiwanych kanałów, czy też złożonego czujnika generującego lub zbierającego pomiar ciśnienia, przesyłającego ponadto informacje statusowe i dane sterujące zaworu.

W IO-Link nawet przy maksymalnej wielkości przesyłanych danych procesowych, tzn. 32 bajtach, można zejść z czasem cyklu poniżej 3 milisekund, używając do tego 3-przewodowego nieekranowanego kabla.

Więcej informacji ze świata PROFIBUS i PROFINET najnowszym numerze PROFINEWS133.
 
Profinews132
Czy wiesz, że IO-Link chroni przed nieprawidłową wymianą urządzenia?

Sytuacje gdy czujnik musi zostać wymieniony wymagają przeważnie pośpiechu, ponieważ urządzenie musi zacząć pracować jak najszybciej. Często taką wymianę musi przeprowadzić personel nie mający specjalnego przeszkolenia. Z tego powodu IO-Link postanowił inaczej podejść do problemu. Opracowany jako interfejs zaprojektowany "przez praktyków dla praktyków" posiada wiele zintegrowanych opcji pozwalających zmaksymalizować łatwość i niezawodność wymiany urządzeń.

Czujniki stają się coraz bardziej podobne pod względem budowy. Czasami trudno jest odróżnić od siebie czujnik ciśnienia, temperatury i przepływu. Z drugiej strony Master IO-Link otrzymuje od każdego z urządzeń informację z dokładną identyfikacją. Zawiera ona przykładowo nazwę producenta oraz nazwę i ID produktu, które dokładnie opisują czujnik. Jeśli podczas wymiany zostanie zainstalowane urządzenie, które posiada inną konstrukcję, master IO-Link rozpoznaje taką sytuację i nie akceptuje nowego urządzenia. Dioda wskazująca na błąd pozostaje zapalona. Jeśli nowy czujnik ma tą samą konstrukcję, co stary, to zostaje on przez sterownik zaakceptowany bez konieczności przeprowadzania żadnych dodatkowych czynności. Urządzenie jest włączane w cykl wymiany danych. Maszyna natychmiastowo wznawia swoje działanie. Jeśli czujnik jest typu plug-in, może być w prosty sposób podmieniony przez przeszkolony personel. Nie jest w tym wypadku potrzebna żadna interwencja w program kontrolera.

Drugą możliwą sytuacją jest zastąpienie czujnika jego nowszą wersją, posiadającą nowe przydatne funkcjonalności. Na pierwszy rzut oka zatem takie urządzenia nie są do końca zgodne. parametry identyfikacyjne po stronie kontrolera, jak i czujnika także są różne. IO-Link ma przewidziane proste rozwiązanie dla tego typu przypadków. Począwszy od wersji 1.1, kontrolery IO-Link mają możliwość odpytania urządzenia, czy jest ono w stanie przejść w tryb zgodności ze swoją poprzednią wersją. Jeśli tak, to kontroler i czujnik automatycznie wznawiają pracę i system działa ponownie.

W najnowszym numerze PROFINEWS132 można znaleźć także ciekawe artykuły na temat profilu PROFIsafe, funkcjonalności Fail-safe w sieciach bezprzewodowych, czy konfiguracji DCP w PROFINET. Zapraszamy do lektury: PROFINEWS132.
 
Profinews131
Ostatnie pięć lat było ekscytujące dla automatyki procesowej. Dla wszystkich zaangażowanych było jasne, że przełom jest na wyciągnięcie ręki. I tym samym, wraz z rozwojem technologii FDI (Field Device Integration) wysłany został ważny sygnał. Po pierwsze, dlatego że technologia sprawi, że integracja urządzeń automatyki procesowej będzie znacząco łatwiejsza. Z drugiej strony dlatego, że współpraca z użytkownikami, organizacjami i producentami była wyjątkowa. Wszyscy uczestnicy ciągnęli projekt do przodu, wypatrując sukcesu.

Tym samym na targach ALCHEMA w połowie czerwca FDI Cooperation LCC było gotowe, by ogłosić koniec projektu - prace nad technologią FDI zakończyły się sukcesem. Do wykorzystywanych wcześniej elementów EDDL i FDT dodano coś nowego, co konsekwentnie upraszcza integrację urządzeń przy zachowaniu optimum neutralności względem producentów.

Specyfikacja, pierwsza wersja narzędzi deweloperskich oraz standardowe komponenty po stronie sterownika były dostępne od marca. Specyfikacja jest dostępna na stronie FDI Cooperation, a także FieldComm Group i PI International. IEC opublikowała specyfikację jako standard międzynarodowy IEC 62769. Od tej pory dostawcy rozwiązań dla automatyki przemysłowej mogą rozwijać produkty i systemy oparte o ten standard. Pierwsze komponenty sieci były pokazane na wystawie ALCHEMA. Teraz do producentów należy decyzja o wdrożeniu standardu do swoich produktów, a użytkownicy zadecydują o integracji nowej technologii do prowadzonych projektów.

Więcej na temat FDI, a także Profinetu DCP, IO-Link, czy Industrial Internet of Things można poczytać w najnowszym numerze PROFINEWS131.
 
Profinews130
W najnowszym numerze PROFINEWS John Swindall z PROFI Interface Center publikuje drugą część artykułu na temat diagnostyki sieci PROFIBUS.

Szeroki wachlarz możliwość diagnostycznych przyczynił się w znacznej części do sukcesu odniesionego przez standard PROFIBUS w świecie automatyki przemysłowej. Każde urządzenie PROFIBUS typu Slave musi obsługiwać minimum 6-bajtowe komunikaty diagnostyczne. dane te są zdefiniowane przez organizację PROFIBUS i PROFINET International i raportują stan urządzenia, jego stacji nadrzędnej oraz informują o dostępności opcjonalnych danych diagnostycznych.
W artykule opisane są trzy formaty kodowania rozszerzonej informacji diagnostycznej (Device Related Diagnostic, Identifier Related Diagnostic i Channel Related Diagnostic) - struktura ramki danych i znaczenie poszczególnych bitów.

Zainteresowanych zapraszamy do przeczytania całości artykułu. W najnowszym numerze PROFINEWS130 znajdą Państwo także informacje na temat Industrial Internet of Things, targach Alchema 2015, nowych produktach czy aktualnych szkoleniach.
 
Profinews129
Jedną z wielu przyczyn sukcesu PROFIBUS przez lata była rozbudowana diagnostyka umożliwiająca wykrywanie problemów w czasie pracy systemu. Celem tego artykułu jest przedstawienie działania diagnostyki sieci PROFIBUS i pokazanie w jaki sposób informacje są raportowane.

Wszystkie urządzenia PROFIBUS typu Slave obsługują podstawowy komunikat diagnostyczny. Jest on wysyłany na każde żądanie stacji typu Master i za jego pomocą urządzenie informuje o tym, czy wymaga parametryzacji lub konfiguracji, a także o wystąpieniu ewentualnych błędów w przesłanych parametrach, aktualnym trybie pracy, stanie watchdoga, itp. Te wszystkie informacje mogą przyczynić się do rozwiązania problemów z konfiguracją urządzenia, ale w punktu widzenia pracującego systemu nie są już już takie pomocne. Komunikaty diagostyczne, które mogą wystąpić w trakcie pracy są o wiele bardziej interesujące.

Stan w którym urządzenie Master kontroluje sieć jest nazwany trybem operacyjnym (Operate mode) lub trybem wymiany danych (Data Exchange mode). W trybie operacyjnym PLC/DCS wysyła ramkę z danymi wyjściowymi i odbiera dane wejściowe z każdego urządzenia Slave, które kontroluje. Master wymienia dane z każdym urządzeniem typu Slave, przeprowadza krótką diagnostykę systemu i zaczyna od początku.

Kiedy urządzenie wykryje zmiany, które należy zgłosić do PLC/DCS, ustawia odpowiedni bit w bajcie statusu, przesyłanym do urządzenia Master z danymi wejściowymi. Master pobiera otrzymane dane i kontynuuje wymianę danych z pozostałymi urządzeniami w sieci. W następnym cyklu odpytywania o dane I/O stacja Master zamiast danych wyjściowych wysyła do takiego urządzenie telegram "Get Diagnostic", a urządzenie odpowiada ramką diagnostyczną zamiast danymi wejściowymi. Kiedy Master czyta informacje diagnostyczne, Slave kasuje wystawiony wcześniej bit, informując że nowa diagnostyka została przesłana do sterownika. Master kontynuuje wymianę danych z innymi urządzeniami, a w następnym cyklu wymienia dane z naszym urządzeniem, tak jak to miało miejsce w poprzednich cyklach.

Master czyta dane diagnostyczne tylko raz, a później wymienia z danym urządzeniem dane w zwykły sposób. Kiedy sytuacja diagnostyczna urządzenia zmieni się znowu, Slave ustawia bit diagnostyczny po raz kolejny. Ten sposób obsługi zapewnia minimalny wpływ postępowania diagnostycznego na czas aktualizacji I/O w systemie PROFIBUS.

Więcej na temat diagnostyki można przeczytać w najnowszym numerze PROFINEWS129.
 
«« start « poprz. 1 2 3 4 5 6 7 8 nast. » koniec »»

Pozycje :: 27 - 39 z 102