ASCII для данных ПЛК: десятичные, шестнадцатеричные коды и управляющие коды

Узнайте, как символы ASCII, десятичные значения, шестнадцатеричные байты и управляющие коды представлены в строках ПЛК и последовательных сообщениях, используя практический метод диагностики ошибок...

1 октябрь 2026 г.

ASCII по-прежнему широко используется в проектах на ПЛК, поскольку многие промышленные устройства обмениваются текстом побайтно. Считыватели штрихкодов, принтеры этикеток, весы, приводы, последовательные шлюзы и терминалы оператора часто представляют команды и измерения в виде кодов символов. Инженеры, умеющие преобразовывать символы в десятичные значения и шестнадцатеричные байты и обратно, быстрее диагностируют такие соединения.

Что определяет ASCII

Исходный американский стандартный код для обмена информацией (ASCII) представляет собой семибитный набор символов. Он определяет 128 значений с номерами от 0 до 127. Значения от 0 до 31 и значение 127 являются управляющими символами. Значения от 32 до 126 - печатные символы, включая буквы, цифры, знаки пунктуации и пробел.

Спецификация RFC 20, размещённая IETF, документирует позиции кодов и их назначение. Современные системы обычно хранят символ ASCII в восьмибитном байте. Старший бит для стандартного ASCII остаётся равным нулю.

Десятичная, шестнадцатеричная и двоичная формы - это один и тот же байт

Тег ПЛК может отображать одно и то же значение в нескольких числовых форматах. Заглавная буква A - это 65 в десятичной системе, 41 в шестнадцатеричной и 01000001 в двоичной. Цифра 0 - это 48 в десятичной системе или 30 в шестнадцатеричной. Это не разные символы, а разные представления одного и того же числового шаблона.

Шестнадцатеричная система удобна при вводе в эксплуатацию, поскольку один байт помещается в две шестнадцатеричные цифры. Захваты пакетов, мониторы последовательного интерфейса и руководства по устройствам также обычно показывают значения байтов в шестнадцатеричном виде. Десятичный формат часто удобнее, когда инструкции ПЛК ожидают целочисленные константы.

Управляющие коды важны в промышленных сообщениях

Многие последовательные протоколы используют управляющие символы в качестве разделителей. Возврат каретки - это 13 в десятичной системе или 0D в шестнадцатеричной. Перевод строки - это 10 в десятичной системе или 0A в шестнадцатеричной. Начало текста - 02 в шестнадцатеричной системе, а конец текста - 03. Устройство может проигнорировать корректную команду, если отсутствует необходимый завершающий символ.

Не следует считать, что каждое устройство использует CR/LF. Некоторым нужен только CR. Другие используют печатный разделитель, фиксированную длину сообщения или байт контрольной суммы. Проверьте точный формат кадра в руководстве производителя по протоколу.

Как строки ПЛК превращаются в массивы байтов

Платформы ПЛК хранят строки по-разному. Некоторые помещают текущую длину перед данными символов. Другие резервируют массив фиксированного размера и завершают текст нулевым байтом. При передаче данных через границу протокола принимающее устройство видит байты, а не внутренний тип строки контроллера.

Проверьте как объявленную длину строки, так и базовый буфер. Неактуальный байт после текущей длины может попасть в передаваемые данные, если процедура отправляет весь буфер. Очистите целевой буфер или передавайте только количество активных символов.

Практический метод диагностики

Зафиксируйте точно переданные байты с помощью монитора последовательного интерфейса, анализатора протокола или диагностической страницы шлюза.
Запишите каждый байт в шестнадцатеричном виде и сопоставьте печатные значения с символами.
Отметьте байты кадрирования, завершающие символы, разделители, поля длины и контрольные суммы.
Сравните захваченные данные с руководством по устройству, включая пробелы и регистр букв.
Повторите захват для заведомо корректного сообщения и сравните позиции байтов.

Такой побайтовый подход позволяет отделить ошибки форматирования от проблем с проводкой, скоростью передачи и чётностью. Если в захвате виден читаемый, но неполный текст, сосредоточьтесь на формировании строки. Если каждый байт неверен, сначала проверьте физические и последовательные настройки.

Распространённые ошибки реализации

Путаница между цифрой и её числовым значением

Символ «5» имеет код ASCII 53 в десятичной системе, а не целочисленное значение 5. Для преобразования измеренного числа в текст требуется процедура форматирования. Копирование исходного целого числа в буфер символов вместо этого создаёт управляющий байт.

Смешение шестнадцатеричного текста с двоичными байтами

Текст «41» содержит два символа: 34 и 31 в шестнадцатеричной системе. Один байт со значением 41 в шестнадцатеричной системе представляет букву A. Определите, ожидает ли протокол читаемый человеком шестнадцатеричный текст или необработанные двоичные данные.

Игнорирование кодировок, выходящих за пределы ASCII

ASCII охватывает английские буквы и ограниченный набор символов. UTF-8 использует те же значения байтов для первых 128 символов, но не-ASCII-символы занимают несколько байтов. Устаревшее устройство может отклонять такие байты или неправильно подсчитывать их.

Контрольный список для ввода в эксплуатацию

Подтвердите кодировку символов и порядок байтов.
Проверьте разделители и завершающие символы в шестнадцатеричном виде.
Уточните, имеет ли сообщение фиксированную длину или содержит длину в начале.
Отличайте печатный шестнадцатеричный текст от необработанных двоичных данных.
Проверьте поведение тайм-аутов, повторных попыток и очистки буфера.
Сохраните захват заведомо корректного обмена байтами вместе с файлами проекта.

ASCII прост, но промышленные сбои часто скрываются в одном пропущенном или неправильно интерпретированном байте. Сначала рассматривайте сообщение как последовательность числовых значений. Преобразуйте его обратно в текст только после того, как структура кадра станет понятной.