Chciałbym przedstawić w sumie bardzo prosty projekt – układu pośredniczącego pomiędzy nowymi pompami Grundfos Alpha, a sterownikiem ogrzewania. Kilka lat temu prezentowałem układ sterownika kotłowni, który ma możliwość sterowania pompami Grundfos UPE z użyciem protokołu GeniBus. Niestety pompy te mają taką sobie elektronikę – w trakcie tych kilku lat użytkowania na 5 pomp padły mi 3. Grundfos też się wycofał z ich sprzedaży i powstał problem – mam sterownik, który może sterować innymi pompami, ale tylko w trybie on/off, bez informacji zwrotnej o ewentualnej awarii.
W ciągu tych lat, zmieniła się też koncepcja sterowania urządzeniami – co raz częściej wykorzystuje się do sterowania urządzeniami grzewczymi prosty sygnał PWM. W stosunku do skomplikowanych protokołów typu GeniBus ma to pewne zalety: przede wszystkim prostota układu i implementacji. Oczywiście ilość informacji jaką możemy przesłać do pompy, lub z niej odczytać dzięki PWM też jest ograniczona, ale podstawowe rzeczy, typu sterowanie przepływem, uśpienie pompy, informacje o przepływie lub poborze energii i ewentualnej awarii, możemy bez problemu uzyskać. Niestety mój moduł sterowania kotłownią nie ma możliwości generowania przebiegów PWM o wymaganej przez Grundfosa charakterystyce, ani tym bardziej nie ma możliwości ich odczytywania. Powstał więc dylemat – zaprojektować nowy układ, lub go protezować. Wybrałem to drugie – proteza umożliwiająca sterowanie maksymalnie 5 pompami Grundfos (lub innymi, sterowalnymi przez PWM). Ograniczenie do 5 pomp wynika głównie z powodu ilości koniecznych złącz śrubowych – trzeba by użyć bardzo dużych obudów na szynę DIN, co po prostu nie ma większego sensu, bo w większości domowych kotłowni więcej pomp nie potrzebujemy. A jeśli ktoś potrzebuje to może zrobić dwa takie moduły.
Prezentowany układ jest banalnie prosty – 8 bitowy mikrokontroler XMEGA32E5, sprzętowo generujący 5 przebiegów PWM (można więcej, ale u mnie nie ma takiej potrzeby), oraz odczytujący stan 5 wejść PWM. Układ załatwia interfejs pompa-procesor, dodatkowo mamy możliwość sterowania pompami z zewnątrz przez interfejs RS485 lub RS232 (ten ostatni dodałem tylko jako prosty interfejs serwisowy, do podglądu co się dzieje w razie awarii i sterowania przy pomocy poleceń tekstowych, w formie zrozumiałej dla człowieka).
Przez interfejs RS485 możemy w pełni sterować podłączonymi pompami (ustawienie mocy, odczytanie diagnostyki), a także interfejsem sygnalizującym pracę układu. Można też przez ten interfejs uaktualnić software – wykorzystując wbudowany bootloader. I tu właśnie leży wyjaśnienie zagadki dlaczego użyłem XMEGA32E5, zamiast odpowiednika z mniejszą ilością FLASH (program zajmuje około 11 kB i zmieściłby się w XMEGA16E5). Użyty protokół komunikacyjny – multimaster RS485, zajmuje około 3 kB FLASH i wraz z resztą kodu bootloadera (weryfikacja poprawności kodu aplikacji, autoryzacja) zajmuje dokładnie 4094 bajty FLASH. Ponieważ tylko XMEGA32E5 posiada bootloader o długości 4096 bajtów, więc nie mogłem użyć mniejszego procesora, co zresztą po porównaniu cen i tak nie miało większego sensu.
Układ potrafi działać autonomicznie, ale większy sens jest, gdy jest sterowany przez mój sterownik kotłowni, który nadzoruje pracę pomp. Jak widać, całość mieści się w standardowej obudowie na szynę DIN, na górze mamy 6 LEDów dwukolorowych – 1 LED wskazuje włączenie układu (kolor zielony), oraz wejście w bootloader (kolor czerwony). Dodatkowo w przypadku, gdy nie zgadza się CRC32 kodu aplikacji, program wchodzi w bootloader oczekując na poprawny kod, co sygnalizuje okresowo migający LED.
Pozostałych 5 LEDów sygnalizuje stan każdej z pomp. Kolor zielony – wszystko OK, kolor czerwony – błąd pompy. Dzięki temu użytkownik może się szybko zorientować, czy coś jest nie tak. Dodatkowo LEDy można wykorzystać do sterowania – jako przyciski dotykowe, jednak, póki układ jest sterowany przez sterownik zewnętrzny, ta funkcja jest nieużywana. LEDy dla zaoszczędzenia pinów IO są sterowane multipleksowo.
Zasilanie
Układ posiada przetwornicę impulsową, generującą 5V niezbędne dla generowanego sygnału PWM dla pomp, oraz stabilizator liniowy low-drop generujący z 5V 3,3V do zasilania procesora i transceivera RS485. Sam układ może być zasilany napięciem z zakresu 7-24V AC/DC, dodatkowo jest zabezpieczony bezpiecznikiem polimerowym.
Sygnał PWM
Pompy Grundfos wymagają sygnału sterującego PWM o f=100 do 4000 Hz (mój układ generuje 1 kHz), o napięciu z zakresu 4-24V – stąd w układzie stabilizator na 5V. Działanie pompy zależy od wypełnienia PWM. Ponieważ sygnał trafiający do pompy trafia na LED transoptora, więc całość jest optoizolowana w pompie, zrezygnowałem więc z dodatkowej optoizolacji w układzie. Podobnie optoizolowany w pompie jest zwrotny sygnał PWM. Ponieważ sygnał trafia na LED, sterowanie tak naprawdę jest prądowe, a nie napięciowe – daje to dużą odporność na zakłócenia.
Interpretacja sygnału PWM przez pompę zależy od wybranego profilu. Zazwyczaj brak PWM powoduje jej pracę zgodnie z parametrami ustawionymi przy pomocy przycisków na pompie. Zgodnie z notą pompa interpretuje sygnał następująco (profil A):
≤ 10% – maksymalna moc,
> 10% – ≤ 84% – moc proporcjonalna do wypełnienia,
> 84% – ≤ 91% – minimalna moc,
> 91% – ≤ 95% – histereza on/off,
>90% - tryb standby.
Jest jeszcze profil C, w którym podane wartości są odwrotne – dla bezpieczeństwa przy stosowaniu w obiegach solarnych. Chodzi o to, aby przy rozłączeniu lub braku sygnału kontrolnego, pompa działała z maksymalną mocą, co zapobiega przegrzaniu instalacji solarnej.
Pompa generuje zwrotnie sygnał PWM o f=75 Hz inforumujący o jej stanie:
- 95% - pompa w trybie standby,
- 90% - zablokowany rotor,
- 85% - błąd elektryczny,
- 75% - ostrzeżenie,
- 0%-70% - moc wyjściowa.
Program
Jak pisałem, układ posiada bootloader, umożliwiający wczytywanie nowego wsadu poprzez RS485. Właściwa aplikacja kontroluje pompy, generując zadany przez sterownik sygnał PWM i sprawdzając zwrotnie stan pompy. Inne układy podłączone do magistrali mogą odczytywać bieżący stan pomp oraz go zmieniać. Jak widać nie jest to dużo, bo cała logika sterująca temperaturą i przepływami umieszczona jest w głównym sterowniku kotłowni (który zresztą wkrótce zmienię na coś nowszego). Sterownik może wysyłać powiadomienia do wybranych urządzeń o awarii pompy.
Całość zabezpieczona jest CRC32 – po każdym restarcie układ sprawdza poprawność kodu aplikacji, oczywiście nad wszystkim czuwa WatchDog. W przypadku restartu do pamięci logowany jest powód – czy jest to zadziałanie WatchDoga, zanik zasilania, czy inne przyczyny. Jest to o tyle istotne, że zadziałanie Watch Doga może sygnalizować problem z aplikacją
Komunikacja z otoczeniem odbywa się po magistrali RS485 – w tym celu stworzyłem protokół multimaster, ale o tym w przyszłości. Dzięki temu mogę łatwo wymieniać dane pomiędzy urządzeniami (elementami systemu Home Automation), mam też mostki – RS485-USB oraz RS485-radio (pokazywałem już na elektrodzie).
Problemy
W Eagle, w którym projektowałem PCB, są symbole tranzystorów SMD w obudowie SOT23 z wyprowadzeniami w formacie EBC i BEC. O ile te drugie można kupić, o tyle nie spotkałem się z dostępnym tranzystorem PNP z układem wyprowadzeń EBC. Na szczęście odwrócenie tranzystorów plecami w dół umożliwiło ich przylutowanie.
Drugi mały błąd to brak rezystora ściągającego linię RE/DE transceivera RS485 do masy. Nie jest to wielki problem, ale taki rezystor zapobiega przypadkowemu włączeniu nadajnika, w trakcie włączania układu, lub, kiedy procesor nie steruje linią RE/DE (np. w czasie resetu). Nie przeszkadza to w normalnej pracy, tym bardziej, że sam protokół wymiany danych po RS485, którego używam sprawdza poprawność i w razie potrzeby dokonuje retransmisji ramki danych.
Poza tym układ działa doskonale i robi to, co od niego oczekiwałem.
Kilka przykładów
Upload nowego firmware do jednego ze sterowników po magistrali RS485. Aplikacja do uploadowania jest napisana w Qt:
Możemy też przez interfejs RS485 wydawać inne polecenia w celu sprawdzenia bieżącego stanu układu, wersji oprogramowania itd. Urządzenia mogą przesyłać informacje po sieci w sposób w miarę przejrzysty dla człowieka.
Realizacja prostych poleceń tekstowych umożliwia komunikację za pomocą dowolnego terminala, co dodatkowo uniezależnia cały system od bardziej skomplikowanego softu. W razie czego debuggowanie zapewne też będzie łatwiejsze. Poniżej przykład sprawdzenia wersji oprogramowania modułów, statystyk magistrali i typu modułu:
No i na koniec kilka zdjęć gotowego modułu:
No i schemat oraz rysunek PCB:
Cool? Ranking DIY
Jako opcja w starych budynach bez odpowiedniej infrastruktury to ok, w nowych IMHO prościej pociągnąć kabel.
