Modbus – это тот самый протокол, который пережил десятки «убийц индустрии», потому что он прост, предсказуем и понятен даже в три часа ночи на пусконаладке. Но как только в одном проекте встречаются Modbus RTU и Modbus TCP, начинается вечная путаница: «Это же один Modbus, значит разницы почти нет?» Разница есть. И она не только в кабеле.
На бумаге Modbus RTU и Modbus TCP выглядят как "один и тот же протокол в разной упаковке". На объекте все иначе: проект может работать неделями стабильно, а потом внезапно ловить фантомные таймауты, скачки задержек и чтение "не тех" регистров.
В 90% случаев проблема не в самом Modbus. Проблема в инженерной дисциплине: адресация, карта регистров, опрос, физика линии RS-485 или архитектура Ethernet. Именно это и разделяет "собрали и забыли" от "постоянно тушим пожар".
Ниже - не теория, а прикладной разбор того, как выбрать RTU/TCP и не похоронить проект на пусконаладке.
В 90% случаев проблема не в самом Modbus. Проблема в инженерной дисциплине: адресация, карта регистров, опрос, физика линии RS-485 или архитектура Ethernet. Именно это и разделяет "собрали и забыли" от "постоянно тушим пожар".
Ниже - не теория, а прикладной разбор того, как выбрать RTU/TCP и не похоронить проект на пусконаладке.
Блок "Короткий ответ"
RTU чаще выигрывает в простых локальных шинах с предсказуемой физикой. TCP удобнее для масштабирования и распределенных объектов. Большинство сбоев появляется из-за ошибок адресации, опроса и сетевой архитектуры, а не из-за "плохого протокола".
Что такое Modbus по сути
Modbus – это протокол прикладного уровня с моделью клиент–сервер (исторически говорили “master–slave”). Клиент инициирует запрос, сервер отвечает. В Modbus нет “самопроизвольных” сообщений по инициативе устройства – почти всегда опрос.
В основе Modbus лежат две идеи:
- Адресуемые данные (регистры/входы/выходы), которые читают и пишут по номерам.
- Функциональные коды, которые говорят устройству, что сделать: прочитать регистры, записать регистр, записать несколько и т.д.
Важно: Modbus – не про семантику данных. Протокол не знает, что такое “температура” или “давление”. Он знает только “регистр 40021, 16 бит”. Всё остальное – договорённость между производителем устройства и интегратором.
Modbus RTU: кадр, тайминги и RS-485 «как оно работает в цеху»
Физика и канал
Modbus RTU почти всегда живёт поверх RS-485 (реже RS-232). Это многоточечная шина: один сегмент, несколько устройств, общая линия. Полудуплекс, терминаторы, поляризация – классика.
Как выглядит кадр RTU
RTU – двоичный формат. В запросе и ответе есть:
- Адрес устройства (1 байт)
- Функциональный код (1 байт)
- Данные (N байт)
- CRC16 (2 байта) – контроль целостности
Кадр в RTU отделяется не специальными символами, а паузой по времени: “тишина” на линии должна быть минимум 3.5 символа (в терминах времени передачи на данной скорости). Отсюда главный практический вывод: RTU очень чувствителен к таймингам, “творческим” USB-RS485 адаптерам и неправильным настройкам порта.
Адресация
В RTU адрес – это байт 1…247 (0 иногда используют как broadcast без ответа). То есть в одной шине вы физически “сопоставляете” адрес устройству.
Modbus TCP: тот же Modbus, но в упаковке TCP/IP
Физика и канал
Modbus TCP работает поверх Ethernet/IP и транспорта TCP (обычно порт 502). Это уже не общая шина, а сеть со свитчами, маршрутизацией, разными сегментами и нормальным full-duplex.
Что внутри пакета Modbus TCP
В Modbus TCP тот же PDU (функциональный код + данные), но добавляется заголовок MBAP (Modbus Application Protocol header):
- Transaction ID (2 байта) – чтобы сопоставить ответы запросам
- Protocol ID (2 байта) – обычно 0
- Length (2 байта) – длина последующей части
- Unit ID (1 байт) – “адрес устройства” внутри
И важный момент: CRC в TCP нет, потому что целостность обеспечивает Ethernet (FCS) + TCP (checksum и контроль доставки). Поэтому кадр короче и меньше “привязан” к таймингам линии.
Unit ID – зачем он вообще нужен
В чистом Modbus TCP, когда вы общаетесь с одним IP-устройством, Unit ID часто ставят 1 и забывают. Но Unit ID становится важным, когда Modbus TCP используется как “туннель” к RTU через шлюз: IP-шлюз принимает TCP-запрос, по Unit ID выбирает RTU-адрес и уже на RS-485 идёт к нужному прибору.
Общая логика данных: “coils” и “registers” без мистики
Modbus оперирует четырьмя “таблицами”:
- Coils (0xxxx) – дискретные выходы, 1 бит, read/write
- Discrete Inputs (1xxxx) – дискретные входы, 1 бит, read-only
- Input Registers (3xxxx) – входные регистры, 16 бит, read-only
- Holding Registers (4xxxx) – регистры хранения, 16 бит, read/write
В реальном кадре “0xxxx/4xxxx” не передаются – передаётся адрес смещения (обычно 0-based) и количество.
И тут родилась самая популярная ошибка: документация пишет “40001”, а устройство ждёт “адрес 0”. Или наоборот. В одном проекте это лечится таблицей соответствий и дисциплиной: фиксируете, как именно трактует адреса конкретное устройство и конкретная библиотека/SCADA.
Ключевые различия RTU vs TCP – коротко и по делу
Ниже – таблица, которую удобно держать в голове при выборе архитектуры.
Главная мысль: TCP не делает Modbus “промышленнее”. Он делает его удобнее для распределённых сетей и больших расстояний, но добавляет сетевые риски.
Производительность: почему “TCP быстрее” – не универсальная истина
Да, Ethernet 100 Мбит/с выглядит как космос по сравнению с RS-485 на 9600 бод. Но Modbus упирается не только в физическую скорость. Упирается в:
- частоту опроса и длину запросов,
- время реакции устройств,
- ограничения на количество регистров за один запрос (часто 125 регистров чтения),
- нагрузку на мастер/клиент и на сервер,
- организацию сети (в TCP).
RTU может быть “быстрым” на короткой линии с хорошей дисциплиной опроса. TCP может стать “медленным” в сети, где одновременно крутятся тяжёлые потоки, свитчи перегружены, а кто-то ещё и Wi-Fi мост поставил “временно, на испытания”.
Надёжность: почему RTU иногда живее всех живых
У RTU есть простое преимущество: физически понятный канал. Один кабель, терминаторы, скорость, чёткая диагностика осциллографом. Если линия нормальная – работает годами.
TCP хорош, когда сеть построена правильно: сегментация, QoS при необходимости, промышленное железо, отсутствие “сюрпризов” вроде бытовых роутеров в шкафу управления.
Правильный вывод: RTU – это про устойчивость на простом физическом уровне. TCP – про масштабирование при условии сетевой дисциплины.
Типовые ошибки, которые ломают проекты
1) Смешали адресацию 0-based и 1-based
Это причина “регистры читаются, но не те”. Лечится только одним способом: проверка на реальном устройстве и фиксация правила в проектной документации.
2) В RTU забыли про физику RS-485
Терминаторы не там, поляризация отсутствует, экран заземлён “как получилось”, кабель не витая пара – а потом удивление: “почему ночью ошибки CRC”. RS-485 – не магия, он любит дисциплину.
3) В TCP не учли, что сеть – это тоже система
Порт 502 блокируется, NAT портит сессии, “умный” firewall режет соединения, свитч в кольце без нормального протокола резервирования – и всё превращается в непредсказуемость.
4) Опрос построили «как попало»
Сто запросов по одному регистру хуже, чем один запрос пачкой. В обоих мирах (RTU и TCP) оптимизация опроса решает половину проблем с нагрузкой и задержками.
Как выбрать: RTU или TCP в конкретной задаче
Если говорить инженерно, выбор обычно сводится к условиям площадки:
- Один шкаф/одна линия/куча приборов рядом → RTU часто проще и дешевле.
- Распределённые объекты, длинные расстояния, несколько щитов, нужна гибкость → TCP удобнее.
- Есть приборы только с RS-485, но сеть уже Ethernet → ставите шлюз RTU↔TCP и аккуратно ведёте Unit ID.
В нормальной архитектуре часто встречается гибрид: “на местах” RTU как полевая шина, “вверх” – TCP до SCADA/серверов. Один раз упомяну нативно: в таких схемах удобно, когда контроллер/шлюз (в том числе из линейки СТАБУР) умеет и RS-485 Modbus RTU, и Ethernet Modbus TCP – тогда сбор данных и маршрутизация делаются без зоопарка внешних конвертеров.
FAQ
Почему "читается, но не то значение"?
Обычно перепутана 0-based/1-based адресация или неверно собрана карта регистров конкретного устройства.
Нужно ли всегда переходить на TCP, если есть Ethernet?
Нет. Если топология простая и локальная, RTU может быть устойчивее и дешевле в эксплуатации.
Зачем Unit ID в Modbus TCP?
Unit ID критичен при работе через шлюзы TCP-RTU, где нужно адресовать конечное устройство на RS-485.
Как снизить таймауты и "плавающие" отказы?
Оптимизировать опрос пакетами, навести порядок в карте регистров, проверить физику RS-485 или сегментацию сети для TCP.
Обычно перепутана 0-based/1-based адресация или неверно собрана карта регистров конкретного устройства.
Нужно ли всегда переходить на TCP, если есть Ethernet?
Нет. Если топология простая и локальная, RTU может быть устойчивее и дешевле в эксплуатации.
Зачем Unit ID в Modbus TCP?
Unit ID критичен при работе через шлюзы TCP-RTU, где нужно адресовать конечное устройство на RS-485.
Как снизить таймауты и "плавающие" отказы?
Оптимизировать опрос пакетами, навести порядок в карте регистров, проверить физику RS-485 или сегментацию сети для TCP.
Итог: чем они реально отличаются
Modbus RTU – компактный двоичный протокол для последовательных линий, где кадр держится на таймингах и CRC, а надёжность – на качестве RS-485.
Modbus TCP – тот же смысловой Modbus, но упакованный в TCP/IP с MBAP-заголовком, где кадры живут в сетевой логике и зависят от архитектуры Ethernet.
Если помнить, что Modbus не про “умную автоматизацию”, а про честную доставку регистров, то RTU и TCP перестают быть “религией”. Они становятся инструментами под разные условия. И тогда вместо вечного “что лучше?” появляется нормальный вопрос: что устойчивее и дешевле именно для этой площадки и этой сети.
Практически удобнее архитектуры, где оборудование поддерживает оба режима обмена - RTU и TCP. К такому оборудованию и относится ПЛК СТАБУР. Это снижает число промежуточных конвертеров и упрощает миграцию существующих узлов без полной переделки проекта.