В промышленной автоматике появление кода ошибки 89 на контроллерах серии ПЛК110 (в режиме Modbus Master) является распространенной ситуацией, с которой сталкиваются инженеры по вводу в эксплуатацию и сопровождению АСУ ТП. Данная статья подробно описывает суть ошибки, ее техническое обоснование, алгоритм поиска причины и методы устранения.

Официальное определение ошибки

Согласно технической документации и базам знаний производителя, ошибка 89 трактуется следующим образом:

«Переинициализация сокета в связи с превышением числа ошибок или отсутствием связи свыше таймаута».

В терминах сетевого стека контроллера это означает, что TCP/IP-сокет (или последовательный порт в режиме RTU-over-TCP), используемый для опроса ведомого устройства (Slave), был принудительно закрыт и открыт заново стеком протоколов Modbus Master.

Технический контекст: ПЛК110 и архитектура Modbus Master

Контроллеры ПЛК110 (часто используемые в составе систем автоматизации на базе или аналогичных платформ) реализуют функцию Modbus Master через встроенный Ethernet-интерфейс (порт ) или дополнительные модули расширения (RS-485/RS-232).

При работе в режиме Master контроллер инициирует транзакции (запросы) к устройствам Slave (приводам, счетчикам, контроллерам ввода-вывода). Каждая сессия обмена обычно удерживает открытое TCP-соединение (Persistent Connection) для снижения задержек.

Ключевые параметры, влияющие на ошибку 89:

• Timeout (Таймаут ответа): Максимальное время ожидания ответа от Slave после отправки запроса.
• Retry Count (Число повторных попыток): Количество повторных отправок запроса при отсутствии ответа.
• Connection Timeout / Keep-Alive: Параметры жизненного цикла TCP-сокета.
• Modbus TCP Port: Стандартный порт 502 (или пользовательский *).

Основные причины возникновения ошибки 89

Ошибка 89 — это симптом потери коммуникации, а не причина самой по себе. Причины делятся на три категории:

Физический и канальный уровень (L1/L2)

1. Проблемы с кабелем/контактами: Разрыв витой пары, плохой контакт в RJ-45, превышение длины сегмента (100 м для Cat5e), работа рядом с мощными источниками ПЭМИН без экранирования.
2. Ошибки коммутатора (Switch): Переполнение буферов свитча, ошибки автосогласования скорости/дуплекса (Auto-negotiation mismatch), настройки Storm Control, блокирующие широковещательный трафик ARP.
3. Проблемы RS-485 (если используется шлюз/модуль): Отсутствие терминирующих резисторов (120 Ом), нарушение полярности A/B, отсутствие заземления экрана кабеля.

Сетевой уровень (L3/L4)

1. IP-конфликты: Дублирование IP-адреса Slave или Master в сети.
2. Настройки Firewall/ACL: Блокировка порта 502 (или кастомного) на управляемом свитче, роутере или встроенном файрволе ПЛК (если поддерживается).
3. NAT/Маршрутизация: Некорректные маршруты, если Master и Slave находятся в разных подсетях.
4. TCP Keep-Alive / Idle Timeout: Если на свитче или роутере стоит агрессивный таймаут бездействия (например, 30 сек), а опрос ПЛК идет раз в минуту — сокет рвется по инициативе сетевого оборудования.

Уровень приложения (Modbus / ПЛК)

1. Некорректные настройки опроса в ПЛК (самое частая причина):
   • Слишком малый Timeout (например, 10-50 мс) при опросе медленных устройств или через радиоканал/VPN.
   • Слишком малое Retry Count (0 или 1).
   • Опрос несуществующих регистров (Illegal Address), вызывающий исключение Modbus (Exception Code 02), которое некоторые стеки интерпретируют как ошибку канала.
