W ostatnim czasie bardzo dużo działo się w naszym projekcie na githubie. Zaczęliśmy od generalnego przeglądu kodu w celu pozbycia się wszelkiego rodzaju błędów i ostrzeżeń w czasie kompilacji i budowania paczek z naszym SZARPem. Przy okazji tych prac porzuciliśmy wsparcie dla analizy (boilery out!), psetd oraz sporej gamy przedawnionych daemonów. Później wzięliśmy się za przeniesienie naszych aplikacji okienkowych na bardziej aktualną wersję wxWidgets co znacznie usprawni wprowadzenie nowych funkcjonalności. W międzyczasie poprawiliśmy sterte (nie stos) błędów, bardzo często mylnie oznaczonych jako features. W tym roku zespół contributorów wyszedł z tarczą. Ba, nawet trzema.
Podczas tych prac narodziła się potrzeba wprowadzenia obsługi nowego protokołu FC firmy Danfoss. Protokół ten określa technikę dostępu zgodnie z zasadą master-slave dla komunikacji szeregowej. Nie będziemy się tu rozwodzić na temat szczegółowej specyfikacji, ale warto zwrócić uwagę na jakość i ilość dokumentacji. Ostrzegamy – godna polecenia jest tylko angielskojęzyczna wersja dokumentacji.
Po krótkiej dyskusji na temat czy powinien to być osobny program czy może wykorzystać całe dobro oferowane przez metadaemon, szerzej znany jako borutadmn, odpowiedź była jasna. Nasza poczciwa boruta dostanie kolejny protokół do obsługi. Tylko od czego zacząć?
My zaczęliśmy od przeglądu dokumentacji (raz kolejny polecamy wersje angielskojęzyczną!), gdzie określimy newralgiczne momenty tego protokołu. Mieliśmy nie zagłębiać się w szczegółową specyfikację, ale protokół tego wymagał. Z dokumentacji dowiedzieliśmy się, że w celu uzyskania danych musimy stworzyć 16 bajtowy telegram
gdzie:
- STX jest zawsze 0x02 (nie lubimy magic numbers),
- LGE w przypadku 16 bajtowego telegramu zawsze będzie 0x0E (hic!)¹,
- ADR to jest adres naszego slave, powiększony o 0x80 (7 bit zawsze jest 1),
- Databytes to zawartość telegramu (rozwinięte poniżej),
- BCC to suma kontrolna w postaci logicznego XOR na wszystkich pozostałych bajtach.
Databytes w naszym przypadku zawiera 6 pozycji 2 bajtowych – PKE, IND, PWEHIGH, PWELOW, PCD1, PCD2. W PKE znajduje się numer parametru oraz funkcja o jaką prosimy żeby falownik wykonał z danym parametrem. IND wykorzystywany jest do odpytania parametrów typu array. Pozostałe pozycje wykorzystane są przez slave w celu przekazania informacji.
Wracając do borutydmn, jest to metadaemon zawierający już w sobie wtyczki do obsługi takich protokołów jak modbus (tcp i serial, client i server), zet (tcp i serial, client), fp210 (serial, client), lumel (serial, client), wmtp (tcp, client). Oparty jest na obsłudze zdarzeń z biblioteki libevent, która zapewnia ciągłość wykonywanych zadań na wielu urządzeniach. Zapewnia to wydajną pracę przy jak najmniejszym nakładzie pracy sprzętu. Pisząc nowy moduł do naszego metadaemona staraliśmy się trzymać standardu C++11, co nie zawsze było zgodne z duchem naszej boruty.
Po kilku dniach nierównej walki borutadmn został okiełznany i nasz contributor otrzymał pierwsze dane z falownika Danfoss VLT 6000. Nastąpiła faza testów tak zwanych na stole, które wykryły szereg nieprawidłowości w utrzymaniu stabilności komunikacji. Błędy te zostały jak najszybciej zlokalizowane i poprawione.
Konfiguracja odczytu z falowników Danfoss za pomocą protokołu FC jest bardzo zbliżona do konfiguracji daemona dla innych protokołów. Na potrzeby naszego nowego modułu musieliśmy wprowadzić nowy atrybut do elementu param zwany parameter-number znajdujący się w przestrzeni nazw ipk-extra. Odpowiada on numerowi parametru, który chcemy odczytać. Po szczegóły konfiguracji zapraszamy do naszej sekcji Dokumentacja.
W najbliższym czasie wtyczka powinna pojawić się w nowszym metadaemonie borutadmn_z opartym na libzmq co oferuje jeszcze więcej możliwości, m.in. odczyt i zapis danych 2/4 bajtowych bez znaku.
__________________
¹ – na nasze potrzeby wykorzystujemy jedynie telegramy 16 bajtowe (LGE=0x0E), ale dopuszczalne są również telegramy 8 bajtowe wtedy pod LGE podstawiamy 6