На пуске MasterSCADA 4D в дереве драйвера Modbus RTU-TCP горит зелёный Connected, счётчик опросов растёт, ошибок связи нет. Оператор смотрит на мнемосхему: все аналоги нули, дискретные ложь, quality Good. Modbus Poll с ноутбука через тот же serial server на порту 502 показывает нормальные значения с Unit ID 3. Интегратор крутит настройки станции, меняет адреса регистров - нули остаются. Через час выясняется: в драйвере SCADA прописан Unit ID 3, а шлюз в режиме bridge добавляет свой station id в кадр, и slave отвечает на другой адрес. Connected есть, потому что TCP-сессия и ответы RTU приходят - просто не от того устройства или с пустой картой.
RTU over TCP - самый коварный режим Modbus на объекте: сеть «живая», протокол «отвечает», цифры мёртвые. Статья разбирает двойной Unit ID, путаницу station id на шлюзе и station id в SCADA, карту регистров и trace опроса. Не повторяем базовый урок Modbus RTU и TCP - он в отдельных материалах; здесь фокус на связке MasterSCADA + serial server + RS-485.
Если MasterSCADA через RTU-TCP показывает Connected и нулевые теги с Good quality, чаще всего Unit ID задан дважды (в SCADA и на шлюзе) или карта регистров не совпадает с реальной адресацией slave. Проверьте: Unit ID в свойствах канала драйвера - один раз, согласованный с Poll; режим шлюза (transparent bridge vs mapping с подстановкой id); не дублируется ли id в поле «станция» и в адресе тега; byte order и тип (INT16 vs UINT16); starting address 0-based vs 1-based. Включите trace опроса драйвера или Wireshark на TCP: сравните Unit ID в запросе SCADA с рабочим запросом из Modbus Poll. Исправьте id на одном уровне, пересчитайте адреса регистров, перезапустите опрос.
В Modbus TCP Unit ID передаётся в поле MBAP и дублируется в RTU-кадре при RTU over TCP. Serial server принимает TCP, упаковывает запрос в RTU на RS-485, slave отвечает, сервер возвращает ответ в TCP. Unit ID на шине RS-485 определяет, какой прибор ответит.
Три места, где id может «сломаться»:
В проекте MasterSCADA: свойство Unit ID / Station / Slave address у канала или у каждого тега. На web-интерface serial server: режим, когда сервер сам подставляет id (fixed station, mapping table). В настройках «прозрачного» моста: id должен приходить только из master, но прошивка некоторых шлюзов по умолчанию добавляет свой.
Двойной id выглядит так: SCADA шлёт Unit ID 3, шлюз переписывает на 1 или добавляет второй байт - slave с адресом 3 молчит, отвечает устройство 1 с регистрами, которых нет в вашей карте, или с нулями в неиспользуемых адресах. TCP-сессия успешна - Connected.
Подробнее про три режима Modbus - в материале про RTU, TCP и RTU over TCP.
MasterSCADA (и любая SCADA) ставит Connected, когда драйвер получает ответы в пределах timeout без exception на уровне транспорта. Ответ Modbus exception 02 (illegal address) иногда маппится в Bad quality, но «успешный» ответ с нулевыми данными из другого диапazона регистров часто даёт Good и ноль.
Slave может быть другой: шлюз опрашивает первое устройство на шине, SCADA думает, что это насос №2. Значения «стабильные нули» - типичный признак чтения резервных или неинициализированных регистров в другом диапазоне.
Сравните один и тот же holding register в Poll и в trace SCADA: адрес, function code, Unit ID побайтно. Расхождение в одном байе id - ваша ошибка.
При добавлении канала указывают IP serial server, TCP-порт (часто 502), timeout, retry, scan rate. Unit ID задают на уровне устройства (один slave за канал) или на теге (несколько slave через один TCP - реже и требует дисциплины).
Типовые ошибки:
Unit ID 0 по умолчанию - на шине все приборы с 1..247, нули не от кого ждать. Unit ID скопирован из документации TCP-устройства, а вы на RTU-TCP через шлюз - в TCP-документе id часто 255 или 0 для single-device gateway. Два канала на один IP:port с разными id - нормально, если шлюз поддерживает; если нет - второй канал читает те же регистры, что первый.
Карта тегов: holding 40001 в документации vs address 0 в драйвере. MasterSCADA, как и CODESYS, может использовать 0-based offset. Ошибка на +1 даёт соседний регистр - часто 0.
Сверьте с Modbus TCP для интегратора - правила Unit ID и транзакций те же на уровне кадра.
Производители шлюзов RS-485/Ethernet делят режимы условно так:
Transparent / RFC2217 / raw RTU tunnel - байты из TCP уходят на шину как есть, Unit ID только из master. Virtual serial port с таблицей mapping - каждому TCP-порту или сессии привязан fixed slave id, master может слать любой id - шлюз подменит. Multi-master запрещён - один TCP-клиент, иначе коллизии на RS-485.
Если SCADA настроена на id 3, а шлюз в mapping режиме жёстко шлёт id 1 на шину, Poll с ноутбука (напрямую задаёте id 3 в программе) работает, SCADA с id 3 в драйвере получает ответы от id 1 только когда шлюз согласует - или наоборот, пустые кадры.
Откройте web-интерface шлюза, снимите скрин режима до изменений. Переключение bridge/mapping требует перезапуска - на пуске это забывают.
Несколько slave на одной RS-485: один TCP-сокет, разные Unit ID в запросах - нормальная схема для SCADA. Шлюз не должен фиксировать id, если у вас несколько приборов. Если фиксирует - второй slave в проекте SCADA никогда не оживёт.
Когда Unit ID совпал, нули остаются из-за адресации и типа данных. INT16 со знаком на счётчике энергии без знака даёт мусор, но не всегда ноль. Ноль чаще от:
Чтение input register вместо holding (function 4 vs 3). Адрес в «4xxxx» vs «3xxxx» перепутан в документации. Длина строки: читают один регистр, значение в двух (32-bit float). Byte order: Big Endian в приборе, Little Endian в драйвере - иногда даёт 0.0 при малых значениях.
В MasterSCADA проверьте свойства тега: тип, swap words, swap bytes, deadband. Включите отображение «сырого» значения в инженерном окне.
Масштаб 0..100 на регистре 0..1000: при значении 0 на поле - это может быть правда, а не ошибка. Сверьте с технологом, что на объекте реально должно быть при останове.
На объектах с Modbus RTU vs TCP: таймауты и стабильность уже разобрано, почему агрессивный scan rate даёт пропуски - здесь связь Connected, но если scan слишком частый, иногда приходят старые буферные нули. Редко, но проверьте после id.
Диагностический тег на тестовом адресе (версия прошивки slave) часто читают первым. Если он ненулевой, а технологические нули - ошибка в offsets конкретных тегов, не в Unit ID. Если все нули включая диагностику - id или не тот slave.
Добавьте временный тег на известный регистр из паспорта (serial number, firmware) - один правильный адрес снимает половину версий.
Некоторые шлюзы умеют режим «Modbus TCP server → Modbus RTU master» с таблицей преобразования регистров внутри web-интерface. SCADA подключается как к TCP-slave, шлюз сам опрашивает RS-485. Unit ID в SCADA тогда часто 255 или 0 (single connection), а реальный id на шине задаётся только в таблице шлюза. Ошибка: продублировать id и в SCADA, и в таблице - двойной адрес снова.
Если после обновления прошивки шлюза таблица преобразования сбросилась, Connected остаётся (TCP жив), регистры в SCADA читают «пустую» таблицу - нули. Экспорт конфигурации шлюза в файл после каждого изменения - часть as-built, не «настройки в браузере».
Если quality Good, а на экране проблемы отображения - это другой слой (привязка HMI, роли). При нулевых значениях с Good оператор видит ноль, не серый. Не путайте задачи. Общее: Connected обманывает, нужна сверка с Poll на том же IP.
При mixed архитектуре (часть TCP-native, часть RTU-TCP) в одном проекте не копируйте настройки канала между типами - Unit ID для TCP-native часто 255 или из MBAP-only контекста.
На пуске теги часто заливают из Excel, где адреса записаны как «40001» без пояснения 0-based. Импортёр MasterSCADA может положить 40001 как literal offset - slave отвечает exception или нулями в зависимости от прошивки шлюза. После импорта выборочно проверьте пять тегов в trace, не все двести.
Если в таблице Unit ID в отдельной колонке, а импортёр кладёт id только на первый тег группы, остальные могут унаследовать 0. Симптом: первая группа «оживает», остальные нули при одном Connected.
Зафиксируйте в акте: IP и port serial server, режим bridge/mapping, Unit ID каждого slave на шине, скрин hex-запроса Poll и hex-запроса SCADA на одном регистре (должны совпадать по id и адресу). Без этого через полгода после замены шлюза снова «Connected и нули», и некому вспомнить рабочую комбинацию.
При сдаче передайте заказчику не только IP, но и таблицу «имя тега - Unit ID - адрес - тип - byte order». Эксплуатация меняет прибор - сверяется с таблицей, не с «зелёным Connected».
На ПЛК и панелях СТАБУР Modbus RTU и Modbus TCP настраиваются и из CODESYS, и из MasterSCADA 4D - среды взаимозаменяемы. Если полевой контроллер опрашивается по RS-485 через внешний шлюз, карту тегов и Unit ID удобно вести в одном месте с HMI. После смены шлюза или прошивки serial server перепроверяйте режим bridge - «вчера работало» после обновления web-интерface шлюза часто означает сброс на mapping с id 1.
| Индикация связи | Где ошибка id/адреса | Исправление |
|---|---|---|
| Connected, все теги 0, Good | Двойной Unit ID (SCADA + шлюз) | Отключить подстановку id на шлюзе или убрать id из SCADA |
| Connected, Poll OK с id 3, SCADA id 3 - нули | 0-based vs 1-based адрес | Сдвинуть адрес на ±1, сверить с паспортом |
| Connected, exception в trace | Неверный FC или адрес | FC3/4, диапазон регистров |
| Connected, значения «замёрзли» | Второй master на RS-485 | Один опросщик, отключить Poll |
| Bad на части тегов, Connected | Разный id на тегах | Единый id на устройство или таблица шлюза |
| После замены шлюза нули | Mapping по умолчанию id 1 | Перенастроить bridge, id как на шине |
| Good, числа нереалистичны малы | Byte order / тип | Swap, UINT vs INT, float 32-bit |
| TCP OK, Poll через шлюз OK, SCADA нет | Firewall не при чём; другой IP в проекте | IP:port в канале = Poll |
| Работало до клонирования канала | Скопирован Unit ID 0 | Прописать id из as-built |
Connected гарантирует правильный Unit ID?
Нет. Гарантирует только обмен кадрами по TCP и ответы без обрыва сессии.
Можно ли задать разный Unit ID каждому тегу через один serial server?
Да, если шлюз в transparent режиме и на шине несколько slave. Нет, если шлюз фиксирует один id.
Poll и SCADA одновременно - можно?
На RS-485 один master за раз. Два TCP-клиента к одному порту шлюза часто конфликтуют. Для теста отключите опрос SCADA.
Почему quality Good при нулях?
Ответ Modbus успешен, данные нулевые. Quality отражает связь, не «правдивость» технологии.
Нужен ли restart Runtime после смены id?
После смены Unit ID или адресов - перезапуск канала или Runtime, иначе старый буфер может отдавать кэш.