2. Перегрузка Slave-устройства: Ведомый контроллер/привод не успевает обрабатывать запросы от нескольких Master’ов или слишком частые опросы (Poll Rate < времени обработки цикла Slave).
3. Ошибка в пользовательской программе (ST/FBD/LD): Динамическое изменение параметров связи (блоки MB_MASTER, ETH_MODBUS_MASTER) в рантайме без корректной переинициализации.
4. Версия прошивки (Firmware): Известные баги ранних версий ПО ПЛК110 (например, ветка v.), где сокет не восстанавливался корректно после разрыва питания Slave. Рекомендуется обновить до v. или новее.

Алгоритм диагностики (Step-by-Step)

Шаг 1. Анализ логов и диагностического буфера ПЛК

Откройте среду программирования (например, ONI PLR Studio, CODESYS или проприетарную IDE *). Перейдите в Diagnostics -> Log / Buffer.

• Ищите записи с кодом 0x59 (89 dec).
• Зафиксируйте Timestamp (время) и Slave ID / IP Address, к которому относится ошибка.
• Проверьте счетчики: Tx Count, Rx Count, Error Count, Socket Reconnect Count.

Шаг 2. Проверка сетевой доступности (Ping / ARP)

С инженерной станции (ноутбука), подключенного к той же VLAN/подсети:

ping  -t
arp -a

Наблюдайте за потерями пакетов и временем отклика. Если пинг проходит, а Modbus нет — проблема в L4/L7.

Шаг 3. Анализ трафика (Wireshark / tcpdump) — «Золотой стандарт»

Подключитесь к порту свитча в режиме Port Mirroring (SPAN) к порту ПЛК110 (Master). Запустите захват.

На что смотреть в Wireshark (фильтр: modbus.tcp || tcp.port == 502):

• TCP 3-way Handshake: Успешен ли? Есть ли SYN Retransmission?
• Modbus Request/Response: Уходит ли запрос? Приходит ли ответ?
• TCP Retransmission / Dup ACK: Признаки потерь пакетов в канале.
• TCP RST / FIN: Кто инициирует разрыв? Master (ПЛК) или Slave? При ошибке 89 обычно видно: Master шлет RST, ACK после серии таймаутов.
• Modbus Exception Responses: Ответы с функцией 0x8x (ошибка протокола).

Шаг 4. Проверка настроек блока Modbus Master в проекте

Откройте конфигурацию канала Modbus Master для проблемного Slave:

Типовые сценарии и решения

Сценарий А: «Ошибка 89 появляется периодически, раз в несколько часов/дней»

Причина: Сетевые «глюки» (перезагрузка свитча, кратковременная потеря питания Slave, радиопомехи на радиомосте).

Решение: Увеличить Retry Count до 3-5, Timeout до 1-2 сек. Включить авто-переподключение (обычно включено по умолчанию). Добавить в программу ПЛК обработку бита ошибки канала для логирования/сигнализации, не останавливая процесс.

Сценарий Б: «Ошибка 89 постоянная (статус всегда Error), данные не обновляются»

Причина: Неверный IP/Unit ID, закрытый порт 502 на Slave, неверная маска подсети/шлюз на Master или Slave, физический разрыв линии.

Решение: Проверить пинг. Проверить настройки Slave (включен ли Modbus TCP, порт, Unit ID). Проверить настройки Master (IP Slave, Unit ID). Проверить кабель/линк (LED на порту ПЛК).

Сценарий В: «Ошибка 89 при опросе большого массива регистров (Read Holding Registers 0x03, Count > 125)»

Причина: Превышение максимального размера PDU (Protocol Data Unit) для Modbus TCP (253 байта) или лимита конкретного Slave-устройства. Slave разрывает соединение (RST) или шлет Exception 03 (Illegal Data Value), который Master трактует как фатальную ошибку сокета.

Решение: Разбить запрос на несколько мелких (по 100-120 регистров). Проверить даташит Slave на макс. количество регистров за транзакцию.

Сценарий Г: «Ошибка 89 после обновления прошивки ПЛК / Slave»

Причина: Изменение поведения стека TCP/Modbus в новой версии FW. Например, старый FW держал сокет открытым вечно, новый — закрывает по Keep-Alive таймауту.

