Отладка RS-485/RS-232 по логам обмена
Друзья, сегодня мы залезаем в ту самую "подвал" электроники, где байты бегут по проводам, а отладчик не подключить. Последовательные интерфейсы RS-232 и RS-485 живут в промышленности, встраиваемой технике, ЧПУ-станках и датчиках уже полвека, и сдаваться не собираются.
Я перебрал кучу проектов, где проблема была не в коде, а в том, "кто кому что сказал и в какой последовательности". И каждый раз спасали логи обмена. Рассказываю, как их снимать и как читать.
Теория: что мы вообще ловим
Прежде чем лезть с щупами, давайте вспомним матчасть.
RS-232 — старый добрый последовательный интерфейс. Полнодуплексный (приём и передача идут одновременно по разным линиям), с уровнями ±12В . В нуль-модемном кабеле достаточно трёх проводов: TX (передача), RX (приём), GND (земля) . Дальность — метры, скорость — до 115.2 кбит/с классика, но бывает и выше.
RS-485 — промышленный стандарт. Полудуплексный (передаём и принимаем по одной витой паре по очереди), дифференциальный сигнал, дальность — километры, скорость — до 10 Мбит/с, на линии может висеть до 32 устройств . Используется в Modbus, Profibus и прочих промышленных шинах.
Когда что-то идёт не так, мы должны увидеть, какие байты реально ушли в линию и какие байты пришли обратно. Идеально — ещё и с временными метками.
Инструментарий: чем смотреть
Выбор инструмента зависит от того, на какой стадии вы находитесь и сколько готовы потратить.
Уровень 1: Терминал с логированием (для самых простых случаев)
Если вы просто хотите увидеть, что устройство шлёт в порт, и иногда ответить ему — хватит обычного терминала.
Для экспериментов на столе подойдут: - PuTTY — классика, но для отладки протоколов не очень - Tera Term — тоже старичок - SerialTool — более продвинутый кроссплатформенный инструмент, умеет показывать байты в HEX, ASCII, бинарном виде, и эмулировать VT-100
Вот как выглядит разница: если устройство шлёт бинарный протокол типа Modbus, обычный терминал покажет кракозябры. А хороший софт — аккуратные байты :
01 03 00 00 00 02 C4 0B
Главное, что должен уметь терминал для отладки: - Показывать приём и передачу в HEX - Логировать сессию в файл - Отправлять заранее заготовленные команды
Уровень 2: Монитор последовательного порта (самый ходовой)
Когда нужно смотреть, что приложение говорит с устройством, а устройство — с приложением, нужен монитор порта. Это программа, которая "вклинивается" между драйвером COM-порта и приложением и показывает весь обмен.
Serial Port Monitor от Eltima — классика в этом жанре . Позволяет: - Видеть все данные, которыми обмениваются устройство и приложение - Отслеживать ошибки подключения - Проверять, те ли настройки порта (скорость, биты данных, чётность) использует программа
Такие мониторы незаменимы, когда у вас есть готовая SCADA-система или софт, который не показывает детали обмена, но вы подозреваете, что проблема именно в настройках связи .
Уровень 3: Аппаратные анализаторы (для полевых условий)
Если устройство уже в поле, и под рукой только ноутбук, но нужно смотреть "на проводах" — пригождаются аппаратные снифферы.
Lineeye LE-150PR / LE-200PR — пример профессиональных анализаторов : - Работают и как анализатор (с PC), и как автономный регистратор - Поддерживают RS-232 и RS-422/485 - Детектируют ошибки чётности и кадра - Ставят временные метки на каждое сообщение (до миллисекунд!) - Могут работать от батареи или USB, крепятся на DIN-рейку - Есть Wi-Fi для удалённого управления
В режиме регистратора такой анализатор можно оставить на объекте на сутки, а потом снять лог и посмотреть, что там происходит, когда никого нет .
Уровень 4: Осциллограф (когда всё плохо)
Когда протокол не работает, а почему — непонятно, и мониторы порта показывают тишину, потому что устройство вообще не отвечает, нужен осциллограф.
Современные осциллографы (Rohde & Schwarz, Keysight, Tektronix) умеют не просто показывать "моргание" на линии, а декодировать протокол : - Триггер на старт-бит, ошибку, конкретные данные - Цветная раскраска пакетов прямо на экране - Таблица декодированных сообщений - Проверка глазковой диаграммы (eye-diagram) для анализа качества сигнала
Это высший пилотаж. Сюда идут, когда подозревают физические проблемы: наводки, перекосы, неправильные уровни.
Что искать в логах
Допустим, лог у нас есть. Теперь надо понять, где проблема.
Случай 1: Устройство вообще молчит
В логах — ничего. Приложение шлёт запросы, но в мониторе порта видно только исходящий трафик, входящий — пусто.
Что проверять: - Физическое соединение: не перепутаны ли RX и TX? Для RS-232 часто бывает, что нужно сделать "кросс" (TX одного в RX другого). Для RS-485 — проверить полярность A и B. - Терминаторы: для длинных линий RS-485 нужны согласующие резисторы 120 Ом на концах. - Настройки скорости и формата: 9600 8N1 против 19200 8E1 — и устройства не слышат друг друга.
Случай 2: Устройство отвечает, но ответ битый
В логе видно, что запрос ушёл, ответ пришёл, но байты не те, что ожидались.
Что проверять: - Контрольную сумму (CRC, checksum). Частая проблема — неправильный порядок байт (little-endian против big-endian). В одном форуме обсуждали случай, когда из-за неправильной конвертации CRC данные не принимались, хотя визуально были похожи . - Размер пакета: может, устройство ждёт 8 байт, а приходит 7 — и оно "зависает" в ожидании.
Случай 3: Ошибки кадра или чётности
Если в логах анализатора или осциллографа появляются ошибки framing error или parity error — это почти всегда проблема физического уровня .
Причины: - Несовпадение скорости (самое частое) - Длинный кабель, наводки - Нет общей земли (GND) между устройствами в RS-232 - Перекосы в дифференциальной паре RS-485
Случай 4: Потерянные байты или "задвоение"
Устройство шлёт 01 03 00, а принимается 01 03 или 01 01 03 00.
Что проверять: - Буферизацию на стороне приёмника - Таймауты: иногда байты приходят, но программа не успевает их собрать в пакет и "разрезает" не там, где надо .
В хороших терминалах есть настройка "тайм-аут последнего байта" — если байты перестали приходить на N мс, считается, что пакет закончен . Это критично для Modbus, где нет специального символа конца пакета.
Как организовать логирование на долгую перспективу
В промышленных проектах часто нужно не просто отладить, а постоянно мониторить обмен. Для этого есть готовые решения.
Например, устройства Teltonika позволяют настраивать RS-485 в режим "логгера", когда они просто печатают всё, что видят на шине, в свои внутренние логи . Есть режимы: - RS-485 transmit (FMB log) mode — устройство само шлёт свой лог в порт - RS-485 receive (LLS) mode — опрос датчиков уровня топлива - TCP ASCII/Binary buffered — когда данные с шины накапливаются в буфере и отправляются на сервер при появлении связи
В таких режимах можно настроить префиксы — первые байты пакета, по которым устройство понимает, что это сообщение адресовано ему . Это позволяет отсеивать "чужой" трафик и не захламлять логи.
Практический пример: отладка Modbus RTU по RS-485
Допустим, у нас есть мастер (PLC) и несколько слейвов (датчики). Обмен нестабильный.
Шаг 1. Включаем монитор порта на компьютере, где запущена SCADA.
Шаг 2. Смотрим лог:
[14:23:45.123] TX: 01 03 00 00 00 01 84 0A
[14:23:45.456] RX: 01 03 02 02 34 B9 A2
[14:23:50.123] TX: 02 03 00 00 00 01 84 39
[14:23:50.456] RX: (timeout)
[14:23:55.123] TX: 02 03 00 00 00 01 84 39
[14:23:55.456] RX: (timeout)
Видим: устройство с адресом 1 отвечает, устройство с адресом 2 — нет.
Шаг 3. Проверяем физически. Берём осциллограф или простой светодиод с резистором, смотрим, есть ли активность на линии при опросе адреса 2.
Шаг 4. Оказывается, что у датчика №2 перепутаны A и B. Меняем провода — появляются ответы.
Шаг 5. Но ответы иногда битые. Снова смотрим лог:
[14:25:01.123] TX: 01 03 00 00 00 01 84 0A
[14:25:01.456] RX: 01 03 02 02 34 B9 A2
[14:25:02.123] TX: 02 03 00 00 00 01 84 39
[14:25:02.456] RX: 02 03 02 02 33 B8 91
[14:25:03.123] TX: 01 03 00 00 00 01 84 0A
[14:25:03.456] RX: 01 03 02 02 34 B9 A2
[14:25:04.123] TX: 02 03 00 00 00 01 84 39
[14:25:04.456] RX: 02 03 02 02 34 B9 50
Видим, что для адреса 2 иногда приходят данные от адреса 1 (значение 02 34 вместо 02 33). Это классический признак коллизии на шине или неправильной адресации.
Шаг 6. Лечим: проверяем, нет ли двух устройств с одинаковым адресом, или не "висит" ли одно устройство, зажимая линию.
Типичные грабли (мои личные)
Грабли 1: Забыть про GND в RS-232
RS-232 — это не дифференциальная передача. Напряжение считается относительно земли. Если забыть соединить GND устройств, сигнал будет "гулять", и на приёме будет шум. В логах это выглядит как случайные байты или "полубайты" .
Грабли 2: Перепутать A и B в RS-485
Вроде мелочь, но диагностируется долго. В логах — тишина, потому что устройство "слушает" не тот провод.
Грабли 3: Неправильный расчёт CRC
Особенно когда портируешь Modbus с одного контроллера на другой. CRC считается по-разному (прямой порядок байт, обратный). В логах видно, что пакет красивый, но слейв его игнорирует, потому что контрольная сумма не сходится.
Грабли 4: Таймауты в пакетном режиме
Если в терминале не настроен "тайм-аут последнего байта", то пакеты могут "склеиваться" . Для протоколов с фиксированной длиной это не критично, а для переменной — катастрофа.
Грабли 5: Логировать слишком много
Если оставить анализатор на сутки в автоматическом режиме, можно получить гигабайты логов, где 99% — нормальный рабочий обмен, и только 1% — ошибки. Нужно уметь настраивать триггеры и фильтры, чтобы ловить только аномалии .
Чек-лист для отладки
Если вы пришли на объект с проблемной RS-485/RS-232 связью, делайте по порядку:
- [ ] Проверьте распиновку кабеля (RX/TX не перепутаны, GND есть)
- [ ] Для RS-485 — проверьте полярность A/B и терминаторы
- [ ] Проверьте настройки порта: скорость, биты данных, чётность, стоп-биты
- [ ] Подключите монитор порта и посмотрите, что реально передаётся
- [ ] Проверьте контрольные суммы в пакетах
- [ ] Если пакеты есть, но ответов нет — проверьте адресацию
- [ ] Если ответы есть, но битые — проверьте тайминги и коллизии
- [ ] Если ничего не помогает — берите осциллограф и смотрите физический сигнал
Что в итоге
Отладка последовательных интерфейсов по логам обмена — это искусство, которое сводится к одному принципу: увидеть, что реально происходит на линии, а не что должно происходить по задумке.
Инструменты для этого есть на любой бюджет: от бесплатных терминалов до профессиональных анализаторов за тысячи долларов . Но самый дорогой инструмент бесполезен, если вы не умеете читать лог и видеть в нём закономерности.
Начинайте с малого: возьмите любой терминал, который показывает HEX, и поймите, что ваше устройство реально шлёт в порт. Уверен, вы удивитесь тому, что увидите.