Modbus Exception Busy / Gateway Path Unavailable: кто тормозит опрос
Коды Modbus exception 0x06, 0x0A и 0x0B: кто тормозит опрос - slave или шлюз, очередь команд, частота scan и отличие от timeout.
В журнале драйвера SCADA не timeout и не «connection refused», а Modbus Exception: function code с старшим битом, exception code 06 - Slave Device Busy. Через минуту на другом канале 0x0A - Gateway Path Unavailable, хотя ping до шлюза есть. Оператор видит Bad quality на части тегов, Poll на один регистр в это же время показывает OK. Наладчик крутит timeout с 300 до 3000 ms - не помогает: slave отвечает «занят», а не «молчу».
Exception response - это ответ по протоколу. Устройство приняло запрос и отказало по правила Modbus. Это другая диагностика, чем timeout (ответа нет) и чем Bad quality без exception (драйвер сам пометил точку). Статья разбирает коды 0x06 (Busy), 0x0A (Gateway Path Unavailable), 0x0B (Gateway Target Device Failed to Respond): шлюз vs конечный slave, частота опроса, очередь команд. Не повторяем базовый урок Modbus и не сводим всё к «увеличьте timeout».
Короткий ответ
Exception 0x06 (Slave Device Busy) - конечный slave (или единственный узел на линии) занят: длинная операция в ПЛК, запись во flash, переполнена очередь Modbus server, слишком частый опрос несколькими master. Лечится снижением частоты опроса, группировкой регистров, разнесением master, повышением приоритета Modbus task на slave - не бесконечным timeout.
0x0A (Gateway Path Unavailable) - шлюз Modbus (RTU-TCP, serial server) не может достучаться до downstream шины: порт занят, неверный routing, шлюз в reset, обрыв RS-485, неверный Unit ID на внутренней стороне.
0x0B (Gateway Target Device Failed to Respond) - шлюз дошёл до шины, но целевой slave не ответил в окно шлюза (offline, wrong ID, коллизия, слишком короткий gateway timeout).
В Wireshark exception виден в поле Exception Code ответа. Сравните trace master-shлюз и шлюз-RS-485. Отличие от timeout: кадр ответа есть, FC | 0x80.
Как читать exception в кадре Modbus
Запрос: Unit ID, Function Code (например 03), адрес, quantity. Нормальный ответ: тот же Unit ID, тот же FC, данные. Exception: Unit ID тот же, Function Code = запрошенный + 0x80 (03 → 83), один байт exception code.
Распространённые коды для интегратора: 0x01 Illegal Function и 0x02 Illegal Data Address отвечает slave при неверной функции или адресе; 0x04 Slave Device Failure - внутренняя ошибка узла. Статья фокусируется на 0x06 Slave Device Busy (отвечает slave, реже шлюз), 0x0A Gateway Path Unavailable и 0x0B Gateway Target Device Failed to Respond (оба от шлюза). Эти три кода чаще всего маскируются под «связь плохая» при живом TCP к шлюзу.
Драйвер SCADA может маппить exception в Bad quality с subcode «device busy» или «gateway error» - смотрите документацию драйвера, не только красный индикатор.
0x06 Slave Device Busy: slave жив, но не готов
ПЛК принял TCP/RTU кадр, Modbus server task поставил запрос в очередь, но application ещё обрабатывает предыдущий блок записи, выполняет backup, обслуживает другой порт или cycle load 95 %. Ответ Busy - «подождите и повторите», не «адрес неверный».
Типичные виновники:
- Scan rate SCADA выше, чем slave успевает (200 одиночных FC3 в секунду на слабом CPU).
- Два master: SCADA + HMI + Poll на одной RS-485.
- FC16 массовая запись рецепта параллельно с циклическим FC3.
- Приоритет задачи Modbus ниже motion/PID на том же CPU.
- Serial server агрегирует несколько TCP-клиентов в один RTU поток - очередь на стороне ПЛК переполняется.
Что менять: снизить RPS (запросов в секунду), включить block read, убрать лишних master, на slave увеличить буфер server (если настраивается), retry с backoff в драйвере (2-3 попытки с паузой 50-200 ms), а не timeout 10 с.
Timeout при Busy бесполезен: ответ приходит за 5 ms с кодом 06. Увеличение timeout не снижает частоту Busy.
Отличие от 0x04 Device Failure: Failure - внутренняя ошибка slave; Busy - временная перегрузка. На тренде Busy часто пачками при пике цикла ПЛК.
Подробнее про нагрузку опроса и таймауты на объекте - Modbus RTU vs TCP: стабильная связь; здесь акцент на exception, а не на расчёт ms с нуля.
0x0A Gateway Path Unavailable: проблема до целевого slave
Отвечает шлюз (Modbus TCP → RTU, роутер serial, некоторые PLC в режиме gateway). Значение: шлюз не может открыть путь к downstream сегменту - порт RS-485 занят другой сессией, шлюз в диагностике, не сконфигурирован virtual serial, обрыв трансивера, неверный baud на downstream.
Симптомы:
- Ping и TCP connect к шлюзу OK.
- Любой Unit ID на downstream даёт 0x0A, не только один прибор.
- После перезагрузки шлюза 2-3 минуты тишина, потом снова 0x0A.
Диагностика:
- Захват на LAN стороне шлюза (exception 0x0A в ответе TCP).
- Захват или LED на RS-485 стороне - уходит ли запрос вообще.
- Проверить single client policy шлюза: второй TCP master блокирует path.
- Логи шлюза (buffer overflow, port busy).
Менять: не SCADA timeout, а максимум одна активная TCP-сессия на serial port, inter-frame delay, перезагрузка с проверкой конфигурации, замена кабеля RS-485 при 0x0A + 0x0B попеременно.
0x0A не лечится «правильным Unit ID» на TCP стороне, если path физически недоступен.
0x0B Gateway Target Failed to Respond: шлюз стучался, slave молчит
Шлюз отправил RTU кадр на шину, в своё внутреннее окно (gateway timeout, часто 200-500 ms жёстко) не получил ответ и вернул 0x0B master’у. Причины на downstream:
- Неверный Unit ID на RS-485 (шлюз маршрутизирует на id 5, прибор на 1).
- Slave offline, питание, A/B перепутаны.
- Коллизия и потеря кадра на RS-485.
- Slave отвечает медленнее, чем gateway timeout, хотя SCADA timeout большой (SCADA ждёт шлюз, шлюз уже сдался).
- Слишком много устройств, нет терминатора, отражения.
Классическая ловушка: SCADA timeout 2000 ms, gateway internal 300 ms. Slave отвечает за 400 ms. SCADA видит 0x0B, Poll с ноутбука напрямую на RS-485 с 1000 ms - OK. Виноват не «медленный ПЛК», а короткое окно шлюза.
Решение: увеличить gateway response timeout в веб-интерфейсе шлюза, снизить опрос, починить RS-485, исправить id map.
Разница 0x0A vs 0x0B: 0x0A - path недоступен на уровне шлюза (порт, конфиг); 0x0B - path есть, целевой узел не ответил вовремя.
Шлюз vs slave: кто тормозит опрос
На архитектуре «SCADA → Modbus TCP → serial server → RS-485 → 10 ПЛК» три узла принятия решений. Busy 0x06 чаще от конечного ПЛК, если TCP терминируется на нём же. 0x0A/0x0B - от serial server, даже если SCADA думает, что говорит с «одним устройством».
Проверка за 15 минут:
- Подключить Poll напрямую к RS-485 (минуя шлюз) с тем же Unit ID. Нет exception - копать шлюз и тайминги. Есть Busy - копать slave и scan rate.
- Один запрос через шлюз в Poll. Exception 0x0B при прямом OK - gateway timeout или mapping.
- Два TCP клиента: включить второй - появился 0x0A - политика single session.
Modbus TCP для интегратора разбирает Unit ID и транзакции; добавьте к чек-листу колонку «exception code».
Частота опроса и очередь команд
Modbus не гарантирует параллелизм на одном serial порту. Запросы выстраиваются в очередь: на master (драйвер SCADA), на шлюзе (TCP→RTU), на slave (server queue). Переполнение - Busy или дроп на шлюзе.
Практические цифры ориентира (зависят от железа): слабый PLC slave комфортно держит 20-50 транзакций/с с grouped read; 200 одиночных FC3/с - путь к 0x06. Шлюз с одним UART на 38400 бод физически не переварит 100 транзакций/с независимо от timeout SCADA.
Очередь записей (FC6/FC16) приоритетнее для slave, чем циклический опрос - во время записи рецепта опрос holding registers может сыпать Busy. Разнесите write в ручной режим оператора и снизьте scan на время загрузки рецепта.
Несколько Unit ID через один шлюз - суммарный budget времени на шину. Оптимизация одного id не спасает, если соседний id забирает 80 % окна.
Exception vs timeout vs Bad quality без exception
Timeout - master не получил Modbus PDU в свой deadline. В trace нет response PDU или только TCP retransmit.
Exception - response PDU есть, FC с 0x80, один байт кода. Связь «работает».
Bad quality без exception - драйвер отбросил ответ (CRC на RTU через шлюз, length mismatch, stale buffer), или quality stale при пропуске цикла без ошибки протокола.
Сценарий: SCADA Bad, Wireshark на TCP - exception 06. Чинить scan, не кабель Ethernet.
Сценарий: SCADA Bad timeout, Wireshark - silence. Чинить сеть, firewall, serial.
Сценарий: Poll OK, SCADA Bad без exception - см. разбор Poll vs SCADA; не путать с Busy.
Диагностика в Wireshark и журнале драйвера
Фильтр modbus.func_code == 131 (83 dec) для exception на FC3. Поле modbus.exception_code == 6 (или 10, 11). Сопоставьте timestamp с пиком CPU на ПЛК или с записью в журнал шлюза.
Захват 15 минут на объекте даёт статистику: доля 06 от всех ответов. Если >5 % - системная перегрузка опроса, не «плавающая помеха».
На RTU-over-TCP смотрите оба уровня: TCP stream и dissector Modbus RTU внутри payload - exception может идти от шлюза без физического RS-485 кадра наружу (эмуляция).
Синхронизируйте часы SCADA и ноутбука с trace.
Три режима связи и где ждать 0x0A
В трёх режимах Modbus RTU-over-TCP максимально похож на «шлюз в кабеле»: каждый TCP connect может иметь свой virtual COM. Политики serial server критичны. Чистый Modbus TCP до ПЛК с Ethernet - 0x06 на стороне CPU, 0x0A реже (если ПЛК не gateway).
Код exception, типичный виновник, что менять
| Код exception | Типичный виновник | Что менять |
|---|---|---|
| 0x06 Busy | Перегрузка Modbus server на ПЛК, частый scan | Block read, снизить scan rate, один master, retry с паузой |
| 0x06 Busy | Параллельная FC16 запись | Сериализовать write, пауза опроса на время рецепта |
| 0x06 Busy | Два TCP клиента на один slave порт | Отключить лишний master |
| 0x0A Gateway Path | Serial port занят второй сессией | Одна TCP-сессия на порт шлюза |
| 0x0A Gateway Path | Шлюз misconfig / reboot | Проверить mapping, прошивку, питание RS-485 трансивера |
| 0x0B Target fail | Gateway timeout < RTT slave | Увеличить gateway timeout до 2× RTT downstream |
| 0x0B Target fail | Неверный Unit ID в map шлюза | Сверить id с Poll на шине |
| 0x0B Target fail | RS-485 физика, терминатор | Осциллограф, terminators, bias |
| 0x06 + 0x0B попеременно | Перегрузка шины + слабый slave | Комплекс: scan + шлюз timeout + физика |
| Exception есть, SCADA «timeout» | Драйвер не обрабатывает exception | Включить exception handling, не только timeout |
Типовые ошибки
Крутить только SCADA timeout. При 06 и 0x0B через шлюз timeout master часто уже достаточен.
Считать exception «ошибкой адреса». Это 02, не 06.
Два master «на минуту для теста». Busy на весь сменный день.
Игнорировать gateway timeout. SCADA 5 с, шлюз 200 ms - вечный 0x0B.
Группировать регистры без проверки slave max quantity. Иногда 04 Failure, но на старых устройствах - Busy при разборе.
Вопросы с объекта
Нужно ли retry на 0x06?
Да, 2-3 раза с 50-100 ms jitter. Бесконечный retry забивает шину.
0x0A после грозы - норма?
Проверить шлюз и surge на RS-485. Может быть hung port до power cycle.
Busy только ночью?
Архив, backup, IT scan - коррелируйте по времени.
Exception на write, read OK?
Slave блокирует область памяти на запись - норма для некоторых счётчиков.
Modbus TCP до ПЛК, нужен ли шлюз в диагностике?
Нет, если нет gateway в цепи. 0x0A/0x0B тогда смотрите на встроенный gateway модуль, если есть.
На практике
ПЛК и панели СТАБУР в поле часто опрашиваются по Modbus TCP или через RS-485 модули PSV; при интеграции в SCADA закладывайте grouped read и лимит RPS до стенда. CODESYS и MasterSCADA на одном контроллере - взаимозаменяемые среды; параметры exception и retry настраиваются в драйвере среды, поведение slave на шине одинаково.