Wstęp
Niedawno pojawił się u mnie w głowie pomysł polegający na sterowaniu i komunikacji z przekaźnikiem programowalnym PR200 firmy akYtec przy pomocy mikrokontrolera. Pierwszą oczywistą myślą jak sprawić, żeby urządzenia ze sobą „rozmawiały” był modbus. Takie połączenie jest jak najbardziej możliwe, ale ja chciałem spróbować coś oryginalnego, prostszego… I tak powstał niżej opisany „protokół”.
Opis odbioru i nadania danych
Postanowiłem, że komunikacja będzie oparta o liczniki. Mikrokontroler wysyłałby daną ilość impulsów odpowiadającą numerowi komendy. Później wystarczyło się „umówić” przykładowo, że komenda nr. 10 odpowiada za włączenie wyjścia nr. 10.
Wysyłanie danych jest jednokierunkowe (uC –> Sterownik). Mikrokontroler (ATmega328p) generuje ciąg impulsów. Przykładowo możemy do niego podłączyć klawiaturę numeryczną i wysyłać kod przycisku jako komendę np. wciśnięcie litery „A” oznacza wysłanie 10 impulsów. Do komunikacji potrzebne są tylko dwa przewody (masa i sygnałowy). Oczywiście nie można sterować wyjściem mikrokontrolera wejścia
sterownika z uwagi na różne napięcia pracy (5V i 24V). Na pomoc przychodzi prosty układ, którego schemat znajduje się poniżej:
Układ zapewnia izolacje galwaniczną, co jest wskazane w takich aplikacjach. Jeśli ktoś nie ma transoptora, może połączyć mikrokontroler przez rezystor R1 z bazą tranzystora, pamiętając aby połączyć masę sterownika z masą mikrokontrolera, ponieważ to względem masy mierzy się wszelkie napięcia.
Jak wiadomo, komunikacja powinna być maksymalnie szybka i stabilna (odporna na zakłócenia i awarie). Moim zabezpieczeniem jest wysyłanie takiej samej komendy dwa razy. Sterownik odbiera obie „paczki” danych i później je ze sobą porównuje. Jeśli są sobie równe, finalna komenda jest dostępna do odczytania, jeśli nie są równe, takie dane są odrzucane. Dzięki temu działaniu nawet w przypadku przerwania przewodu w trakcie transmisji żadne niechciane przekłamania nie wystąpią.
Niestety szybkość transmisji nie pozwoli nam na zbyt wiele. Wysłanie jednej komendy trwa 0.6 [s]. Używając wejścia sterownika, jako portu do komunikacji ogranicza nas czas reakcji wejścia i czas odpowiedzi w cyklu pracy sterownika. Na zdjęciu poniżej widać przykładowe wartości dla PR-200.
Czasy trwania impulsów dobrałem tak, żeby sterownik na pewno je odczytał. Stan wysoki impulsu trwa 10 [ms] a niski 5 [ms]. Dla moich potrzeb taka szybkość wystarczy, ponieważ „protokołu” będę używał do włączania wyjść lub wykonania jakiejś części programu. Moim sposobem mogę wysłać 20 różnych komend (numery od 1 do 20).
Ramka czasowa impulsów wysyłanych przez mikrokontroler:
Część programowa
Program wgrany do przekaźnika programowalnego ma za zadanie zliczanie ilości impulsów. Na wejście I1 podawany jest sygnał i zmienna RPD = 0. W takiej sytuacji wykonuje się część programu otoczona zielonym kolorem. Licznik CTN1 zlicza impulsy. Po 0.29 [s] od pojawienia się pierwszego pulsu na I1 wyzwala się TON3 i powoduje zapisanie zmiennej licznika do zmiennej CMD1. Po odliczeniu 0.3 [s] przez timer TON2 zmienna T1 powoduje ustawienie RPD = 1, co oznacza przejście do części liczącej drugą taką samą ramkę danych (kolor czerwony). Działanie tej części programu jest takie samo jak poprzedniej. Po odbiorze drugiej paczki impulsów sterownik porównuje zmienne przechowujące ilość pulsów i jeśli są równe, to przepisywane są na wyjście (kolor fioletowy).
Algorytm mikrokontrolera napisany w języku C znajduje się poniżej. Komentarze powinny wyjaśnić każde działanie.
Część odpowiedzialna za skonfigurowanie programu (inicjalizacja zmiennych, dodanie bibliotek):
Dalej mamy funkcje potrzebne do wysyłania impulsów i pętle programu:
Przykład działania
Przy pomocy arduino dekoduje sygnał z pilota na podczerwień, następnie wysyłam komendę odpowiadającą wciśniętemu przyciskowi. Na wyświetlaczu widać bieżącą komendę. CMD = 1 włącza najniższą diodę, CMD = 2 wyłącza ją, CMD = 3 uruchamia część programu, która przesuwa diody.
Podsumowanie
Powyższy przykład proszę traktować jako ciekawostkę, którą można wykorzystać raczej w warunkach domowych i dla zabawy. W warunkach przemysłowych mamy do dyspozycji dużo bardziej zaawansowane protokoły i warstwy fizyczne komunikacji odporne na wszelkie błędy. Niemniej jednak opracowywanie własnych sposobów porozumiewania się urządzeń daje wiele satysfakcji i uczy, więc polecam.