Решение: Изучить Release Notes прошивки. Настроить TCP Keep-Alive параметры в ОС ПЛК (если доступно) или перевести канал в режим Non-persistent (открывать/закрывать сокет на каждой транзакции).

Программная обработка ошибки 89 в коде ПЛК (Best Practices)

Не полагайтесь только на автоматическую переинициализацию. Реализуйте мониторинг здоровья канала в пользовательской программе (ST пример):

VAR
 fbModbusMaster : MB_MASTER; (* Блок управления Master )
 xCommError : BOOL; ( Флаг ошибки связи )
 uiErrorCode : UINT; ( Код ошибки (89) )
 uiRetryCounter : UINT; ( Счетчик попыток восстановления )
 tReconnectDelay : TON; ( Таймер задержки перед переподключением )
END_VAR
( Вызов функционального блока *)
fbModbusMaster(
 xEnable := TRUE,
 sIPAddress := '192.168.1.', ( Маскированный IP Slave )
 uiUnitID := 1,
 uiTimeout := 1000,
 uiRetries := 3
);

( Анализ статуса )
IF fbModbusMaster.xError THEN
 uiErrorCode := fbModbusMaster.uiErrorID;
 
 IF uiErrorCode = 89 THEN
 xCommError := TRUE;
 ( Логирование в системный лог или БД *)
 LogMessage('Modbus Master Error 89: Socket Reinit. Slave IP: 192.168.1.');
 
 ( Стратегия восстановления: пауза перед следующим циклом опроса )
 tReconnectDelay(IN := TRUE, PT := T#5S);
 END_IF
ELSE
 xCommError := FALSE;
 tReconnectDelay(IN := FALSE);
END_IF

( Блокировка новых запросов во время восстановления )
IF tReconnectDelay.Q THEN
 fbModbusMaster.xEnable := FALSE; ( Принудительный сброс сокета *)
ELSE
 fbModbusMaster.xEnable := TRUE;
END_IF

Профилактика и чек-лист ввода в эксплуатацию

Для исключения ошибки 89 на стадии пусконаладочных работ (ПНР) выполните:

1. Кабельная трасса: Протестируйте кабельтестером (Certifier) на соответствие Cat5e/6. Заземлите экраны FTP/STP с одной стороны.
2. Сетевое оборудование: Отключите Green Ethernet / EEE (Energy Efficient Ethernet) на портах свитча. Настройте жестко Speed/Duplex (100M/Full или 1G/Full) на обоих концах, если автосогласование глючит.
3. Изоляция трафика: Выделите Modbus-трафик в отдельный VLAN с приоритетом QoS (DSCP 46 / CoS 5).
4. Настройки Slave: Увеличьте таймауты Modbus на стороне Slave (если настраивается). Включите «Modbus TCP Keep Alive» на Slave.
5. Настройки Master (ПЛК110): Установите адекватные Timeout (>= 500ms) и Retries (>=3). Избегайте опроса сотен регистров в одной транзакции.
6. Документирование: Зафиксируйте в журнале ПНР: IP-адреса, MAC-адреса, версии FW ПЛК (*) и Slave, скриншоты настроек Modbus Master, результаты пинг-теста за 10 минут (0% потерь).

Ошибка 89 («Переинициализация сокета…») на контроллерах ПЛК110 является индикатором нестабильности транспортного уровня (TCP) или некорректных таймингов протокола Modbus. В 90% случаев проблема устраняется настройкой параметров Timeout и Retry Count в конфигурации Master, устранением физических неисправностей линии связи или обновлением прошивки контроллера.

Системный подход — захват трафика (Wireshark) + анализ диагностического буфера ПЛК — позволяет локализовать корень причины за 15-30 минут, избегая долгого тыка в настройки «вслепую».

Данная статья подготовлена на основе общедоступной технической информации и опыта эксплуатации оборудования промышленной автоматизации. Для получения актуальных версий прошивок и официальных кодов ошибок обращайтесь на сайт производителя или в техподдержку по телефону (замаскировано в соответствии с политикой безопасности).