ASCII dla danych PLC: kody dziesiętne, szesnastkowe i sterujące

ASCII pozostaje powszechnie stosowany w projektach PLC, ponieważ wiele urządzeń przemysłowych wymienia tekst po jednym bajcie. Czytniki kodów kreskowych, drukarki etykiet, wagi, napędy, bramki szeregowe i terminale operatorskie często przedstawiają polecenia i pomiary jako kody znaków. Inżynierowie, którzy potrafią przechodzić między znakami, wartościami dziesiętnymi i bajtami szesnastkowymi, szybciej diagnozują te połączenia.

Co definiuje ASCII

Oryginalny amerykański standardowy kod wymiany informacji (American Standard Code for Information Interchange) to siedmiobitowy zestaw znaków. Definiuje 128 wartości o numerach od 0 do 127. Wartości od 0 do 31 oraz 127 to znaki sterujące. Wartości od 32 do 126 to znaki drukowalne, w tym litery, cyfry, znaki interpunkcyjne i spacja.

Specyfikacja RFC 20 hostowana przez IETF dokumentuje pozycje kodów i ich zamierzone znaczenia. Współczesne systemy zwykle przechowują znak ASCII w ośmiobitowym bajcie. Najstarszy bit pozostaje wyzerowany dla standardowego ASCII.

Dziesiętny, szesnastkowy i binarny to ten sam bajt

Tag PLC może wyświetlać tę samą wartość w kilku formatach liczbowych. Wielka litera A to dziesiętnie 65, szesnastkowo 41, a binarnie 01000001. Cyfra 0 to dziesiętnie 48 lub szesnastkowo 30. Nie są to różne znaki. To różne przedstawienia tego samego wzorca liczbowego.

Zapis szesnastkowy jest przydatny podczas uruchamiania, ponieważ jeden bajt mieści się w dwóch cyfrach szesnastkowych. Rejestratory pakietów, monitory portów szeregowych i instrukcje obsługi urządzeń również zwykle przedstawiają wartości bajtów w systemie szesnastkowym. Zapis dziesiętny jest często wygodniejszy, gdy instrukcje PLC wymagają stałych całkowitych.

Kody sterujące mają znaczenie w komunikatach przemysłowych

Wiele protokołów szeregowych używa znaków sterujących jako ograniczników. Powrót karetki to dziesiętnie 13 lub szesnastkowo 0D. Wysuw wiersza to dziesiętnie 10 lub szesnastkowo 0A. Początek tekstu to szesnastkowo 02, a koniec tekstu to szesnastkowo 03. Urządzenie może zignorować prawidłowe polecenie, jeśli brakuje wymaganego terminatora.

Nie zakładaj, że każde urządzenie używa CR/LF. Niektóre wymagają wyłącznie CR. Inne używają drukowalnego ogranicznika, stałej długości komunikatu lub bajtu sumy kontrolnej. Potwierdź dokładną ramkę w instrukcji protokołu producenta.

Jak łańcuchy znaków PLC stają się tablicami bajtów

Platformy PLC przechowują łańcuchy znaków w różny sposób. Niektóre umieszczają bieżącą długość przed danymi znakowymi. Inne rezerwują tablicę o stałym rozmiarze i kończą tekst bajtem o wartości zero. Gdy dane przekraczają granicę protokołu, urządzenie odbierające widzi bajty, a nie wewnętrzny typ łańcucha znaków sterownika.

Sprawdź zarówno zadeklarowaną długość łańcucha, jak i bazowy bufor. Nieaktualny bajt znajdujący się poza bieżącą długością może pojawić się w przesyłanych danych, jeśli procedura wysyła cały bufor. Wyczyść miejsce docelowe albo przesyłaj tylko aktywną liczbę znaków.

Praktyczna metoda diagnostyczna

1. Zarejestruj dokładne przesyłane bajty za pomocą monitora portu szeregowego, analizatora protokołów lub strony diagnostycznej bramki.
2. Zapisz każdy bajt w systemie szesnastkowym i przypisz wartości drukowalne z powrotem do znaków.
3. Oznacz bajty ramki, terminatory, separatory, pola długości i sumy kontrolne.
4. Porównaj przechwycone dane z instrukcją urządzenia, uwzględniając spacje i wielkość liter.
5. Powtórz przechwytywanie dla znanego poprawnego komunikatu i porównaj pozycje bajtów.

Takie podejście na poziomie bajtów pozwala oddzielić błędy formatowania od problemów z okablowaniem, szybkością transmisji i parzystością. Jeśli przechwycone dane pokazują czytelny, ale niekompletny tekst, skup się na składaniu łańcucha. Jeśli każdy bajt jest nieprawidłowy, najpierw sprawdź ustawienia fizyczne i szeregowe.

Typowe błędy implementacyjne

Mylenie cyfry z jej wartością liczbową

Znak „5” ma w ASCII wartość dziesiętną 53, a nie wartość całkowitą 5. Konwersja zmierzonej liczby na tekst wymaga procedury formatowania. Skopiowanie surowej liczby całkowitej do bufora znakowego wstawia zamiast tego bajt sterujący.

Mieszanie tekstu szesnastkowego z bajtami binarnymi

Tekst „41” zawiera dwa znaki: szesnastkowo 34 i szesnastkowo 31. Pojedynczy bajt o wartości szesnastkowej 41 oznacza literę A. Ustal, czy protokół wymaga czytelnego dla człowieka tekstu szesnastkowego, czy surowych danych binarnych.

Ignorowanie kodowania wykraczającego poza ASCII

ASCII obejmuje litery angielskie i ograniczony zestaw symboli. UTF-8 używa tych samych wartości bajtów dla pierwszych 128 znaków, ale znaki spoza ASCII zajmują wiele bajtów. Starsze urządzenie może odrzucać takie bajty lub błędnie je zliczać.

Wskazówki projektowe dotyczące łatwego utrzymania kodu PLC

Umieść formatowanie protokołu w jednej procedurze. Nadaj stałym kodów sterujących nazwy zamiast rozrzucać literały liczbowe po logice drabinkowej lub tekście strukturalnym. Podczas uruchamiania rejestruj końcowy bufor nadawczy w systemie szesnastkowym. Dołącz przykłady do dokumentacji projektu.

Gdy protokół wykracza poza proste ramkowanie tekstu, użyj zdefiniowanej maszyny stanów. Śledź osobno pozycję odbioru, limit czasu, stan ramki i wynik walidacji. Ułatwia to diagnozowanie ponowień i nieprawidłowych komunikatów.

Więcej informacji o wzorcach obsługi danych znajdziesz w artykule przechodzenie przez tablice w systemach PLC. W przypadku urządzeń sieciowych przewodnik dotyczący wdrażania urządzenia Modbus TCP zawiera dodatkowy kontekst dotyczący ramek i uruchamiania.

Lista kontrolna uruchamiania

• Potwierdź zestaw znaków i kolejność bajtów.
• Sprawdź ograniczniki i terminatory w systemie szesnastkowym.
• Ustal, czy komunikat ma stałą długość, czy długość poprzedzoną prefiksem.
• Odróżnij drukowalny tekst szesnastkowy od surowych danych binarnych.
• Zweryfikuj działanie limitu czasu, ponowień i czyszczenia bufora.
• Zarchiwizuj przechwycone bajty znanego poprawnego komunikatu wraz z plikami projektu.

ASCII jest proste, ale awarie przemysłowe często kryją się w jednym brakującym lub błędnie odczytanym bajcie. Najpierw traktuj komunikat jako sekwencję wartości liczbowych. Konwertuj go z powrotem na tekst dopiero po zrozumieniu ramki.