Komunikacja szeregowa ze skanerami Motorola/Zebra z poziomu C#

0
179

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.

Zainteresowanych zapraszam na: https://github.com/pstrejczek/MotZebSsi

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here