День добрый.
Есть такая проблема: на последовательном порту контроллера висит куча modbus устройств, причем два из них - шлюзы WB-MIO-E V2. Всё работает.
Физически отключаем шлюз. Опрос modbus зацикливается на попытке записи в шлюз, непрерывно посылая пакет 4A-06-00-72-00-01-E7-55 - 4A - адрес шлюза. Все остальные модули, висящие на том же последовательном порту опрашиваться перестают.
Если в настройках драйвера serial устройств запретить опрос всех модулей, стоящих за отключенным шлюзом - опрос восстанавливается.
Добрый день!
WB-MIO-E V2 у вас работает на одном порту контроллера совместно с другими Modbus устройствами в режиме прозрачного шлюза?
Для диагностики проблемы пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в документации.
День добрый!
Диагностический архив оттуда снять не просто: контроллер стоит на месторождении в медвежьем углу, связи туда нету. Его на один день привозили в цивилизацию изменить прикладную программу и попутно обнаружился описанный эффект. Собственно как было обнаружено: людям надо было подключить дополнительно к имеющимся 50 датчикам температуры еще 8 - они сняли контроллер, привезли его в городок, подключили к нему овен 110 8А, я им его сконфигурировал - и все вроде работало. А потом обновили софт на контроллере путем apt update && apt upgrade - и вот именно после этого опрос модуля прекратился и не восстанавливался никак, пока не заблокировали опрос модулей, стоящих за шлюзом.
По поводу порта - да, там два шлюза и до сотни устройств на одном порту со скоростью 57600, на втором порту поднят модбас сервер для связи с верхним уровнем АСУТП.
Попробую попросить притащить контроллер еще раз, но не факт, что получится. В принципе - пока шлюзы не отвалились - все работает. Но заказчику такое поведение не нравится - при аварии связи со шлюзом пропадают все данные со шкафа, а не только те, что за отвалившимся шлюзом были.
Вдогон: притащили еще 3 таких контроллера с прошивкой конца 22 года.
И они этой болезнью не болеют. Сейчас один из них обновим и узнаем появляется ли эффект при обновлении. И архив с этого я смогу снять
подтверждаю: эффект остановки опроса появляется при обновлении до сегодняшней актуальной версии. Архив сняли. Прилагается.
diag_output_ATQS7HDK_2025-10-14-10.17.51.zip (150,1 КБ)
Добрый день!
Благодарю за наблюдение и предоставленный архив!
Постараюсь воспроизвести поведение.
Уточните пожалуйста, какой релиз был до обновления и какие настройки шлюзов ?
И еще немаловажное уточнение— шлюзы WB-MIO-E V2. у вас подключены по такой схеме?:
Есть возможность выслать скриншоты их настроек?
Как временное решение: предлагаю рассмотреть использование TCP/IP порта через Ethernet:
День добрый!
Шлюзы там стоят в качестве modbus rtu / i2c конверторов, т.е. Ethernet для связи с модулями не используется. На нем висит операторская панель. Одна из страниц схемы прилагается. Вот эта вот шина WB1.RS2A/B идет через всю схему с 23 по 42 страницу 
На шине висят штук семь MAI6, столько же WBMAP12, примерно 60 модулей Аист-102 (измерители тока утечки).
Настройки шлюзов вряд ли имеют какое-то отношение к делу, поскольку эффект проявляется именно когда шлюзов нету. Возможно, что шлюзы там “из коробки” - единственное, что им точно поменяли - поставили скорость последовательного порта 57600.
Сфотать настройки шлюзов - попробую наладчиков попросить, но шансов немного.
Релиз там судя по всему был 2304 или предыдущий.
Вариант переподключения через Ethernet не слишком хорош - там где шкаф стоит никто не будет в нем что-то переключать. Да и править прикладную программу придется изрядно - все имена тегов поменяются. Это не та задача, которую удобно решать посреди тайги со связью через заикающийся мобильник. Собственно пока все компоненты и связи исправны - всё работает штатно. Проблемы будут, если что-либо отвалится.
Да, существенно: эффект замечен на двух разных контроллерах из двух разных шкафов. Т.е. эффект относится не к экземпляру, а к типу.
Добрый день!
Теперь понял вашу ситуацию.
Попробую воспроизвести и вернусь с ответом.
дополнительная информация - на одном из четырех шкафов опрос останавливается на опросе шлюзов даже при всех подключенных модулях.
приложен диагностический архив, доступен только сотрудникам поддержки
(215,5 КБ)в journalctl при этом пишется непрерывный опрос шлюзов без обращений к остальным модулям и без ошибок
Добрый день!
Благодарю за дополнительную информацию!
Проанализирую и попробую воспроизвести. По результатам сообщу.
Отключаю шлюз, который работает с WBIO модулями и совместно с остальными modbus устройствами Wiren Board на скорости 57600, и такого поведения не наблюдаю — оставшиеся на шине устройства продолжают работать:
17-10-2025 10:56:12.187 WARNING: [serial device] device modbus_io:147:3 is disconnected
17-10-2025 10:56:12.187 WARNING: [modbus] failed to read 8 coil(s) @ 0 of device modbus_io:147:3: Serial protocol error: request timed out
17-10-2025 10:56:11.595 WARNING: [serial device] device modbus_io:147:2 is disconnected
17-10-2025 10:56:11.595 WARNING: [modbus] failed to read 8 coil(s) @ 0 of device modbus_io:147:2: Serial protocol error: request timed out
17-10-2025 10:56:10.419 WARNING: [serial device] device modbus_io:147:1 is disconnected
17-10-2025 10:56:10.416 WARNING: [modbus] failed to read 14 holding(s) @ 250 of device modbus_io:147:1: Serial protocol error: request timed out
17-10-2025 10:56:09.361 WARNING: [modbus] failed to read 8 coil(s) @ 0 of device modbus_io:147:3: Serial protocol error: request timed out
17-10-2025 10:56:08.770 WARNING: [modbus] failed to read 8 coil(s) @ 0 of device modbus_io:147:2: Serial protocol error: request timed out
17-10-2025 10:56:08.178 WARNING: [modbus] failed to read 14 coil(s) @ 0 of device modbus_io:147:1: Serial protocol error: request timed out
17-10-2025 10:56:07.627 WARNING: [modbus] failed to read 14 holding(s) @ 250 of device modbus_io:147:1: Serial protocol error: malformed response: invalid crc
17-10-2025 10:55:49.844 INFO: [serial device] device modbus:55 is connected
17-10-2025 10:55:49.844 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 25601><-- 0 (0x0)
17-10-2025 10:55:49.821 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 25600><-- 0 (0x0)
17-10-2025 10:55:49.797 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 21505><-- 0 (0x0)
17-10-2025 10:55:49.773 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 21504><-- 0 (0x0)
17-10-2025 10:55:49.750 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 17409><-- 0 (0x0)
17-10-2025 10:55:49.727 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 17408><-- 0 (0x0)
17-10-2025 10:55:49.703 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 13313><-- 0 (0x0)
17-10-2025 10:55:49.679 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 13312><-- 0 (0x0)
17-10-2025 10:55:49.656 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 9217><-- 0 (0x0)
17-10-2025 10:55:49.633 INFO: [modbus] Init setup register "Mode": <modbus:55:holding: 9216><-- 0 (0x0)
7.4.4C/2GC 1D/O-2GC
wb-2507
stable
Будьте добрый выслать ваши шаблоны к устройствам AIST 102C и OWEN MV110.
Если учесть в AISU6K46 зацикливание проявляется и при подключенном шлюзе, то тут может быть дело в неверно подобранных параметрах для wb-mqtt-serial.
День добрый!
Прилагаемые файлы взяты мною из исходного проекта кроме конфигов ОВНа. История вопроса там такая, что изначально в шкафах не было блоков ОВЕН. И когда выяснилось, что в проект забыли добавить кучу датчиков температуры - заказчик сам докупил и установил модули и нас попросили помочь запустить их. То есть в прилагаемом wb-mqtt-serial ОВНов нету.
Конфиги для ОВНов были по-быстрому сляпаны на коленке и там абсолютный минимум регистров.
Тот wb-mqtt-serial , который реально сейчас на шкафах - уже недоступен: генеральный заказчик сегодня принял шкафы (они же работают, если модули по одному не отрывать) и больше никого к ним не подпустит.
aist102c.json (508 байтов)
config-map12h-esseo-trans-reliable.json (19,9 КБ)
oven.json (2,1 КБ)
wb-mqtt-serial.conf (14,1 КБ)
Добрый день!
“response_timeout_ms”: 20,
“frame_timeout_ms”: 15,
Рекомендую увеличить таймауты.
Так же еще заметил, что в шаблоне для сторонних не задан guard_interval_us.
Ниже приведены ссылки на документацию к драйверу с описанием его параметров и рекомендации по составлению шаблонов:
День добрый. Если крутить задержки фрэйма и ответа - в какой-то помент соответствующий модуль сначала будет читаться нестабильно - с ошибками контрольной суммы - а при дальнейшем уменьшении - перестанет читаться вовсе. При этом с опросом ничего криминального не происходит - ну отвалилась пара устройств - остальные опрашиваются.
Я не очень понимаю в каком вообще случае возможна остановка опроса - причем это даже не остановка, а защикливание на операции записи в регистр.
Здравствуйте!
Давайте остановимся на одном из ваших контроллеров.
Мне на wb-2507 (as stable) не удается воспроизвести подобное поведение.
Предлагаю включить debug ( Включение отладки) и снять лог wb-mqtt-serial (или выслать архив). Посмотрим какие пакеты отправляются при зацикливании.
Здравствуйте!
Ожидаю лог с включенной отладкой.
День добрый. К сожалению на данном этапе доступа к контроллеру уже нет: заказчик сказал, что его всё устраивает, а что будет если отвалится связь между модулями - ему неинтересно, ибо такое событие рассматривается как маловероятное
Здравствуйте! В таком случае, если решите разобраться с проблемой, то прошу выслать архив с включенной отладкой и обеспечить доступ к контроллеру.
День добрый! Полагаю если ситуация повторится и будет отловлена на стадии сборки шкафов “в студийных условиях” - тогда есть смысл продолжать.
Спасибо.