Zaawansowane funkcje komunikacyjne

W tym artykule opisano wykorzystanie różnych funkcji WebHMI do realizacji zaawansowanych funkcji komunikacyjnych.

Odczytywanie liczby 64-bitowej

WebHMI operuje maksymalnie na 32-bitowych zmiennych. Zdarza się, że sterowniki PLC lub inne urządzenia wykorzystują 64-bitowe zmienne typu Long Real, czy też zwane inaczej liczby zmiennoprzecinkowe podwójnej precyzji. Można spojrzeć na to i stwierdzić, że po prostu się nie da odczytać takich zmiennych.  Jednak kilka sprytnych funkcji zapisanych w skryptach LUA pozwolą na odczytanie zmiennych Long Real. Poniżej prezentujemy przykład odczytu zmiennej LReal ze sterownika Siemens S7-1200. Podobny sposób można wykorzystać także przy innych protokołach komunikacyjnych.

Zmienna 32-bitowa vs zmienna 64-bitowa

Jakie są różnice między tymi dwoma typami ? Najważniejszą z nich jest liczba bitów. Liczba 64-bitowa zmiennoprzecinkowa (8 bajtów) posiada 1 bit znaku, 11 bitów wykładnika oraz 52 bity mantysy. Dzięki większej liczbie bitów zakres i dokładność podawanej zmiennej rzeczywistej zdecydowanie wzrasta.

Odczyt liczby zapisanej w taki sposób jest możliwe dzięki zależności:

Liczba 32-bitowa zmiennoprzecinkowa (4 bajty) posiada 1 bit znaku, 8 bitów wykładnika i 23 bity mantysy. Liczby 32-bitowe są częściej wykorzystywane, gdyż również pozwalają na całkiem dokładnie odwzorowywanie rzeczywistej wartości zmiennej, a operacje na nich są wykonywane szybciej.

Zależność odczytywania liczby 32 wygląda następująco:

Przykład obliczania liczny za pomocą powyższego wzoru:

Zrozumienie sposobu konwersji liczby binarnej na liczbę zmiennoprzecinkową będzie istotne do zrozumienia skryptów, które wystąpią w dalszej części wpisu.

Jak połączyć się ze sterownikiem S7-1200?

Cała instrukcja komunikacji WebHMI ze sterownikiem Siemens S7-1200 znajduje się tutaj. Została stworzona zmienna Liczba typu LReal (64-bitowa) w Data Block (DB1). To właśnie ją będziemy odczytywać za pomocą naszego WebHMI.

Zmienne w WebHMI

W naszym panelu WebHMI tworzymy 2 nowe połączenia wchodząc w zakładkę Ustawienia → Zmienne. Jedno połączenie ze sterownikiem Siemens, gdzie model urządzenia ustawiamy na Siemens Siematic S7, zmieniamy protokół na S7 Comm (TCP) oraz wprowadzamy adres IP urządzenia. Drugim dodanym połączeniem jest połączenie zmiennych wewnętrznych WebHMI, w którym model urządzenia to Internal WebHMI Registers, a protokół WebHMI.

Aby odczytać zmienną 64-bitową o nazwie Liczba za pomocą WebHMI musimy odczytać 2 zmienne 32-bitowe. W połączeniu S7-1200 zostały stworzone 2 zmienne o nazwie DB1.DB0 oraz DB1.DB4. Do ułatwienia dalszej pracy w skryptach ustawiono ich aliasy na Liczba1 oraz Liczba2.

Dla tych zmiennych konieczne jest ustawienie w zakładce Wartość typu danych jako Double Word oraz zmiana formatu wartości na Ze znakiem, liczba całkowita Integer.

Trzecia i ostatnia zmienna, która jest nam potrzebna, będzie wyświetlać wynik całej operacji. Dodajemy w połączeniu WebHMI nową zmienną o nazwie wynik, podajemy jej adres (D0) oraz (opcjonalnie) alias używany w skryptach (wynik).

Przy zmiennej przechowującej wynik odczytu w zakładce Wartość konieczne jest ustawienie typu danych jako Double Word oraz zmiana formatu wartości na Ze znakiem, liczba zmiennoprzecinkowa, 32 Bity, IEEE 754.

Wszystkie dodane połączenia i zmienne prezentują się następująco:

Skrypty WebHMI

Aby uprościć korzystanie z przedstawionych poniżej funkcji wykorzystamy bibliotekę Lua.

W pierwszej kolejności musimy przygotować bibliotekę, w której będą znajdować się funkcje realizujące naszą konwersję. W tym celu wchodzimy w Ustawienia → Skrypty i dodajemy nowy skrypt o nazwie Zmienne64.lib i typie Biblioteka dla innych programów. Jej treść prezentuje się tak:

Do sprawdzania działania skryptów i podglądu wartości zmiennych można wykorzystać funkcję DEBUG(). Jest to odpowiednik funkcji printf(). Dodana do biblioteki zwróci w konsoli wartości poszczególnych zmiennych, np:

Teraz dodajemy skrypt, w którym wywołamy stworzoną funkcję o nazwie LReal2Real(). Nazwa utworzonego skryptu to Główny, a jego typ Wykonaj w każdym cyklu urządzenia. Pamiętajmy, aby na samym początku dołączyć stworzoną bibliotekę.

Po zapisaniu skryptów WebHMI odczyta, przetworzy i zapisze otrzymaną zmienną w zmiennej wynik. Musimy jednak pamiętać o tym, że WebHMI przechowuje odczytaną wartość jako zmienna 32-bitowa, zatem precyzja takiej zmiennej może być niższa.

Komunikacja zdarzeniowa

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.

Zalety komunikacji zdarzeniowej

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.

Wróć na początek