Symulator/MaSzyna/CAN Modbus

Z Rainsted
Skocz do: nawigacji, wyszukiwania

(Koncepcja jest w trakcie opracowywania.)

Do komunikacji z urządzeniami automatyki zostały przygotowane struktury łączące w sobie funkcjonalność magistrali CAN oraz protokołu Modbus TCP. Ze względu na konieczność wykonywania dodatkowych operacji nie są one bazową formą komunikacji, a jedynie mają ułatwić budowę zewnętrznych urządzeń sterujących.

Stany binarne są dostępne bezpośrednio, jako liczby 32-bitowe. Wartości "analogowe" są każdorazowo przeliczane za pomocą wielomianu trzeciego stopnia, dzięki czemu można dowolnie skalibrować współpracujące urządzenia, a także łatwo skorygować ich ewentualną nieliniowość.

Do każdego parametru, którego wartość ma być przesyłana do urządzenia zewnętrznego przypisana jest ramka wielkości 16 bajtów (4×int32), będąca (zależnie od konfiguracji), ramką CAN albo Modbus TCP. W każdym przypadku wartość parametru zajmuje przedostatnią ćwiartkę, czyli bajty 8..11 (z 0..15). Liczby int32 są w pamięci rozmieszczone zgodnie z konwencją little endian (czyli najmłodsze bajty liczb int32 to 0, 4, 8 i 12), natomiast zakłada się, że ewentualna transmisja szeregowa wykonywana jest w kolejności big endian (czyli kolejno bajty 3, 2, 1, 0, 7, 6, 5, 4, 11, 10, 9, 8, 15, 14, 13, 12).

Magistrala CAN

W tym przypadku bajty 0..3 stanowią 19-bitowy nagłówek danych (w tym 11-bitowy adres urządzenia, będący również priorytetem oraz liczbę bajtów danych, zawsze równą 8). Adres portu oraz numer funkcji jest w bajtach 4..7 (znaczenie jak w Modbus, ewentualnie można to użyć jako CANopen). Przesyłana wartość jest w bajtach 8..11, a bajty 12..15 są zarezerwowane na ewentualną sumę CRC i zakończenie ramki (w sumie 28 bitów). Suma CRC normalnie nie jest liczona, jedynie zarezerwowane jest miejsce — sterownik niskiego poziomu nie musi wykorzystywać tych pól. Zakłada się, że ewentualne dodatkowe bity w ramce (po 5 identycznych wartościach musi być wstawiony dodatkowy bit o przeciwnym stanie) są uwzględniane dopiero na etapie przesyłania.

Jeśli zamiast adresów 11-bitowych mają być używane adresy 29-bitowe, można dodatkowo wykorzystać w tym celu zawartość bajtów 12..15.

Protokół Modbus TCP

Pracując w trybie serwera, symulator odpowiada jedynie ramką z funkcją 3 (odczyt rejestrów 16-bitowych). Odczytywane są zawsze dwa takie rejestry, czyli 32 bity, zaczynając od nieparzystego (w sensie numeru przesyłanego). Możliwy też jest zapis wartości funkcjami 6 i 16 (zapis rejestrów). Zmieniając numer funkcji w ramce na 6 lub 16 uzyskuje się pracę w trybie klienta – wartości będą wysyłane do współpracującego urządzenia bez konieczności generowania zapytań.

Bajty 0..3 zawierają identyfikator ramki (bajty 2..3) oraz typ protokołu (czyli zero w bajtach 0..1). Bajty 4..7 zawierają długość ramki bez nagłówka (bajty 6..7 zawierają liczbę 6), adres odbiorcy (bajt 5) i numer funkcji (bajt 4, zawierający liczbę 3). Bajty 7..11 zawierają przesyłaną wartość. Bajty 12..16 nie są używane, ale mogą zawierać np. adres IP, jeśli komunikacja odbywa się z wieloma innymi urządzeniami.

00 00 00 00 - identyfikator ramki i typ protokołu
00 06 01 03 - długość, adres i numer funkcji
xx xx xx xx - wartość parametru
00 00 00 00 - bajty nie wykorzystane

W przypadku wysyłania danych w inny sposób niż TCP, musi być odpowiednio przetworzona ramka TCP.

Inne protokoły komunikacyjne

Na bazie przyjętego mechanizmu mogą być realizowane inne rozwiązania komunikacyjne. Parametr pochodzący z symulacji jest umieszczany w bajtach 8..11, natomiast pozostałe 12 bajtów może mieć dowolną zawartość, ustawianą plikami konfiguracyjnymi.

Pole danych

Dane są umieszczone w bajtach 8..11. Mogą to być 32 stany binarne, albo jedna liczba "analogowa", określająca wartość z pewnego przedziału. W tym drugim przypadku parametr dostępny w symulacji można przekształcić wielomianem trzeciego stopnia, dzięki czemu można skorygować ewentualną nieliniowość i uprościć konstrukcję końcowego urządzenia. Również przesłana przez zewnętrzne urządzenie liczba jest przeliczana wielomianem trzeciego stopnia.