Modbus Poll подключается к IP шлюза, индикатор зелёный, регистры читаются без ошибок. Только температура в теге SCADA показывает 3276,7 °C, а расход с соседнего счётчика вообще нулевой, хотя на местном дисплее прибора всё в норме. Инженер открывает карту регистров в проекте - адреса совпадают с паспортом. Через час выясняется: шлюз работает не в том режиме, Unit ID в TCP-кадре не тот, а на RS-485 висит ещё три slave, и «прозрачный» сервер отдаёт ответ не от того устройства.
Serial server (конвертер Ethernet - RS-485) часто настраивают как «просто проброс порта 502». На объекте этого мало: нужно понимать bridge против mapping, как шлюз подставляет Unit ID и что происходит, когда на одной шине несколько Modbus RTU slave. Статья разбирает типовые ошибки и пошаговую диагностику. Здесь нет базового курса Modbus и разбора таймаутов RS-485 - это в отдельных материалах. Фокус - почему TCP-сессия «живая», а данные чужие или смещённые.
Modbus RTU-over-TCP - это не Modbus TCP: в TCP-потоке идут RTU-кадры (CRC, без MBAP-заголовка TCP-варианта). Serial server может работать в режиме прозрачного моста (bridge), когда master сам задаёт Unit ID и адреса, или в режиме mapping, когда шлюз хранит карту «TCP-запрос → конкретный slave и регистр». Если Poll читает holding 40001, а шлюз в mapping отдаёт input 30001 другого slave, связь формально OK, данные - мусор. Проверьте: режим шлюза, Unit ID в запросе (должен совпадать с адресом slave на RS-485), нет ли двойной подстановки ID в master и в шлюзе, порядок байт и смещение адресации (0-based vs 1-based). На шине с несколькими slave без mapping master обязан слать правильный Unit ID в каждом RTU-кадре внутри TCP.
В режиме bridge (прозрачный сервер, serial tunnel) шлюз почти не трогает содержимое кадра: TCP-байты уходят на RS-485 как есть, ответ возвращается обратно. Master (Poll, SCADA, ПЛК) формирует полный Modbus RTU запрос, включая Unit ID. Ошибки здесь: неверный Unit ID в master, коллизия двух master на одной шине, слишком короткие паузы между кадрами, шлюз не успевает переключать направление RS-485.
В режиме mapping (Modbus gateway, «виртуальные регистры») шлюз сам опрашивает slave по RS-485 и отдаёт master «свою» таблицу. Master шлёт запрос как к одному устройству (часто Unit ID = 1), а внутри шлюз маршрутизирует на slave 3, 5, 7. Если проект SCADA составлен как для прямого опроса прибора, а шлюз ждёт другую карту - получите «чужие» числа без ошибки CRC.
На web-интерфейсе serial server режимы называются по-разному: Transparent, RFC2217, Modbus TCP to RTU, Virtual Server, Channel mapping. Перед пуском выпишите из паспорта шлюза: какой режим включён, фиксирован ли Unit ID на TCP-стороне, есть ли смещение адресов.
В Modbus RTU первый байт кадра после передачи - Unit ID (адрес slave, 1…247). В RTU-over-TCP этот байт остаётся внутри TCP-пayload; MBAP-заголовок Modbus TCP (с полем Unit Identifier) здесь не используется в чистом виде, если только шлюз или master не добавляют обёртку.
Типовая ошибка: в SCADA указан Unit ID = 1 (дефолт драйвера), на шине счётчик с адресом 4. Шлюз в bridge прокидывает запрос с ID=1, отвечает первый slave, который услышал broadcast или чужой прибор с адресом 1 - не ваш счётчик.
Вторая ошибка - двойной Unit ID: master шлёт RTU-over-TCP с ID=4, шлюз в режиме «Substitute Unit ID» переписывает на 1. Ответ приходит от другого устройства.
Третья - путаница Station ID в настройках COM-порта шлюза и Unit ID в драйвере SCADA. Некоторые шлюзы имеют «Local ID» для TCP-сессии и отдельно «Remote ID» для RS-485.
Проверка: в Modbus Poll выберите режим RTU over TCP (не Modbus TCP!), явно задайте Unit ID из таблички на дверце шкафа, прочитайте один holding, сравните с локальным дисплеем прибора. Затем Wireshark или лог шлюза - какой ID реально ушёл на RS-485.
На одном сегменте RS-485 часто висят частотник (ID=1), счётчик (ID=4), датчик (ID=7). Serial server один, TCP-порт один. В bridge master обязан чередовать опрос с разными Unit ID в каждом запросе; шлюз не «угадывает» slave по номеру регистра.
Если SCADA настроена как «одно устройство, 500 тегов», а за шлюзом четыре slave, без mapping в шлюзе все теги должны идти с правильным Unit ID в каждой транзакции. Некоторые драйверы SCADA при RTU-over-TCP позволяют задать ID на уровне устройства, другие - на уровне канала; ошибка в одном теге без переопределения ID ломает только часть карты - отсюда «половина данных чужая».
Mapping на шлюзе удобен, когда нужно «свернуть» несколько slave в одну TCP-точку для старого master с одним Unit ID. Тогда карта регистров живёт в конфиге шлюза, а не только в SCADA. Любое изменение адреса slave на шине требует правки и шлюза, и проекта - забытое звено даёт старые «правильные» CRC и неправильную физику.
Таймауты и пауза между опросами разных slave критичны: частотник медленно отвечает, счётчик быстрый; при агрессивном scan rate шлюз смешивает хвост предыдущего ответа с новым запросом. Симптом - плавающие значения, не всегда «чужие», но похожие на чтение чужих регистров.
Modbus TCP (native на ПЛК или Ethernet-интерфейсе прибора) использует MBAP: Transaction ID, Protocol ID, Length, Unit ID, затем PDU. RTU-over-TCP упаковывает RTU: [Unit ID][Function][Data…][CRC16], CRC считается по RTU-правилам, не TCP.
Если в Poll выбрать «Modbus TCP» к шлюзу, который ждёт RTU-over-TCP, иногда «случайно» работает часть функций - зависит от прошивки. Данные и ошибки непредсказуемы. Явно укажите тип в master.
Карта регистров в SCADA (40001, 30001, offset) описывает логику master. Карта mapping на шлюзе - второй слой. Они должны совпадать по смыслу или один слой должен быть прозрачным. Инженеры часто правят только SCADA, не открывая web-интерфейс шлюза - порт 502 открыт, связь есть, температура «не та».
Смещение адресации: в документации прибора «регистр 40001», в Poll «Address 0» с offset 40001, в шлюзе «Starting address 1». Таблица соответствия на пуске экономит смены.
На bridge обратите внимание на:
Прошивка старых serial server иногда добавляет или убирает CRC при переходе TCP↔︎RTU. Если CRC на линии RS-485 верный, а master ругается на CRC в TCP - шлюз пересчитывает или портит конец кадра.
Подробнее про три режима Modbus и где какой применяют - в материале про RTU, TCP и RTU-over-TCP. Таймауты и стабильность линии RS-485 - в статье про RTU vs TCP на реальном объекте.
ПЛК с Modbus master часто имеет отдельный блок «Serial Gateway» с фиксированным IP и портом. Unit ID задаётся в параметрах блока на каждый slave. При копировании блока забывают сменить ID - типовая ошибка тиражирования.
MasterSCADA и CODESYS драйверы Modbus различают «шлюз RTU-TCP» и «устройство TCP». Неверный выбор - Connected зелёный (TCP установлен), quality Bad или значения с другого адреса. Сверка с Modbus TCP для интегратора полезна и для RTU-over-TCP в части Unit ID и транзакций.
На пуске зафиксируйте в одной таблице: IP, TCP-порт, режим bridge/mapping, скорость RS-485, parity, stop bits, список Unit ID на шине, ссылку на web-логин шлюза. При замене шлюза «на такой же» прошивка может отличаться - дефолт mapping вместо bridge ломает SCADA без изменения IP. Распечатка карты виртуальных регистров из web-интерфейса рядом со схемой шкафа экономит часы при следующем выезде.
Если master и slave находятся в разных подсетях, serial server не решает маршрутизацию - только конвертацию протокола. TCP до шлюза должен быть установлен с обеих сторон по правилам firewall. Poll с серверной «видит» шлюз, а из цеха - нет, если ACL асимметричен; это не «чужие данные», а отсутствие данных, но после открытия порта ошибка Unit ID выглядит так же убедительно.
При нескольких TCP-клиентах (SCADA + резервный Poll + панель) serial server без очереди может чередовать ответы между клиентами. Симптом: раз в несколько секунд значение «прыгает» между двумя slave. Решение: один master на TCP-сессию, или шлюз с multi-master scheduling по паспорту.
| Симптом на master | Настройка шлюза / проекта | Проверка |
|---|---|---|
| TCP connect OK, значения «случайные» | Bridge, неверный Unit ID в master | Poll RTU-over-TCP с ID со шкафной таблички |
| Часть тегов верна, часть нулевая | Mapping только для части slave | Карта mapping vs список ID на RS-485 |
| Данные «соседнего» счётчика | Unit ID=1 по умолчанию, slave другой | Прямой опрос RS-485 каждого ID |
| После замены прибора всё «поплыло» | Старый mapping, новый адрес slave | Экспорт конфига шлюза, правка Remote ID |
| CRC error в Poll, на RS-485 чисто | Шлюз портит CRC или режим TCP vs RTU-over-TCP | Тип протокола в master, захват TCP |
| Два master, данные чередуются | Два TCP-клиента на один serial | Один клиент, очередь опроса |
| 32767 / 65535 на знаковом теге | Чтение 16-bit как unsigned | Тип данных в SCADA, word swap |
| Работало на стенде, на объекте нет | Другой режим шлюза после сброса | Default config после power cycle |
Порт 502 открыт - значит Modbus настроен?
Нет. 502 только означает, что TCP-сессия до шлюза возможна. Режим bridge/mapping, Unit ID и карта регистров - отдельно.
Можно ли на одном шлюзе смешать bridge для одного slave и mapping для других?
Зависит от модели. Часто один режим на порт. Читайте паспорт; при сомнении - один COM-порт, один режим.
Poll показывает OK, SCADA Bad - кто виноват?
Разные timeout, тип протокола (TCP vs RTU-over-TCP), Unit ID на устройстве и на теге. Сначала выровняйте Poll с SCADA построчно.
Нужен ли терминатор на RS-485 при «нормальном» TCP?
Да. Serial server не компенсирует плохую физику шины. CRC error на шлюзе иногда маскируются как «устаревшее» значение в mapping.
Как документировать для смены?
Схема: IP шлюза, порт, режим, таблица Unit ID → прибор → ключевые регистры. Без этого следующий интегратор снова откроет 502 и удивится.
На объектах с ПЛК и модулями RS-485 линейки СТАБУР serial server часто ставят между цеховой шиной и серверной VLAN. Модуль RS-485 в корзине контроллера может опрашивать ту же шину напрямую - не смешивайте два master без плана: либо шлюз один на шину, либо чёткое разделение сегментов. CODESYS и MasterSCADA на одном железе одинаково требуют явного Unit ID в проекте; «прозрачный» шлюз не снимает обязанность сверить карту с паспортом прибора.