Наладчик ставит Modbus Poll на ноутбук в шкафу: FC3, адрес 40001, интервал 1000 ms, десять минут без единой ошибки. Запускает SCADA - половина тегов Bad quality, timeout, красные индикаторы. Руководитель проекта: «Poll же работает, доработайте драйвер». Вы открываете настройки: timeout SCADA 200 ms, scan rate 50 ms на канал с двумястами тегами, групповой опрос выключен, каждый тег отдельным запросом. Poll терпеливо ждёт секунду на ответ; SCADA шлёт очередь быстрее, чем slave успевает обработать, и режет quality при первом пропуске.
Расхождение Poll vs SCADA - не «SCADA сломана» и не «Poll врёт». Это разные параметры опроса, нагрузка на CPU, группировка регистров и маппинг quality. Статья разбирает timeout, scan rate, jitter, буфер драйвера и сравнение trace. Не дублируем основы Modbus и Unit ID - они в отдельных материалах; фокус на том, почему ручной опрос стабилен, а промышленный цикл - нет.
Если Modbus Poll стабилен, а SCADA даёт Bad quality и timeout, сравните timeout (Poll обычно 500-1000 ms, SCADA часто 100-300 ms), scan rate (Poll 1 тег, SCADA сотни запросов в секунду), групповой опрос (block read в SCADA vs одиночные FC3), нагрузку CPU на slave и serial server, количество одновременных master. Увеличьте timeout SCADA до значения с запасом от измеренного RTT, включите группировку смежных регистров, снизьте scan rate канала, разнесите тяжёлые устройства по циклам. Снимите trace SCADA и Poll на Wireshark - при Bad в SCADA часто видны повторные запросы без ответа в окне timeout, хотя Poll между ними успевает получить ответ.
Modbus Poll по умолчанию опрашивает один (или несколько вручную заданных) адресов с интервалом, который вы сами поставили. Slave видит один запрос, отвечает, ждёт следующий. Нагрузка минимальна.
SCADA опрашивает всю карту тегов по циклу. Если 200 тегов = 200 отдельных транзакций FC3 по одному регистру, при scan rate 100 ms канал должен успеть 2000 транзакций в секунду - физически невозможно на RS-485 на 9600 бод и тяжело даже на Ethernet при слабом ПЛК.
Poll не моделирует production-нагрузку. Он доказывает: «этот адрес, этот id, этот FC - при human pace работает». SCADA ломается на масштабе и темпе.
Timeout в драйвере SCADA - максимальное время ожидания ответа на один запрос. Если ответ не пришёл - Bad quality, счётчик timeout++, следующий тег в очереди.
Типичные значения:
Poll при отладке: 1000-3000 ms, retry 3. SCADA «из коробки»: 200-500 ms. Serial server + RS-485 + 20 slave на шине: RTT одного запроса 50-300 ms в норме, при коллизии или медленном приборе - до 800 ms.
Правило: timeout SCADA ≥ (измеренный 95-й перцентиль RTT в Wireshark) × 2 + запас на jitter. Если Poll с 1000 ms OK, а SCADA с 200 ms Bad - первым делом поднимите timeout до 800-1000 ms на проблемном канале, не «чиня» карту.
Второй эффект: короткий timeout + retry 0 = мгновенный Bad при одном потерянном кадре на RS-485. Poll с retry переживает ту же помеху.
См. Modbus RTU vs TCP: таймауты и стабильная связь для расчёта на реальном объекте.
Scan rate задаёт, как часто драйвер начинает полный проход по тегам канала. 50 ms означает «каждые 50 ms заново опросить все теги» - не «каждый тег каждые 50 ms».
Если полный проход занимает 2 секунды (200 тегов × 10 ms на транзакцию), а scan rate 50 ms, очередь переполняется: новые циклы стартуют до завершения старых, запросы отбрасываются, timeout растёт.
Диагностика: посмотрите в SCADA фактическое время цикла канала (actual scan time, cycle load). Если оно больше заданного scan rate - снижайте rate или оптимизируйте карту.
Практика: scan rate = 1,5…2 × измеренный полный цикл после группировки. Для медленных счётчиков - отдельный канал с rate 1000-5000 ms, для быстрых ПЛК - 100-500 ms.
Poll умеет читать несколько регистров одним запросом, если вы так настроили. SCADA часто импортирует теги по одному адресу - драйвер шлёт N запросов.
Группировка (block read, optimize poll, scan groups): смежные holding registers одного slave объединяют в один FC3 с quantity > 1. Нагрузка падает в 5-20 раз.
Ограничения: slave может ограничивать max registers per request (часто 125). Нельзя склеить разные типы (input + holding). Разрыв в адресах - два блока.
После группировки Poll и SCADA всё ещё могут расходиться, если Poll читает один блок, а SCADA - три группы плюс одиночные. Сравнивайте trace на равных.
ПЛК в цикле управления может откладывать ответ Modbus slave на 100-500 ms под нагрузкой PID, связи, диагностики. Poll в «тихий» момент ловит ответ; SCADA бьёт постоянно и попадает в пики.
Симптом: Bad quality волнами, привязано к фазе цикла ПЛК или к запуску механизма. Решение: поднять timeout, снизить частоту опроса некритичных тегов, на ПЛК поднять приоритет Modbus TCP server task (если среда позволяет).
На Linux RT контроллерах фоновые службы (архив, HMI) конкурируют за CPU - тот же эффект.
Пока Poll подключён, SCADA может терять кадры на RS-485 (half-duplex) или на single-session serial server. Bad quality «когда наладчик в шкафу» - классика.
Правило пуска: при приёмке SCADA отключить все Poll, вторые SCADA, тестовые скрипты. Один master на шину.
На Modbus TCP несколько TCP-клиентов часто допустимы, но слабый ПЛК или шлюз может обслуживать только 1-2 сессии - Poll держит одну, SCADA вторую, третья - timeout.
Драйверы маппят Modbus exception, CRC error, timeout, gap в разные quality subcodes. Оператор видит красный Bad - инженер должен различать:
Timeout / comm fail - сеть или перегрузка. Exception 02 illegal address - ошибка карты, Poll на этот адрес тоже должен показать exception (если Poll настроен смотреть exception). Stale data - старый буфер при пропуске цикла.
Иногда SCADA показывает Bad, а значение на экране последнее Good - устаревшее. Poll показывает актуальное. Сравнивайте timestamp или force refresh.
Подробнее про отображение на HMI - Modbus-карта экрана и Bad quality.
Serial server между SCADA и RS-485 имеет буфер TCP и таймаут idle. Агрессивный scan SCADA заб Flooding шлюз - он дропает кадры, Poll с медленным интервалом проходит.
Проверьте: max connections, inter-frame delay на шлюзе, не включён ли «fast mode» без паузы 3,5 char times на RTU.
Буфер драйвера SCADA: при переполнении старые запросы отменяются - Bad на «хвосте» карты, начало карты Good. Симптом частичный Bad.
Синхронизируйте часы для корреляции с журналом SCADA.
MasterSCADA и CODESYS на одном железе - взаимозаменяемые среды; параметры timeout/scan настраиваются в драйвере среды, не «в Modbus». Импортированный проект мог принести scan 20 ms с другого объекта - на новом slave это убийственно.
После миграции проекта пройдите все каналы Modbus: timeout, retry, scan, группировка.
Каждый запрос SCADA = TCP + RTU + RS-485 + обратно. Poll на том же пути имеет ту же задержку, но один запрос. SCADA с сотней запросов умножает задержку на очередь. Три режима Modbus - напоминание, что RTU-TCP не прощает одиночных транзакций на тег.
Если SCADA не умеет приоритет в вашей версии драйвера, разделите каналы: PLC1_Fast с 20 тегами и scan 200 ms, PLC1_Slow со счётчиками и scan 5000 ms. Poll всегда «fast» - он не показывает, что slow-канал отвалился из-за starvation, если fast съел весь budget serial server.
На MasterSCADA 4D и в CODESYS на одном ПЛК СТАБУР логика одна: меньше транзакций, больше timeout. Среды взаимозаменяемы, параметры драйвера задаёт integrator в каждой среде отдельно.
Запретить постоянный Poll на production шине. Допустить только с согласования и с отключением дублирующего канала SCADA на время теста. Раз в квартал - контрольный trace 15 минут и сравнение счётчика timeout с baseline после пуска. Рост timeout без изменения карты - повод для осмотра RS-485, не только «перезагрузить SCADA».
Документируйте baseline: при хорошей связи timeout errors = N в сутки, cycle time = X ms. Отклонение в 10 раз - заявка в АСУ, не «оператору перезагрузить экран».
Типовой объект: энергоучёт, 200 holding registers на одном slave, scan rate 100 ms, timeout 300 ms. Poll читает register 0 - OK за 40 ms. SCADA шлёт 200 запросов × 40 ms = 8 s на цикл при scan 100 ms - систематический timeout на 80 % тегов.
Решение за один день: группировка в 4 блока по 50 регистров, timeout 1000 ms, scan rate 2000 ms для этого канала. Bad quality падает с 80 % до нуля без смены кабеля. Poll «работал» всё время - доказательство, что slave жив, не что SCADA настроена.
Зафиксируйте в отчёте заказчику: проблема была scan math, не «качество Modbus на объекте».
| Расхождение Poll/SCADA | Параметр | Рекомендуемое значение |
|---|---|---|
| Poll OK, SCADA timeout на всех тегах | Timeout SCADA слишком мал | ≥ 2× RTT, типично 800-1500 ms на RS-485 через шлюз |
| Bad на «хвосте» карты | Scan rate < время полного цикла | Scan rate = 1,5-2× actual cycle; группировка |
| Bad волнами каждые N секунд | Конкуренция CPU на slave | Timeout +100 ms; отдельный канал для медленных тегов |
| Bad только при наладчике в шкафу | Второй master (Poll) | Один master при эксплуатации |
| Poll 1 регистр OK, SCADA Bad на том же | Одиночный vs групповой не при чём; разный Unit ID | Сверить id; один trace |
| Частичный Bad, Connected | Переполнение буфера шлюза | Снизить RPS; inter-frame delay |
| Good в Poll, exception в SCADA | Разный FC или адрес в карте | Cross-check карты импорта |
| После импорта 500 тегов | Нет группировки | Scan groups по объектам |
| TCP connect OK, sporadic Bad | Retry = 0 | Retry 2-3, timeout ↑ |
| Bad ночью только | Резервное копирование / сканирование IT | ACL или VLAN; не трогать timeout днём |
Достаточно ли скопировать timeout из Poll в SCADA?
Хорошая отправная точка. Добавьте запас на полный цикл и jitter, не только один запрос.
Scan rate 50 ms - это нормально?
Нормально только если полный проход укладывается в 50 ms. Иначе - самообман.
Bad quality влияет на архив?
Обычно архивируют с меткой quality. Плохие точки портят отчёты - чинить параметры, не отключать quality.
Poll с ноутбука доказывает приёмку?
Доказывает доступность адреса. Приёмка SCADA - тест под production scan с одним master.
Группировка ломает отдельные теги?
При неверных границах блока - да. Проверьте каждый тег после группировки онлайн.