Komunikacja zdarzeniowa to doskonałe rozwiązanie, gdy nie chcemy aby wymieniane dane w protokole Modbus były odczytywane non stop, a tylko w określonych sytuacjach np. wraz ze wzrostem poziomu cieczy w zbiorniku. Taka opcję będzie przydatna gdy stosujemy transmisję GSM i pragniemy zaoszczędzić ilość wysyłanych danych. Ten artykuł ma na celu przedstawić dwa rozwiązania z wykorzystaniem protokołów Modbus TCP oraz Modbus RTU.
Na czym to polega?
W standardowej komunikacji cyklicznej Modbus dane są przesyłane co określony interwał czasowy. WebHMI jest urządzeniem typu MASTER i według swoich zasad odpytuje np. sterownik PLC który jest urządzeniem typu SLAVE. Komunikacja zdarzeniowa różni się tym, że WebHMI jest urządzeniem typu SLAVE i oczekuje na dane które wyśle jej sterownik PLC jako MASTER. Taka konfiguracja jest możliwa dzięki funkcji Modbus TCP Server. Ta opcja pozwala na szereg innych możliwości dzięki jej zastosowaniu. Oprócz wspomnianej komunikacji zdarzeniowej, za jej pomocą WebHMI może pośredniczyć w wymianie danych urządzeń mających inne protokoły komunikacyjne. Przykładowo dzięki portowi RS-485 można odczytywać dane z urządzeń poprzez Modbus RTU, a następnie udostępniać je panelowi HMI poprzez Modbus TCP.
Modbus TCP
Opcja Serwer Modbus jest ustawiana w zakładce Ustawienia->Serwer Modbus
Po jej aktywowaniu pojawi się kolejna pozycja w menu Ustawienia -> Modbus TCP Serwer. Tam są deklarowane zmienne, które mają być udostępniane przez Modbus TCP oraz definiowane ich adresy Modbus.
Pokazane powyżej rejestry to dane, które WebHMI odczytuje z urządzenia jako MASTER. Mimo że chcemy uzyskać komunikację zdarzeniową, warto aby WebHMI również odpytywało urządzenie ale z dużą częstotliwością np. co 15min. Będzie to służyło jako diagnostyka na wypadek braku komunikacji urządzeń. W przypadku nie zastosowania takiego rozwiązania mogłaby się zdarzyć sytuacja, gdzie dane nie byłyby otrzymywane przez dłuższy okres czasu. Przyczyną mogłoby być brak zmiany stanu zmiennej aktywującej zdarzenie ale również brak komunikacji z urządzeniem.
Zdarzenia są wywoływane w sterowniku PLC, gdzie jest zapisany cały algorytm wysyłania ramek za pomocą Clienta Modbus TCP. Dlatego zanim zdecydujecie się na takie rozwiązanie należy się upewnić czy sterownik posiada taką funkcjonalność w protokole Modbus TCP.
Modbus RTU
Przy protokole Modbus RTU zasada działania wygląda inaczej. WebHMI nie posiada funkcji SLAVE, a ciągle występuje w roli MASTERA. Więc aby wykonać komunikację zdarzeniową należy wykorzystać wewnętrzne rejestry zezwalające na połączenie „CDx”. Idea rozwiązania jest następująca. Do komunikacji z PLC zostaną utworzone dwa połączenia. Jedno połączenie będzie cyklicznie odpytywało rejestr, który jeśli tylko zmieni swój stan, to zostanie aktywowane drugie połączenie gdzie są docelowe dane do odczytu.
Aktywowanie połączenia będzie wywołane poprzez rejestr CDx (gdzie x to numer ID połączenia). Aktualne dane będą kopiowane do wewnętrznych rejestrów WebHMI.
Algorytm wykrywający zmianę stanu rejestru powodujący odczyt danych docelowych jest zapisany w skrypcie.
Oczywiście te rozwiązanie w komunikacji Modbus RTU nie redukuje takiej ilości przesyłanych danych jak w przypadku Modbus TCP. Jeden rejestr jest odpytywany cyklicznie, więc ciągle mamy komunikacje z urządzeniem SLAVE. Mimo wszystko to znacznie odciąży procesor komunikacyjny gdy mamy do odczytu setki jak nie tysiące rejestrów.
Gdzie mogę kupić to urządzenie?
ZestaPRO jest importerem WebHMI w Polsce. Wyślij szybkie zapytanie ofertowe lub uzupełnij formularz aby uzyskać ofertę na urządzenie. Masz pytania o kwestie techniczne? Napisz na support@zestapro.pl.
