Dzisiaj post techniczny i pewnie też trochę niszowy. Porozmawiamy o tym jak oprogramować komunikację szeregową ze skanerami Motorola/Zebra bez korzystania z trybu emulacji klawiatury i bez zewnętrznych bibliotek. Ale tradycyjnie, zaczniemy od pewnej dygresji.
W układach przemysłowych czy quasi-przemysłowych korzystamy z wielu różnych standardów komunikacji. Używamy różnych standardów zarówno pod względem warstwy fizycznej jaki i warstwy protokołu. W warstwie fizycznej wykorzystujemy głównie Ethernet i połączenia szeregowe. Jeżeli chodzi o protokoły mamy tego multum na różnych warstwach i poziomach. Komunikację realizujemy zarówno z wszelkiego rodzaju czujnikami jak i urządzeniami wykonawczymi. Od wielu lat, w ofercie wielu znanych producentów komponentów znajdziemy także urządzenia na USB. I tutaj moja rada, i być może nieco kontrowersyjne stwierdzenie: USB NIE JEST STANDARDEM PRZEMYSŁOWYM !. Jeżeli nasz układ (w tym komunikacja) ma być niezawodny i łatwo diagnozowany – unikajmy połączenia USB jak ognia ! Ilość problemów na jakie możemy napotkać jest nieskończona. Od problemów z niewystarczającym zasilaniem, bo dziwne funkcjonowanie sterowników w samym systemie, na które nie mamy wpływu – aż po niedorobione biblioteki producentów urządzeń, które plują wyjątkami w dziwnych sytuacjach na które support odpowiada „u mnie działa”.
Jeżeli istnieje możliwość oprogramowania komunikacji w możliwie najniższej (z naszego punktu widzenia) warstwie – TCP albo Łącze szeregowe – nawet jeżeli będzie wymagało to nieco więcej pracy, to taką drogą idźmy. Będziemy mieć wtedy pełny wpływ na stan połączenia i jego diagnostykę. Możemy też odpowiednio zareagować w różnych dziwnych sytuacjach.
Wróćmy jednak do tematu:
Wiele tańszych skanerów z oferty firmy Zebra (kiedyś Motorola) oferuje interfejs szeregowy a wiele z nich świetnie nadaje się także do zastosowań przemysłowych – np. rewelacyjny model DS457. Łatwo i szybko skonfigurujemy taki skaner, jeżeli potrzebujemy tryb emulacji klawiatury. Wybór skanera z interfejsem szeregowym jest też całkiem uzasadniony, gdy chcemy podpiąć go po ethernecie. Skorzystanie z rozwiązania typu Moxa N-port będzie tańsze, niż zakup skanera który sam z siebie posiada interfejs ethernetowy.
Co jednak, gdy chcielibyśmy posterować triggerem i timeout-em trigger-a z własnej aplikacji ? Albo chcemy zdiagnozować ewentualne problemy przy odczycie lub w samej komunikacji ?
Możemy skorzystać do tego celu z potężnego Zebra SDK, albo możemy sami oprogramować komunikację w standardzie SSI realizowaną przez te skanery – co nie jest zadaniem trudnym, a pozwoli na pełną kontrolę nad obsługą urządzenia. Zaletą będzie brak konieczności instalowania jakichkolwiek driver-ów czy zewnętrznych bibliotek jeżeli chodzi o część naszej aplikacji realizującą komunikację z urządzeniem.
KONFIGURACJA SKANERA
Większość skanerów, po wyjęciu z pudełka, jest skonfigurowana do pracy w trybie emulacji klawiatury. Aby skorzystać z trybu SSI musimy odpowiednio skonfigurować skaner. Konfiguracja odbywa się przez skanowanie odpowiednich kodów kreskowych z dokumentacji skanera, którą pobierzemy ze strony www producenta.
Aby skaner poprawnie pracował w trybie SSI i łatwo było nam oprogramować komunikację najlepiej jest ustawić:
-
Tryb triggera na HOST
-
SSI HOST
-
SEND RAW DECODE DATA
-
Disable ACK/NACK
Jeżeli korzystamy z urządzenia typu N-port w trybie TCPServer i komunikację realizujemy po ethernecie, konieczne może się również okazać zeskanowanie parametru Host: RTS High.
Po tych operacjach, skaner powinien być gotowy do komunikacji w trybie SSI.
OBSŁUGA KOMUNIKACJI
Musimy zadbać o właściwe sformatowanie ramki, którą wyślemy do skanera.
Ramka powinna zawierać:
-
1 bajt długości ramki.
-
1 bajt samego komunikatu
-
1 bajt źródła komunikatu – ustawiamy na 4
-
1 bajt z ilością powtórzeń – ustawiamy na 0
-
1 bajt sumy kontrolnej
Suma kontrola jest dość prosta do policzenia:
Do długości ramki dodajemy wartość samego bajtu komunikatu, wartość bajtu źródła komunikatu, oraz wartość bajtu z ilością powtórzeń. Całość mnożymy przez -1. Przy tych długościach komunikatu cała suma kontrola zmieści się nam w 1 bajcie.
Dalej obsługa jest tak naprawdę stosunkowo prosta:
-
otwieramy sobie połączenie szeregowe lub TCP.
-
wysyłamy do skanera bajt komendy włączającej trigger – 0x8A (w Hex) – pamiętamy o formatowaniu ramki
-
następnie odpalamy trigger wysyłając bajt – 0xE4 (w Hex) – pamiętamy o formatowaniu ramki
-
jeżeli skaner zeskanuje kod to w odpowiedzi otrzymamy zeskanowany kod
-
dobrze jest też wprowadzić timeout – czyli po pewnym czasie od odpalenia triggera wyłączyć go, jeżeli kod nie został zeskanowany. Wyłączenie triggera – 0xE5(Hex) – pamiętamy o formatowaniu ramki
I to tak naprawdę cała filozofia.
Na github-ie umieściłem napisaną przez siebie bibliotekę do obsługi takiej komunikacji (opartą na eventach) wraz z prostą aplikacją testową w Windows Forms.