ASCII pro data PLC: desítkové, hexadecimální a řídicí kódy

ASCII zůstává v projektech PLC běžný, protože mnoho průmyslových zařízení si vyměňuje text po jednom bajtu. Čtečky čárových kódů, tiskárny štítků, váhy, pohony, sériové brány a operátorské terminály často reprezentují příkazy a měření jako kódové znaky. Inženýři, kteří dokážou převádět mezi znaky, desítkovými hodnotami a hexadecimálními bajty, tyto komunikace odstraňují rychleji.

Co ASCII definuje

Původní American Standard Code for Information Interchange je sedmibitová znaková sada. Definuje 128 hodnot očíslovaných od 0 do 127. Hodnoty 0 až 31 a 127 jsou řídicí znaky. Hodnoty 32 až 126 jsou tisknutelné znaky včetně písmen, číslic, interpunkce a mezery.

Specifikace RFC 20 hostovaná organizací IETF dokumentuje pozice kódů a jejich zamýšlené významy. Moderní systémy obvykle ukládají znak ASCII do osmibitového bajtu. Nejvyšší bit zůstává u standardního ASCII nulový.

Desítková, hexadecimální a binární reprezentace jsou stejný bajt

Tag PLC může zobrazovat stejnou hodnotu v několika číselných formátech. Velké písmeno A je desítkově 65, hexadecimálně 41 a binárně 01000001. Číslice 0 je desítkově 48 nebo hexadecimálně 30. Nejde o různé znaky. Jsou to různé pohledy na stejný číselný vzor.

Hexadecimální zápis je užitečný při uvádění do provozu, protože jeden bajt se vejde do dvou hexadecimálních číslic. Záznamy paketů, sériové monitory a příručky zařízení také obvykle zobrazují hodnoty bajtů v hexadecimálním tvaru. Desítkový zápis je často přehlednější, když instrukce PLC očekávají celočíselné konstanty.

Řídicí kódy jsou v průmyslových zprávách důležité

Mnoho sériových protokolů používá řídicí znaky jako oddělovače. Návrat vozíku je desítkově 13 nebo hexadecimálně 0D. Posun řádku je desítkově 10 nebo hexadecimálně 0A. Začátek textu je hexadecimálně 02, zatímco konec textu je hexadecimálně 03. Zařízení může platný příkaz ignorovat, pokud chybí požadovaný ukončovací znak.

Nepředpokládejte, že každé zařízení používá CR/LF. Některá vyžadují pouze CR. Jiná používají tisknutelný oddělovač, pevnou délku zprávy nebo bajt kontrolního součtu. Přesný rámec ověřte v protokolové příručce výrobce.

Jak se řetězce PLC převádějí na pole bajtů

Platformy PLC ukládají řetězce různě. Některé umísťují aktuální délku před znaková data. Jiné vyhrazují pole pevné délky a text ukončují nulovým bajtem. Když data překročí hranici protokolu, přijímací zařízení vidí bajty, nikoli interní datový typ řetězce řídicí jednotky.

Zkontrolujte deklarovanou délku řetězce i podkladový buffer. Zastaralý bajt za aktuální délkou se může objevit v přenášených datech, pokud rutina odesílá celý buffer. Cílovou oblast vymažte nebo přenášejte pouze aktuální počet znaků.

Praktická diagnostická metoda

1. Pomocí sériového monitoru, analyzátoru protokolu nebo diagnostické stránky brány zachyťte přesně přenášené bajty.
2. Zapište každý bajt v hexadecimálním tvaru a tisknutelné hodnoty převeďte zpět na znaky.
3. Označte rámovací bajty, ukončovací znaky, oddělovače, pole délky a kontrolní součty.
4. Porovnejte záznam s příručkou zařízení včetně mezer a velikosti písmen.
5. Záznam zopakujte pro známou správnou zprávu a porovnejte pozice bajtů.

Tento přístup na úrovni bajtů oddělí chyby formátování od problémů s kabeláží, přenosovou rychlostí a paritou. Pokud záznam obsahuje čitelný, ale neúplný text, zaměřte se na sestavování řetězce. Pokud je každý bajt nesprávný, nejprve ověřte fyzické a sériové nastavení.

Časté chyby při implementaci

Záměna číslice za její číselnou hodnotu

Znak „5“ je v ASCII desítkově 53, nikoli celočíselná hodnota 5. Převod naměřeného čísla na text vyžaduje formátovací rutinu. Zkopírování surového celého čísla do znakového bufferu místo toho vytvoří řídicí bajt.

Míchání hexadecimálního textu s binárními bajty

Text „41“ obsahuje dva znaky: hexadecimálně 34 a hexadecimálně 31. Jeden bajt s hodnotou hex 41 reprezentuje písmeno A. Rozhodněte, zda protokol očekává člověkem čitelný hexadecimální text, nebo surová binární data.

Ignorování kódování mimo ASCII

ASCII pokrývá anglická písmena a omezenou sadu symbolů. UTF-8 používá pro prvních 128 znaků stejné hodnoty bajtů, ale neASCII znaky používají více bajtů. Starší zařízení mohou tyto bajty odmítnout nebo je nesprávně započítat.

Doporučení pro udržovatelný kód PLC

Formátování protokolu ponechte v jediné rutině. Pojmenujte konstanty pro řídicí kódy místo rozptylování číselných literálů po kontaktních schématech nebo strukturovaném textu. Během uvádění do provozu zaznamenávejte konečný vysílací buffer v hexadecimálním tvaru. Do projektové dokumentace zahrňte příklady.

Když protokol přeroste jednoduché textové rámování, použijte definovaný stavový automat. Samostatně sledujte pozici příjmu, časový limit, stav rámce a výsledek ověření. Díky tomu se snadněji diagnostikují opakované pokusy i chybně vytvořené zprávy.

Další vzory práce s daty najdete v článku procházení polí v systémech PLC. U síťových zařízení nabízí průvodce nasazením zařízení Modbus TCP další souvislosti k rámování a uvádění do provozu.

Kontrolní seznam pro uvádění do provozu

• Potvrďte znakovou sadu a pořadí bajtů.
• Ověřte oddělovače a ukončovací znaky v hexadecimálním tvaru.
• Zkontrolujte, zda má zpráva pevnou délku, nebo zda je její délka uvedena na začátku.
• Rozlišujte tisknutelný hexadecimální text od surových binárních dat.
• Ověřte chování časových limitů, opakovaných pokusů a mazání bufferu.
• Uložte známý správný záznam bajtů společně se soubory projektu.

ASCII je jednoduché, ale průmyslové poruchy se často skrývají v jediném chybějícím nebo nesprávně přečteném bajtu. Nejprve zprávu vnímejte jako posloupnost číselných hodnot. Na text ji převádějte až po pochopení rámce.