Практика: найти ошибку Modbus RTU

Задача: выяснить, какие запросы ведущий отправляет устройству и что устройство отвечает. Ниже адрес 7 и диапазон 100–109 — учебные значения. Замените их значениями своей записи.

Почему обычного вывода байтов недостаточно

В CANopen анализатор получает отдельные CAN-кадры. При чтении обычного COM-порта он получает поток байтов: границы операций чтения не обязаны совпадать с границами RTU-сообщений. Если терминал не учитывает паузы и структуру протокола, в его выводе несколько сообщений могут сливаться, а одно сообщение — распадаться на несколько строк.

Tracer восстанавливает сообщения с учётом структуры, длины, CRC и ожидания недостающих данных. Поэтому фильтры ниже применяются к разобранным записям: modbus.unitId обозначает адрес устройства в сообщении, а не произвольный байт с таким же значением.

Пауза между порциями данных в Windows не является точным измерением паузы на RS-485: на неё влияют буферы адаптера и драйвера. Для проверки физических интервалов между байтами нужны аппаратные временные метки или захват линии подходящим измерительным оборудованием.

Подготовьте данные

Выберите Industry → Modbus RTU. Загрузите .ptrbs или подключите источник, на котором уже есть обмен. Для пассивного наблюдения нужны видимые запросы и ответы, а параметры последовательной линии должны соответствовать фактическим.

Открытие Tracer или Monitor не создаёт опрос. Для этого сценария запросы уже отправляет ведущий системы. Не подключайте дополнительного активного ведущего только ради просмотра трассы.

1. Оставьте устройство

modbus.unitId == 7

Ожидаемый результат: корректно разобранные сообщения адреса 7. Если строк нет, очистите фильтр и проверьте, какие адреса и функции вообще видны.

2. Посмотрите чтение регистров

modbus.unitId == 7 and modbus.function == 0x03

Ожидаемый результат: запросы чтения, обычные ответы и распознанные исключения для функции 0x03. Сравните время и последовательность. Столбец Response time заполняется там, где удалось сопоставить обмен.

3. Проверьте диапазон запроса

modbus.unitId == 7 and modbus.request == true and modbus.function == 0x03 and modbus.startAddress == 100 and modbus.quantity == 10

Ожидаемый результат: запросы диапазона 100–109 с отсчётом от нуля. Если инструкция устройства использует номера вроде 40101, сначала проверьте их соответствие адресу протокола.

Ответ чтения не содержит startAddress. Для его просмотра вернитесь к выражению шага 2: фильтр диапазона не переносит условия на соседний ответ.

4. Отделите исключения от повреждённых записей

Исключения устройства:

modbus.unitId == 7 and modbus.exception == true

Проверьте modbus.exceptionCode и содержание запроса. Например, код 0x02 означает недопустимый адрес данных, а не отсутствие устройства на линии.

Проверка качества разбора всей записи:

modbus.valid == false

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

Если ответа нет, отдельной строки «отсутствующий ответ» фильтр не создаёт. Анализируйте исходный запрос, последующие события и границы записи. Широковещательный запрос к адресу 0 ответа не предполагает.

5. Посмотрите Monitor

На поступающем или воспроизводимом потоке откройте Monitor. Найдите адрес 7, функцию 03 и диапазон. Сопоставьте Observed value, Observed period, Status и Last activity.

Ожидаемый результат: сводка наблюдаемой операции. Значения появятся после сопоставленного ответа. Stale означает давность наблюдения, а не установленную причину отказа. Изменение диапазона запросов может создать другую строку — это отдельная операция.

6. Сохраните результат

В Tracer поставьте метку на интересующем сообщении и сохраните .ptrbs. Запишите выражение фильтра и ожидаемый ответ. Файл сохранит и сообщения, скрытые текущим фильтром, поэтому коллега сможет повторить разбор с другими условиями.

Справка: поля Modbus RTU, Monitor, файлы трасс.