Нарушение связи Modbus после обновления до wb-2602

Контроллеры Wiren Board
1

Контроллер: 8.4.4B/4G1 1.2C-4G
После обновления до wb-2602 наблюдаю странную ситуацию.
Сеть очень разветвленная, задействовано 13шт. WB-MGEv2.
Сразу после обновления заметил, что отваливаются устройства за одним из шлюзов, причем очень странно отваливаются. В meta топики error ничего не пишется
Я это заметил только по тому, что у меня есть самописное правило следящее за доступностью узлов посредством постоянного контроля за изменением uptime или heartbeat.
После перезагрузки wb-mqtt-serial обмен возобновляется и стабильно идет около 15 сек, потом замолкает (т.е. значения не обновляются), при этом в конфигураторе Serial-устройств выглядит все хорошо, даже прошивка корректно обновляется.
К этому WB-MGEv2 подключено: 2шт. WB-MR3LV, 1шт. WB-MR6CU и Овен ПР102. Все это работало в такой конфигурации уже два года без сбоев.
В настройках порта была прописана Задержка перед записью в порт - 4000мкс, т.к. подключено стороннее Modbus устройство.
Так вот, я поменял это значение на дефолтный 0 и все заработало. Но раз в пару дней наблюдаю те же симптомы, на несколько минут все устройства за шлюзом замолкают, а потом работают нормально.
Странно это еще и потому, что подобных шлюзов WB-MGE, за которыми стоят вперемешку устройства WB и Овен у меня несколько, и ни с одним больше такой проблемы нет.
Сейчас пока писал это сообщение, подумал, почему бы не посмотреть на то, бегают ли пакеты между контроллером и MGE. Установил задержку перед записью в порт - 4000мкс, что бы связь гарантировано нарушилась. И видно, что первые несколько секунд обычные Modbus запросы/ответы бегают, а потом видно только пакеты связанные с быстрым Modbus и запросы без ответов.
Файл из Wireshark прилагаю.

KOTELNAYA.pcapng (105,1 КБ)

3

Добрый день.
Диагностировать и воспроизвести довольно сложно.
Подскажите описанная ситуация наблюдается только на одном шлюзе?

4

Да, только на одном и именно после обновления до wb-2602

5

Пришлите пожалуйста его серийный номер WB-MGE v.2

6

HW: 2.5
Номер: 4262639946

8

По серийнику это какой то очень очень старый шлюз WB-MGE от 11.10.2021, запишу в книгу жалоб для разработчиков, по возможности посмотрят, не сломали ли чего по совместимостям со старыми устройствами.

9

Вряд ли, в этой же системе без перебоев работают и более старые шлюзы.
В общем, я постараюсь в ближайшие дни поменять два шлюза местами и отпишусь.
Думаю, так точно ясно будет, в шлюзе ли дело

10

Хорошо, ждём обратную связь.

11

Заменил шлюз на WB-MGE v.2 HW:2.10Y 5EE75180
Ради эксперимента опять выставил задержку перед записью в порт 4000мкс - все тоже самое.
Сам контроллер Wirenboard молчит и не видит проблем, в логах между перезапусками wb-mqtt-serial вообще тишина. Но устройства при этом не опрашиваются и данные с них не обновляются. Если же в конфигураторе я нажимаю “Перечитать настройки” или меняю какие-либо настройки, все меняется и перечитывается. За шлюзом был WB-MDM3 для которого вышло обновление прошивки, так вот и прошивка успешно обновилась.

Один из вопросов, почему контроллер не ставит флаг …/meta/error - “r”, если отчетливо видно, что десятки запросов от контроллера остаются без ответа.
Я написал правило, что бы не пропустить ни одного статуса error:

trackMqtt(“/devices/+/meta/error”, function(message) {
log.info(“DevControl Subs | name: {}, value: {}”.format(message.topic, message.value));
});
trackMqtt(“/devices/+/controls/+/meta/error”, function(message){
log.info(“ContControl Subs | name: {}, value: {}”.format(message.topic, message.value))
});

Но ни одного сообщения о проблеме в логах нет.

Прилагаю трафик с момента перезагрузки wb-mqtt-serial. Отчетливо видно, что около 24 секунд идет нормальный обмен, а потом ответы на стандартные запросы Modbus почти не приходят. Здесь же и трафик процесса обновления прошивки WB-MDM3.
KOTELNAYA1.pcapng (551,1 КБ)

12

Добрый день.

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

13

приложен диагностический архив, доступен только сотрудникам поддержки
(497,2 КБ)

15

Пока в логах вижу что устройство плохо опрашивается на шине, много таймаутов от сюда и нарушение связи

image
image984×1085 35.9 KB

Происходит как раз в одном месте видимо, надо перепроверить что там по модулям, состав и состояние шины, возможно где то проблема по подключению именно после шлюза

16

Если вы смотрите сегодняшний лог в районе 9:30, то это как раз тот момент, когда я шлюзы местами менял, поэтому и столько ошибок.
Когда наблюдается проблема, таких ошибок нет.

17

Да как раз в 9:28

Получается что есть проблема только в одном месте с устройствами на шлюзе? на остальных шлюзах всё хорошо?

Подскажите насколько критично будет сделать поочередно:
apt update
apt upgrade
reboot

проверить осталась ли проблема

18

Да, проблема наблюдается только с устройствами за этим одним шлюзом.
Обновил, перезагрузил.
Если выставить задержку перед записью в порт 4000мкс - все тоже самое. Через несколько секунд после запуска wb-mqtt-serial, десятки запросов остаются без ответов.
Если задержка 0, то все работает относительно стабильно, но ответы вижу на процентов 70-80 запросов на вскидку.

19

Насколько сложно будет переконфигурировать все устройства заново?
Т.е. удалить этот канал управления и заново всё настроить, сначала только наши устройства затем уже посадить на шину сторонние.
Других вариантов пока выявить причину к сожалению не вижу.

20

Я ради эксперимента просто отключил опрос Овен ПР102, и все работало несколько минут стабильно с задержкой перед записью в порт 4000мкс. Длиннее эксперимент провести не могу, многое завязано на это устройство.
Выходит, ПР102 периодически вешает шину?
А есть ли возможность отключить ваш быстрый Modbus только на этом порту (шлюзе)? Так, что бы на шине были только стандартные запросы/ответы?
Если выяснится, что устройство Овен так реагирует на ваши широковещательные пакеты, то буду мучать их тех. поддержку)

21

Вполне возможно

Посмотрите там в настройках секции Socket A Parameters: настройки взаимодействия через Ethernet. В поле Work Mode можно выбрать один из режимов:

  • TCP Server/None — для протокола Modbus RTU over TCP, рекомендуем этот режим, если по RS-485 подключены Modbus-устройства Wiren Board — так вы сможете обновлять их прошивку.
  • TCP Server/ModbusTCP — для протокола ModbusTCP.

Попробовать как раз второй вариант

22

Да, действительно переключил на ModbusTCP, и вижу в трафике строго “Запрос - Ответ” без единого пропуска.
По сути, проблема решена, спасибо.
Но мой вопрос, почему контроллер не ставит флаг …/meta/error - “r”, если отчетливо видно, что десятки запросов от контроллера остаются без ответа, остался не отвеченным. Можете как-то это объяснить?

Ну и просьба на будущее: добавьте в web-интерфейс возможность менять тип порта (Serial over TCP / ModbusTCP), а то сейчас смог поменять только путем прямой правки конфига.

23

Пока без ответа, надо воспроизводить/разбираться запишу как жалобу.

Запишу как предложение.