Siemens Logo! 8 czy Eaton easyE4? Który przekaźnik będzie lepszym wyborem? Dylematów tego typu oraz związanych z nimi porównaniami w internecie pojawiło się dosyć dużo. Ale czy odpowiedź jest oczywista?
Jakiś czas temu poproszono mnie o wykonanie projektu w oparciu o przekaźnik Siemens’a. Do tamtego momentu nie miałem jeszcze okazji programować urządzeń tego typu, na co dzień zajmuję się raczej programowaniem sterowników swobodnie programowalnych PLC. Na napisanie programu dostałem kilka godzin, nie było więc mowy o gruntownym zapoznaniu się z manualem oprogramowania Logo Soft Comfort. Stwierdziłem, że potrzebne informacje będę wyszukiwał na bieżąco, w miarę pojawiających się problemów.
Projekt został oddany po terminie. Nie wszystkie wymagania klienta zostały spełnione. Zawiodłem.
Kilka dni po finalizacji zlecenia wpadł mi w ręce easyE4. Do głowy przyszła mi myśl, aby jeszcze raz podejść do tematu i napisać program opierający się o te same wymagania projektowe co poprzednio. Tym razem na spokojnie, mając na to tyle czasu, ile będzie potrzeba. Dobór easy zamiast Logo wydawał się trafiony. Bądź co bądź, są to urządzenia uznawane za pokrewne. Ale czy na pewno takie są?
W tym artykule chciałbym opisać moje zmagania podczas implementacji tego samego projektu na dwóch różnych przekaźnikach programowalnych. Z uwagi na fakt, że jest to moje pierwsze zderzenie z tego typu urządzeniami, uważam, że ktoś z większym doświadczeniem na tym polu, na pewno poradziłby sobie lepiej. Z tego względu, chciałbym podkreślić, że jest to subiektywny opis trudności, które napotkałem podczas wykorzystania obydwu przekaźników.
Wymagania projektowe
Projekt polegał na wykorzystaniu układu logicznego do sterowania pracą trzech dzwonków sygnalizujących różne pory pracowniczego dnia, takie jak początek zmiany, przerwa, koniec zmiany, początek kolejnej itd.
Klient prosił, aby zadziałanie każdego z trzech dzwonków, można było wywołać dziesięciokrotnie podczas jednej doby, z różnymi godzinami zadziałania. Konfiguracja każdego wywołania powinna ponadto pozwalać na ustawienie długości pracy dzwonka oraz rodzaju sygnału (sygnał ciągły/przerywany). Dodatkowo, parametryzacja urządzenia miała się odbywać przez interfejs typu webserver.
Podsumowując wymagania projektowe:
- 3 fizyczne wyjścia sygnalizacyjne,
- 10 indywidualnie parametryzowanych wywołań każdego z wyjść,
- Każde wywołanie pozwalające na konfigurację: dni tygodnia zadziałania, godziny rozpoczęcia, a także czasu oraz rodzaju sygnalizacji,
- Parametryzacja za pośrednictwem webserver’a.
Pamięć remanentna
Na pierwszy ogień poszła weryfikacja lokalizacji wszystkich tych danych, które muszą pozostać w pamięci po ewentualnym restarcie zasilania. A więc na pewno dni tygodnia i godzina zadziałania, a także czas i rodzaj sygnalizacji.
Siemens
Poszukiwania rozpocząłem w dokumentacji urządzenia. Znalazłem tam następującą informację:
A więc Logo posiada 250 jednostek pamięci remanentnej. Ale w jaki sposób przypisać ją do konkretnych rejestrów? Głębsza analiza dokumentacji utwierdziła mnie w przekonaniu, że pamięć REM służy do obsługi niektórych bloków funkcyjnych, których parametry mogą być podtrzymywane. Aby się upewnić zaglądnąłem dodatkowo na forum Siemens’a, gdzie okazało się, że nie jestem pierwszą osobą szukającą pomocy. Podsumowując – w sposób bezpośredni nie ma możliwości, aby pewna zdefiniowana przez użytkownika ilość rejestrów była podtrzymywana po wyłączeniu zasilania. Użytkownik może w sposób pośredni zapamiętać wartości danych rejestrów, wykorzystując określone bloki funkcyjne, wyposażone w opcję podtrzymywania parametrów.
Tak więc, pisząc aplikację zawierającą informacje, które powinny zostać zapamiętane, należy budować ją w taki sposób, aby wykorzystywać konkretne bloki. Taki sposób programowania jest dosyć uciążliwy i niejednokrotnie można spędzić dużo więcej czasu na szukaniu pośredniego sposobu podtrzymania rejestru niż pisząc konkretną logikę.
easyE4
W dokumentacji easySoft7 znalazłem następujący zapis:
Bajty remanencji
Cały obszar znaczników remanentnych easyE4 nie może przekraczać 400 bajtów. Suma bajtów remanencji dla programu głównego i modułów użytkownika (UF) jest wyświetlana w widoku projektu, w zakładce Ustawienia systemowe. Jeżeli zakres znaczników remanentnych przekracza 400 bajtów, jest to wskazywane w polu wolne wyświetlaną na czerwono liczbą ujemną.
easyE4 oferuje 400 bajtów pamięci, która może zostać zdefiniowana jako remanentna. Chcąc sobie uzmysłowić czy jest to duża ilość, należy mieć świadomość że urządzenie udostępnia użytkownikowi 512 bajtów pamięci na przechowywanie programu głównego i modułów użytkownika.
Otwierając zakładkę, o której mowa w dokumentacji, można w prosty sposób zadeklarować przedział pamięci jako podtrzymywany.
Czasowa funkcja sterująca
Przekaźniki programowalne wyposażone są zwykle w szeroki wachlarz czasowych funkcji sterujących. Niejednokrotnie można przeczytać o przykładach ich wykorzystywania przez użytkowników domowych do automatyzacji rutynowych czynności w ciągu tygodnia, których przykładem może być otwieranie i zamykanie rolet w zadane dni o określonych godzinach.
Wykorzystanie tego typu funkcji zaimplementowanej przez producenta wydawało się logicznym rozwiązaniem.
Siemens
Producent Logo! 8 udostępnił użytkownikom blok „WT – Weekly Timer”, którego funkcjonalność okazała się bardzo przydatna podczas pisania programu.
Bloczek parametryzowany jest poprzez zaznaczenie dni tygodnia, oraz określenie o której godzinie i na jaki czas ma zostać aktywowane wyjście bloczka. Niestety, nie doszukałem się możliwości zdefiniowania rejestrów, które mógłby być modyfikowane z poziomu webserver’a. W instrukcji obsługi również nie znalazłem takiej informacji. Przeglądając forum Siemens’a w poszukiwaniu odpowiedzi, natknąłem się na przykład parametryzacji bloczka „WT” z poziomu przeglądarki. Jego szybka analiza pozwoliła na zrozumienie mechanizmu mapowania, który należy zastosować.
W menu „Tools” znajduje się opcja „Parameter VM mapping”. W dokumentacji funkcja ta opisywana jest w następujący sposób:
LOGO! Base Module uses VM (Variable Memory) as a local data communication interface for data exchange by means of connections/data-transfer configuration.
W wolnym tłumaczeniu, użytkownik może używać tej funkcji jako interfejs do wymiany danych, między innymi z webserver’em. Wykorzystując VM mapping umożliwiłem dostęp do zmiennej „On Time1” oraz „Weekday1” (godzina i dzień załączenia bloczka WT) z poziomu interfejsu użytkownika.
Wykorzystanie bloczka „WT” częściowo rozwiązało problem z rejestrami remanentnymi – wszystkie wartości, które przyjmuje, są podtrzymywane. Ze względu na ograniczoną ilość czasu oraz brak swobodnych rejestrów remanentnych, które można by było zastosować w sposób bezpośredni, zdecydowałem się na podział dziesięciu wywołań pojedynczego dzwonka na wywołania z sygnałem ciągłym o długości 2s i 4s oraz na wywołania z sygnałem przerywanym, również o długości 2s i 4s. Ograniczyłem tym samym możliwości konfiguracji każdego z wywołań przez użytkownika, oszczędzając jednak sporo czasu, który musiałbym poświecić na poszukiwanie pośrednich rozwiązań podtrzymywania zmiennych.
Funkcja „WT” podłączona do wejścia I1 pełni rolę aktywatora bloku funkcyjnego. W przypadku, gdy aktualny dzień został wybrany przez użytkownika, oraz zadana godzina zgadza się z aktualną, na wejściu I1 pojawia się impuls aktywujący pracę bloku.
Wejścia I2, I3 i I4 pozwalają na parametryzację odpowiednio dzwonka o sygnale 2s, 4s oraz charakteru pracy (ciągłym/impulsowym).
Z uwagi na powtarzającą się funkcję, zależności sterowniczo-czasowe zamknąłem w bloku funkcyjnym użytkownika „UDF”.
Ze względu na wymaganą ilość wywołań pojedynczego dzwonka, poniższy kod skopiowano dziesięciokrotnie. Wyjścia bloków funkcyjnych połączyłem za pomocą instrukcji OR, na której wyjściu umieściłem fizyczne wyjście sterownika „Q1”, stanowiące sygnał sterowniczy jednego z dzwonków.
Opisany powyżej fragment kodu powieliłem trzykrotnie, tworząc sterowanie dla drugiego i trzeciego dzwonka.
easyE4
Eaton również wyposażył swój przekaźnik w kilka rozbudowanych funkcji sterujących związanych z czasem.
Blokiem, który wydawał się spełniać oczekiwania był „WT – Tygodniowy zegar sterujący”.
Po przeniesieniu bloczka na pole robocze okazało się, że jest on wyposażony jedynie w pojedyncze wejście aktywujące „EN” oraz w pojedyncze wyjście sterujące „Q1”. Wyświetlone poniżej parametry bloku umożliwiały zaznaczenie konkretnych dni tygodnia oraz określenie czasu aktywacji wyjścia „Q1”. Nie zauważyłem niestety możliwości przypisania jakiegokolwiek rejestru do zdalnej parametryzacji bloczka.
Analizując informację zawarte w dokumentacji, znalazłem nastepujący zapis:
WT – Tygodniowy zegar sterujący
Dla każdego 32 tygodniowych zegarów sterujących WT01 do WT032 można sparametryzować 8 zdarzeń przełączania, które będą wykonywane o tej samej godzinie w dowolnie wybranych dniach tygodnia. Ustawienia mają dokładność do minuty i nie mogą być zmienione w czasie pracy; należy je rozumieć jako stałą parametryzację.
Jednak wgłębiając się dalej w dokument, odnalazłem informację:
Jeżeli dla modułu funkcyjnego w punkcie Zestaw parametrów/Wyświetlanie parametrów/wybrano + Wywołanie dostępne, wówczas czasy przełączania można zmieniać na urządzeniu w trybach pracy RUN/STOP, w menu PARAMETRY.
Podsumowując, użytkownik może sparametryzować blok funkcyjny „WT” na dwa sposoby: na stałe, poprzez konfigurację w środowisku easySoft 7 i wgranie parametrów do przekaźnika, lub poprzez menu kontekstowe samego urządzenia, jeśli zostało ono wyposażone w ekran.
W praktyce konfiguracja z poziomu webserver’a oraz podglądu ekranu jest możliwa, jednak nie wyobrażam sobie, aby użytkownik, który nie jest równocześnie programistą tego urządzenia i nie zna numerów i nazw odpowiednich bloczków, był w stanie poprawnie wykonać tą operację. Pomijam tutaj jakikolwiek komfort użytkowania, biorąc pod uwagę konieczność ustawienia 30 wywołań dzwonków.
Z tego względu zdecydowałem się na napisanie fragmentu programu, pełniącego funkcję „Tygodniowego zegara sterującego”. W celu uzyskania informacji o aktualnym dniu oraz godzinie, wykorzystałem bloczek „RC – Zegar czasu rzeczywistego”.
Dostep do wszystkich informacji oferowanych przez funkcję można uzyskać w sposób bezpośredni, jednak „DD – dzień” jest określany w formie liczby z zakresu od 0 do 6, gdzie 0 to niedziela, a 6 – sobota. Na potrzebę dalszego wygodnego dostępu do kolejnych dni tygodnia bez konieczności każdorazowego wykorzystania komparatorów analogowych, napisałem prostą funkcję konwertującą dzień tygodnia w postaci liczbowej na kolejne markery.
Z uwagi na brak możliwości użycia bloku „WT”, wykorzystałem zwykłe markery jako aktywatory wywołania dzwonka w zadany dzień. Stworzenie aktywatorów dla każdego dnia tygodnia wymagało wykorzystania stosunkowo dużej liczby markerów. Ich liczba będzie wynosić: 7 (dni tygodnia) x 10 (wywołań pojedynczego dzwonka) x 3 (dzwonki – Q1, Q2, Q3) = 210 markerów.
Poniżej zamieszczony fragment programu służy do sprawdzenia czy pojedyncze wywołanie jest aktywne, a więc czy został zaznaczony dzień odpowiadający aktualnemu. Dla przykładu, jeśli jest niedziela (M100 = TRUE) i zaznaczono, aby pierwsze z dziesięciu wywołań (D1) pierwszego dzwonka (Q1) było aktywne w niedziele (M241 = TRUE), wówczas marker M110 ma stan wysoki.
Bardziej eleganckim rozwiązaniem byłoby zamknięcie tego typu funkcji w module użytkownika „UDF”, jednak z uwagi na ograniczoną ilość możliwych wejść do stworzenia (12), zdecydowałem się na pozostawienie tego fragmentu kodu w poniższej postaci.
Z uwagi na ilość wymaganych wywołań, a więc 10 (wywołań) x 3 (dzwonki – Q1, Q2, Q3), kod został skopiowany 30 razy, oczywiście zmieniając markery odpowiadające aktywatorom kolejnych wywołań dzwonków.
Kolejnym krokiem było utworzenie funkcji, która zweryfikuje, czy pojedyncze wywołanie dla danego dzwonka jest aktywne (wynik poprzedniej funkcji) oraz czy aktualna godzina i minuta zgadza się z wartościami zadanymi.
Do tego momentu, kod odpowiada funkcjonalności pojedynczego bloku „WT – Tygodniowy zegar sterujący”, z tą różnicą, że powyższe podejście pozwala na parametryzację z poziomu webserver’a.
Dla wygody użytkowania, oprócz komparatorów weryfikujących wspomniane wyżej zależności, w module umieściłem również przekaźniki czasowe sterujące pracą dzwonka, stąd możliwość wyboru sygnału ciągłego lub impulsowego, a także wartości czasu trwania dzwonka oraz czasu impulsu.
Powyższy moduł użytkownika stanowi jedynie pojedyncze wywołanie jednego z trzech dzwonków. Tak więc aby sprostać wymaganiom projektowym, skopiowałem moduł odpowiednią ilość razy, a więc 10 (wywołań) x 3 (dzwonki – Q1, Q2, Q3) = 30, odpowiednio wprowadzając zmienne wejściowe.
Wszystkie dziesięć wywołań pojedynczego dzwonka zrealizowałem jako prostą alternatywę wyjść z modułów użytkownika „Dzwonek”. Oczywiście, biorąc pod uwagę ilość fizycznych dzwonków, taki fragment kodu pojawił się w programie trzykrotnie.
Interfejs użytkownika
Wymaganiem projektowym było udostępnienie użytkownikowi interfejsu użytkownika, pozwalającego na parametryzację wywołań dzwonków, poprzez wykorzystanie zabudowanych w przekaźnikach webserver’ów.
Siemens
Pierwszą rzeczą, jaką rzuciła mi się w oczy po aktywowaniu usługi, była opcja „to customised site”, dostępna podczas logowania. W wolnym tłumaczeniu, oznacza ona, że użytkownik ma możliwość zbudowania własnej strony web, pełniącej interfejs użytkownika.
W dokumentacji odnalazłem informację, że taką stronę można zaprojektować za pomocą darmowego oprogramowania Logo Web Editor. Obsługa programu okazała się bardzo prosta i w kilka minut pozwoliła mi stworzyć prosty interfejs, pozwalający na konfigurację wszystkich wywołań dzwonków. Z uwagi na ilość dostępnego miejsca na ekranie, podzieliłem wizualizację na trzy osobne strony przypisane do kolejnych wyjść sterujących – „Dzwonek 1”, „Dzwonek 2”, „Dzwonek 3”.
Jak wcześniej pisałem, dostęp do rejestrów sterownika odbywa się poprzez mapowaną pulę pamięci, dostępną w LWE jako pamięć „V” dla rejestrów typu word oraz „VB” dla bajtów.
Podczas wgrywania wizualizacji okazało się, że do jej przechowywania wymagana jest karta microSD, zamontowana w urządzeniu. Po prawidłowym wysłaniu interfejsu do Logo, sprawdziłem poprawność działania poprzez zalogowanie się do webserver’a i ustawienie kilku przykładowych wywołań dzwonków.
Nawigacja pomiędzy stronami odbywa się poprzez menu „Navigation”, wysuwane z lewej strony interfejsu.
easyE4
Przed przystąpieniem do pracy nad interfejsem użytkownika przeglądnąłem dokumentację w poszukiwaniu informacji na temat tworzenia własnego interfejsu web’owego, na kształt tego w Logo. Gdy próby znalezienia informacji spełzły na niczym, zwróciłem się do kolegów starszych stażem, jednak oni również stwierdzili, że Easy nie posiada takiej możliwości.
Nastepnym krokiem było przeglądnięcie interfejsu udostępnianego przez webserver Eaton’a. Pośród sporej ilości zakładek znalazłem opcję „Lista parametrów”. Zakładka ta umożliwia stworzenie własnej puli parametrów, których stan można monitorować oraz modyfikować. Bardzo szybko udało mi się dodać wszystkie rejestry związane z pracą utworzonego wcześniej programu. Tak przygotowana lista może ostatecznie pełnić funkcję interfejsu użytkownika. Nie jest to tak eleganckie rozwiązanie jak w Logo, ale jednak.
Dodatkowo w zakładce „Wyświetlacz” zauważyłem możliwość kontrolowania menu Easy E4, tak jak miało by to miejsce operując fizycznymi przyciskami i obserwując reakcję na ekranie urządzenia. W dokumentacji znalazłem również informację, że jest możliwość stworzenia własnych ekranów użytkownika, które mogą służyć do podglądu lub modyfikacji parametrów.
Posługując się blokiem funkcyjnym „D – znacznik tekstowy”, utworzyłem szablon służący do modyfikacji wszystkich wartości związanych z pojedynczym wywołaniem pracy dzwonka.
Wybór odpowiedniego ekranu odbywa się poprzez zmianę wartości rejestru MB426 na ekranie urządzenia i porównanie jej z kolejnymi numerami ekranów. Niestety nie ma możliwości dynamicznego podmieniania rejestrów, więc musiałem skopiować blok trzydziestokrotnie.
Podczas wgrywania zaskoczył mnie fakt, że Eaton nie potrzebuje karty microSD do przechowywania ekranów, jak miało to miejsce w przypadku Siemens’a. Obsługa interfejsu użytkownika z poziomu webserver’a jest wygodna, z poziomu urządzenia dużo bardziej uciążliwa.
Podsumowanie
Podczas pracy nad projektem, bardzo dużo dowiedziałem się na temat specyfiki przekaźników programowalnych. Szczerze mówiąc nie sądziłem, że jest im tak daleko do sterowników PLC i pewne zachowania dla mnie naturalne, nie mogły mieć miejsca podczas ich programowania.
Ale wracając do pytania: Eaton easyE4 czy Siemens Logo! 8 ?
Uważam, że obydwa urządzenia niezaprzeczalnie mają swoje zalety. Ich dobór powinien odbywać się po dokładnej analizie założeń projektowych – czego z uwagi na niewielką ilość czasu – na pewno u mnie zabrakło.
Poszukiwania alternatywnych dróg przechowywania informacji w sposób remanentny w przypadku Siemens’a, w znacznym stopniu wydłużyły czas pracy nad projektem. Prostota deklarowania puli rejestrów podtrzymywanych w Eaton’ie przemawia na jego korzyść.
Implementacja gotowej funkcji – „WT” w Logo, której parametry można było modyfikować w sposób zdalny, sprawiła, że ilość spędzonego czasu nad klawiaturą podczas rozpatrywania tej kwestii była dużo krótsza, niż pisanie dedykowanej funkcji w Eaton’ie.
Eleganckie podejście do tworzenia interfejsu użytkownika w przypadku Siemens’a również przemawia za wyborem tego przekaźnika. Wykorzystanie listy parametrów lub obsługa wyświetlacza i dedykowanych ekranów w Eaton, nie przypadło mi do gustu. Trzeba zaznaczyć jednak, że do obsługi interfejsu Logo potrzebuje dodatkowego nośnika danych, Eaton obywa się bez.
A więc który?
Podchodząc ponownie do tematu, na pewno zaproponowałbym zmianę sprzętu na najprostszy sterownik PLC lub panel operatorski z obsługą makr. Jednak jeśli musiałbym zostać w świecie przekaźników, z uwagi na wszystkie wspomniane kwestie, ponownie wybrałbym Siemens’a.
Artykuł został nagrodzony w Konkursie iAutomatyka – edycja Grudzień 2019
Nagrodę Słuchawki bezprzewodowe + powerbank + zestaw gadżetów dostarcza ambasador konkursu, firma B&R. |