Aby zrozumieć jak działa WebHMI przeanalizujemy jak działa jego jądro. Schematycznie strukturę rdzenia systemu można przedstawić w następujący sposób:
Źródło: http://docs.webhmi.com.ua/performance_optimization
Jądro działa cyklicznie. Oznacza to, że wszystkie czynności są wykonywane sekwencyjnie jedno po drugim w kolejnych cyklach wykonania programu. Jeśli na jakimś etapie wystąpują opóźnienia, to wpływa to na czas realizacji całego cyklu.
Spójrzmy na każdy z kroków na tym schemacie.
Odczyt konfiguracji
Po uruchomieniu systemu projekt jest ładowany do pamięci głównej. W tym momencie wartości zapisane w rejestrach ulotnych są zerowane, stan wszystkich zdarzeń jest ustawiony na „niewykonane”. Jeśli użytkownik dokona jakiejkolwiek zmiany w ustawieniach rejestrów, połączeń, zdarzeń, skryptów itp., to jądro ponownie odczyta konfigurację po zakończeniu bieżącego cyklu. Wszystkie wartości rejestrów zostaną zresetowane, zdarzenia również zostaną przerwane. Dlatego zmiana konfiguracji projektu w trakcie eksploatacji może spowodować przerwanie zdarzeń i zresetowanie rejestrów znajdujących się w pamięci ulotnej. Nie zalecamy zmiany projektu „w locie” bez potrzeby.
Kiedy ustawienia projektu są wczytane, jądro wchodzi do głównej pętli.
Zapisywanie nowych wartości do rejestrów
Na początku cyklu nowe wartości są zapisywane do rejestrów. System posiada specjalną kolejkę do zapisywania nowych wartości do rejestrów. Istnieją 2 sposoby zapisywania danych do rejestru – poprzez API oraz poprzez skrypty. W obu przypadkach rejestracja nie następuje natychmiast gdy nadejdzie żądanie, tylko do kolejki wysyłane jest żądanie zapisu. Wszystkie żądania zapisu zostaną wykonane na początku następnego cyklu.
Odczyt rejestrów
Następnie następuje odczyt rejestrów z urządzeń zewnętrznych oraz rejestrów wewnętrznych WebHMI. Rejestry odczytywane są w grupach. Grupowanie odbywa się na podstawie ich połączenia. Jeśli na przyład projekt ma połączenie z Delta PLC, Siemens PLC i wewnętrznymi rejestrami WebHMI, odczyt będzie wyglądał następująco:
- Odczytywane są wszystkie rejestry ze sterownika Delta.
- Odczytywane są wszystkie rejestry ze sterownika Siemens.
- Odczytywane są wszystkie rejestry wewnętrzne WebHMI
Wewnętrzne rejestry WebHMI są zawsze odczytywane jako ostatnie, ponieważ zawierają rejestry C0, C1, C2…, w których zapisywane są błędy odczytu z pozostałych połączeń.
Po odczytaniu następują przeliczenia wartości zgodnie z ustawieniami rejestru (skalowanie, zmiana typu itp.). Jeśli występuje przerwa stabilizacyjna dla któregokolwiek z połączeń, to przed odczytaniem grupy rejestrów tego połączenia nastąpi odpowiednia przerwa. Czasami jest to konieczne do stabilnej pracy różnych typów urządzeń na jednej magistrali RS-485. Bez tej przerwy niektóre urządzenia mogą nie być w stanie określić początku ramki danych i pomijać pierwszy pakiet w celu odczytania pierwszego rejestru.
Dodatkowo połączenia mają ustawienie limitu czasu – Timeout. Jest to czas przez jaki system będzie czekał na odpowiedź z urządzeń na swoje zapytanie. Jeśli urządzenia nie odpowiedziały w określonym czasie lub nie odpowiedziały na cały pakiet danych, system przyjmie, że rejestr nie został odczytany. Jego wartość zostanie ustawiona na -1, a status rejestru na nieprawidłowy. Oznacza to, że jeśli nie ma połączenia z jednym z urządzeń zewnętrznych, całkowity czas odpytywania (minimalna długość głównej pętli) wzrośnie o Timeout × liczba rejestrów w danym połączeniu.
Przykład – Wpływ braku połączenia na czas cyklu pracy
Mamy połączenie z Delta SX2 PLC poprzez ModBus RTU. Odczytujemy z niego 5 rejestrów z prędkością 115200. Timeout ustawia się na 100 ms. Średni czas odczytu wszystkich pięciu rejestrów to 30 ms (można to zobaczyć w rejestrze wewnętrznym WebHMI T1). Jeśli połączenie ze sterownikiem PLC zostanie utracone z dowolnego powodu, to średni czas odczytu wszystkich pięciu rejestrów teoretycznie wzrośnie do 5 × 100 ms = 500 ms (iw praktyce wyniesie około 525 ms).
Oznacza to, że w przypadku odpytywania niepodłączonego urządzenia spowolni to cały cykl na znaczny czas. Jeśli konieczne jest zminimalizowanie tego opóźnienia, to należy zmaksymalizować czas pomiędzy zapytaniami oraz zredukować Timeout i pauzę stabilizacyjną, a najlepiej jest albo ponownie połączyć się z urządzeniem, albo rozłączyć to połączenie w ustawieniach.
Wykonywanie skryptów
Po odczytaniu rejestrów jądro wykonuje skrypty. Skrypty (lub programy) są wykonywane bardzo szybko i nie powinno tu być opóźnień przy rozsądnej ilości i złożoności skryptów. Jedyną rzeczą, na którą należy zwrócić uwagę, jest różnica w mechanizmie działania operacji Set and Write.
Operacja Set zmieni wartość podanego rejestru natychmiast, w tym samym miejscu w głównej pętli. I zmieni to tylko wartość w pamięci RAM jądra. Nowa wartość nie zostanie zapisana na urządzeniach zewnętrznych i będzie dostępna tylko do końca bieżącego cyklu.
Operacja Write działa bardzo podobnie do Set, z tą różnicą, że dodaje polecenie zapisania nowej wartości do kolejki zapisu. I na początku następnego cyklu wartość ta zostanie zapisana w odpowiednim rejestrze urządzenia zewnętrznego.
Należy zwrócić uwagę, że jeśli w skrypcie jest warunek, a żaden rejestr z tego warunku nie został odczytany w bieżącej pętli, to warunek ten nie zostanie obsłużony. W związku z tym działania z tego warunku nie zostaną wykonane.
Wyznaczanie stanów rejestrów
W tym punkcie głównej pętli wartości wszystkich rejestrów zostały już wyznaczone i nie zmienią się później, dlatego w tym kroku są wyznaczane stany rejestrów( wyłączone / normalne / ostrzeżenie / alarm).
Przetwarzanie zdarzeń
Po zebraniu i przygotowaniu wszystkich danych uruchamiany jest mechanizm identyfikacji i przetwarzania zdarzeń.
Przetwarzanie zdarzenia rozpoczyna się od sprawdzenia stanu zdarzenia. Podobnie jak w przypadku skryptów, jeśli w bieżącej pętli nie został odczytany żaden rejestr warunku, to warunek ten nie zostanie obsłużony. W związku z tym całe wydarzenie nie zostanie przetworzone.
Jeżeli zdarzenie nie ma trwania w czasie, to warunek jego wystąpienia jest sprawdzany w każdym cyklu. Za każdym razem, gdy ten warunek zostanie spełniony, zostaną wykonane działania dla tego zdarzenia. W każdym kolejnym cyklu, jeśli warunek zostanie ponownie spełniony, to będzie to nowe wystąpienie zdarzenia i działania będą wykonywane ponownie.
Jeśli zdarzenie ma trwanie w czasie, to posiada flagę stanu wykonywania. Jest to flaga, która informuje jądro, że warunek jest spełniony. Takie zdarzenie może rozpocząć się w jednym cyklu i zakończyć w drugim. Może trwać tak długo, jak chcesz, przy czym przy każdej zmianie konfiguracji projektu WebHMI ta flaga będzie koniecznie resetowana.
Gdy warunek rozpoczęcia zdarzenia jest spełniony, flaga wykonania jest ustawiana jako prawda. Jeśli warunek końcowy (jeśli jest ustawiony) lub warunek początku nie jest spełniony (jeśli warunek końcowy nie jest określony), flaga jest resetowana.
Gdy ta flaga jest prawdziwa, wszystkie akcje dla tego zdarzenia są wykonywane. Ta flaga może być również odczytana z wewnętrznych rejestrów WebHMI pod adresami ESx, gdzie x jest identyfikatorem zdarzenia. Należy zwrócić uwagę, że pierwsza wartość „prawda” zostanie obliczona podczas skanu po tym, w którym ta wartość została ustawiona jako prawdziwa.
Oprócz akcji dostępnych dla zdarzeń w bazie danych znajduje się wpis zawierający informacje o zdarzeniu. Należy pamiętać, że ta operacja wymaga dużych zasobów obliczeniowych WebHMI, dlatego zaleca się zapisywanie danych tak rzadko, jak to możliwe. Zbieraj tylko niezbędne dane. Nie ma sensu zapisywać wszystkich rejestrów do bazy danych w każdym cyklu, jeśli wystarczy zebrać dane o pięciu wymaganych rejestrach w odstępie 5 sekund. Ponadto zwiększenie zbyt wielu szczegółowych danych prawdopodobnie doprowadzi do dużego obciążenia karty SD i jej zwiększonego zużycia.
Dlatego postępuj zgodnie ze zdrowym rozsądkiem podczas gromadzenia danych i zbieraj tylko te dane, które są naprawdę potrzebne w Twoim projekcie.
Jedną z opcji zapisywania danych zdarzenia jest rejestrowanie wartości rejestrów co N sekund. Mechanizm jest tak zaimplementowany, że zapis będzie następował nie częściej niż co N sekund od ostatniego rekordu w bazie danych. W tym miejscu konieczne jest wyjaśnienie specyfiki działania tego przedziału. Najlepiej zrobić to na przykładzie.
Przykład – częstotliwość rejestracji wartości rejestrów podczas trwania zdarzenia
Jądro czyta 150 rejestrów ModBus, średnia długość cyklu wynosi 1,3 sekundy. Zdarzenie jest ustawione na rejestrowanie danych co 5 sekund. Załóżmy, że zdarzenie jest wykonywane po raz pierwszy w ciągu T + 0,0 sekund. Dane zostały zapisane do bazy danych również w czasie T + 0,0 sekund.
W następnym cyklu wydarzenie nadal trwa. Czas od ostatniego zapisu to T + 1,3 sekundy. 1,3 <5 sek. więc zapis do bazy danych się nie dzieje. W następnym cyklu wydarzenia wydarzenie nadal trwa. Czas od ostatniego zapisu to T + 2,6 sekundy. 2,6 <5 sek. więc zapis do bazy danych się nie dzieje. W następnym cyklu wydarzenie nadal trwa. Czas od ostatniego nagrania to T + 3,9 sekundy. 3,9 <5 sek. więc zapis do bazy danych się jeszcze nie odbędzie. W następnym cyklu wydarzenie nadal trwa. Czas od ostatniego rekordu to T + 5,2 sekundy. 5,2> 5 sek. więc nastąpi w końcu zapis do bazy danych. Następnie system porówna czas z momentem T + 5,2.
Należy uwagę, że rzeczywisty czas między zapisami wyniesie 5,2 sekundy, a nie 5. Z racji tego że system wyświetla czas z dokładnością do sekundy, może to spowodować, że czas między rekordami będzie wyświetlany jako 6 sekund, a dla niektórych odchyleń nawet 7 sekund (na przykład , pierwszy zapis był w T + 0,9, a drugi w T + 6,1).
To znaczy. ze względu na fakt, że długość cyklu może być niestabilna, wówczas rzeczywisty interwał rejestracji danych również będzie zależał od tej długości. System będzie zachowywał się optymalnie, jeśli określony interwał odpytywania urządzeń (Interwał komunikacji) przekracza faktyczną długość cyklu, a rejestracja w bazie danych jest prowadzona z wielokrotnymi interwałami (Interwał komunikacji).
Przygotowywanie wartości rejestrów dla API
Po przetworzeniu zdarzeń jądro przygotuje listę wszystkich rejestrów, ich stanów oraz wartości i przekazuje ją do API. Następnie odpowiedzi z API dotyczące bieżących wartości rejestrów będą zawierały dane uzyskane w bieżącym cyklu.
Zapisywanie wartości do bazy danych
Na tym etapie cyklu bieżące wartości rejestrów są zapisywane w logu. Tylko te rejestry, dla których uwzględniono odpowiednią opcję, są zapisywane w logu. Jeśli opcja zapisu wykresów dla rejestru jest włączona, to są również zapisywane dane do wykresów.
Zapis na kartę SD to powolna operacja, dlatego rejestrowanie dużej liczby wartości z dużą częstotliwością zmian może zająć znaczną ilość czasu i zasobów systemowych. Zużywa również wytrzymałość karty SD.
Zaleca się dlatego zapisywanie do dziennika tylko tych rejestrów, które są naprawdę potrzebne. Zalecamy też niezbyt częste ich zapisanie. Rejestrowanie 10-20 parametrów co sekundę może znacząco obciążyć system, skrócić czas reakcji interfejsu oraz zwiększyć długość cyklu.
Pauza
Po zakończeniu wszystkich operacji system określa, jaki był rzeczywisty czas cyklu. Jeśli ten czas jest mniejszy niż ustawiony interwał komunikacji, to system zatrzyma się na różnicę [Interwał komunikacji – czas rzeczywisty], tak aby całkowita długość cyklu była dokładnie taka sama, jak czas określony w przedziale komunikacji.
Oznacza to, że jeśli rzeczywisty czas cyklu jest większy niż interwał komunikacji, system nie zatrzyma się i nie będzie w stanie odpytywać urządzeń z określoną częstotliwością.
Jeśli konieczne jest „dopasowanie” określonego przedziału, istnieje kilka sposobów optymalizacji:
- Zwiększenie prędkości wymiany danych na magistralach RS-485, RS-232. Szybkość 9600 jest zbyt mała dla wielu danych. Zalecamy wybranie prędkości 115200 i większej.
- Jeśli jest wiele rejestrów i nie wszystkie muszą być odpytywane w każdym cyklu, można określić większy interwał odpytywania dla mniej ważnych rejestrów. Spowoduje to odciążenie systemu i magistrali danych.