Отсутствие опроса устройств при отключении ряда из них

Добрый день!

Столкнулся со следующей ситуаций.

Контроллер AM75Z4F3, wb-2507, stable, 8.4.3A/4G2 1.2A-4G.
К нему подключен ряд устройств: “wb-mao4_221”, “wb-mr6c_16”, “wb-mr6c_63”,“wb-mr6c_83”,“wb-mr6c_84”,“wb-mr6c_117”,“wb-mr6cu_108”,“wb-mr6cu_131”,“wb-mr6cu_239”,“wb-led_130”,“wb-led_144”,“wb-map6s_55”,“wb-map6s_116”,“wb-mio-e_183”,“wb-mai6_119”,“wb-mr6cu_207”,“wb-mio_162”. Основная часть подключена к RS-485 1, кроме wb-mio-e_183 и wb-mai6_119, которыеые подключены через шлюз WB-MIO-E v.2, который в свою очередь подключен напрямую к контроллеру в eth.

Так же к контроллеру подключен инвертор по протоколу snmp (192.168.184.20), через внешний коммутатор, который подключен к контроллеру через другой eth порт.

Запитывается всё это от двух линий питания 24 В:

  1. линия гарантированного питания от ИБП постоянного тока (DUPS20), на ней висит всё уже упомянутое, включая контроллер.
  2. резервный источник питания, на нём висят контроллер, wb-map6s_55, wb-mr6cu_207, wb-mio_162. Уточняю, что эти элементы питаются через диодную развязку, то есть напряжение на них приходит либо от 1 линии, либо от резервного. Резервный источник обычно отключен. Включается при пропадании питания на 1 линии. При таком переключении происходит кратковременная пауза, поэтому контроллер и модули перезапускаются.

Теперь по проблемам, их две.

Проблема 1. Если отключить основное питание 24 В, и перезапустить контроллер от резервного ИП, то даже запитанные модули перестают нормально опрашиваться.
Сами модули не показаны как офлайн, они не святятся красным и даже имеют значения в полях топиков, но их данные не обновляются. Для сравнения: 55 модуль запитан, 116 нет.

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

Я зашёл в настройки последовательных портов, включил режим отладки и записал лог. Он выше.

Сразу скажу, что проблемы не было какое-то время назад, проверяли такой режим неоднократно. У меня есть функция практически полного обесточивания, опция работала, контроллер норм входил и выходил из данного режима. Проблема, как мне кажется, проявилась только на прошлой неделе, когда отключили питание, включили, и контроллер не выполнил алгоритмы включения. Я это связываю именно с проблемой связи с модулями.


Для полноты картины так же опишу, что произошло неделю назад.

  1. реле wb-mr6cu_207/K1 было замкнуто.
  2. отключили основное питание контроллера. Реле wb-mr6cu_207/K1 так же откючилось.
  3. контроллер запустился на резервном источнике питания. Реле wb-mr6cu_207/K1 НЕ ВКЛЮЧИЛОСЬ. По идее должно было включиться. Но не придал этому значения.
  4. прошло 10-20 минут, включили основное питание контроллера. все модули получили питание. Реле wb-mr6cu_207/K1 по-прежнему было отключено.
  5. Я зашел в админку по веб, и вижу, что в админке wb-mr6cu_207/K1 включено. В жизни нет, светодиод у 1 выхода на wb-mr6cu_207 не горит. ПРОВЕРИЛ визуально.
  6. Перезагрузил контроллер руками по кнопке ПЕРЕЗАГРУЗКА в админке. Ничего не поменялось - в админке горит включенным выход, в жизни нет.
  7. Передёрнул в админке этот выход - как только он оказался отключенным, скрипт смог его включить с первого раза.

Моя гипотеза была в том, что контроллер потерял связь с модулем - и даже после перезагрузки не мог понять, что модуль тут. Такое ощущение, что состояние его выходов жёстко застряло в контроллере, что он не мог его синхронизировать с модулем.

Диагностический архив на тот момент времени был приложен в этом посте

(там я описал другую проблему и не стал смешивать)

Эксперименты, которые я проводил сегодня и создал эту тему - это попытка повторить ту ситуацию. Один в один она не повторилась, но схожесть поведения модулей есть. Я уже глянул лог - там mqtt serial упорно пытается связаться с модулем 221 и напрочь забывает обо всём остальном. Но возможно я что-то не так смотрю, так что оставляю вопрос специалистам.


Проблема 2.

Кстати, она в прошлые выходные так же повторилась, то есть это уже уверенное поведение контроллера.

После того, как все модули были запитаны и вроде как всё внешне ожило - не восстановилась связь с инвертором по протоколу snmp (192.168.184.20). Я пробовал в прошлые выходные перезапускать инвертор, переподключал его snmp модуль - эффекта не было. А вот перезагрузка контроллера сразу вернула обмен с ним к жизни. Сегодня сам инвертор не трогал, перезагрузка контроллера помогла, связь с ним восстановилась.

![Скрин 3 16.29.30|635x469](upload://15F06fF2PbGSAfy63Tw6CRkfY6E.png)

Удалённый доступ к контроллеру есть, что-то заходить выполнять можно, однако так пощёлкать питанием проблематично во время рабочей недели. Если что-то вдруг пойдёт не так, то будет некому запустить систему даже вручную.


Не понятно почему скрин не прикрепился выше. Так выглядит отвал связи с SNMP, когда он подключен (значения полей NaN. У тех полей, где есть запись - это виртуальные устройства правил). Кстати, для информации - связь с ним теряется, т.к. отключается питание хаба, через который он подключен. Так то инвертор в норме и продолжает работать.

Добрый день!

Прошу отключить режим отладки и повторить эксперимент.
Также прошу приложить схему коммутации и проверить напряжение на клеммах — соответствует ли оно ожидаемому значению.

Могу приложить частичные фотографии, потому что страниц много и выкладывать всё не очень хочется.

Схема коммутации интерфейса стандартная: не экранированная витая пара внутри одного щита идет шлейфом по всем устройствам по минимальной дистанции, на оконечном устройстве терминальное сопротивление 120 Ом, в контроллере сопротивление тоже включено.

Питание так же параллельно заведено на модули. gnd на модулях и интерфейсах объединены. Напряжения в норме, 27 В по основной линии и 24 В от маломощного ИП для нескольких модулей, если отключен основной ИП и батареи. В процессе проверки видел, что напряжение, приходящее на контроллер было 24 В как и ожидалось от этого источника.

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

Добрый день!

Попробуйте по максимуму исключить все устройства и проверить работу в минимально воспроизводимой конфигурации.
Также прошу проверить, нет ли разрыва общей земли (GND) при переключении.
Уточните, пожалуйста, куда именно заведена объединённая GND в конце.

приложен диагностический архив, доступен только сотрудникам поддержки
(569,9 КБ)
Вот, в 13.45.02 по мск я перевел его в режим ограниченной работы: контроллер, 55, 207, и 162 модули физически остались в работе, остальные отключились по отсутствию питания. Напряжение по измерителю самого контроллера - 24 В.

Кстати, заметил, что 55 модуль не полностью умирает, связь идёт, но очень редко. Десятки секунд проходят, пока показания изменяться.

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

Добрый день!

Проанализировал архив — вижу большой поток ошибок следующего вида:

Oct 27 13:47:15 wirenboard-AM75Z4F3 wb-mqtt-snmp[3158]: ERROR: failed to poll snmp_192.168.184.20_public: Output load percent: Error writing to socket: write udp 192.168.184.54:48116->192.168.184.20:161: write: network is unreachable
Oct 27 13:47:15 wirenboard-AM75Z4F3 wb-mqtt-snmp[3158]: ERROR: failed to poll snmp_192.168.184.20_public: OutputSourceStatus: Error writing to socket: write udp 192.168.184.54:48116->192.168.184.20:161: write: network is unreachable
Oct 27 13:47:15 wirenboard-AM75Z4F3 wb-mqtt-snmp[3158]: ERROR: failed to poll snmp_192.168.184.20_public: AC output apparent power: Error writing to socket: write udp 192.168.184.54:48116->192.168.184.20:161: write: network is unreachable

Далее встречается ошибка:

Oct 27 13:51:31 wirenboard-AM75Z4F3 wb-mqtt-serial[2059]: WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors

Такое сочетание может приводить к ситуации, когда устройства опрашиваются некорректно.

Да я особо не сомневаюсь, что потеря ряда устройств ломает обмен. Вопрос в том, чтобы этого не было. Я понимаю, что какое-то время интерфейс потратит на ожидания ответов, но не полминуты же. Кстати, сейчас я быстро обратно всё включил, в течение пары минут. В предыдущие разы с более длинными разрывами 15-20 минут ИБП (wb-mqtt-snmp) в себя не пришел вообще до перезагрузки контроллера.
Плюс wb-mqtt-snmp и последовательный порт вообще разные сервисы, почему они друг на друга влияют (если это связано между собой)

Добрый день!

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

Ок, буду ждать информацию. Какие причины устранять не очень понятно, потому что с точки зрения структуры системы это штатное состояние.

Добрый день.
Попробовал воспроизвети.
Для этого настроил 20 фактически отсутствующих устройств (выбрал WB-MR3) на шине.
Ну и (одно) устройство с адресом 36 реально присутствует.
И да - опрос идет, с перерывами на таймаут.

То есть фактически, учитывая таймауты опрос раз а ~7 секунд.
Иными словами - не воспроизводится.

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

Ещё такой момент: как работает отладочный лог для 485? Ведь там в логе реально видно зависание на одном устройстве, т.е. он упорно пытается прочитать одно устройство (какое именно не помню, надо файлы из темы поднимать). Когда в настройках включен режим отладки интерфейса. Либо лог выборочно показывает неудачные опросы?

И второй момент: а snmp почему не восстанавливается даже после возврата всех 485 модулей?

Честно говоря эта картинка не понятна от слова совсем. У вас есть такое ветвление “устройство было отключено”. Что это такое не ясно. Если предполагать пропадание связи, то получается в случае “нет” он опрашивает регистры. А если пропадало, то ещё и пишет?) Может там да / нет местами поменялись? Ну даже если и так, то после определения устройства отключенным - опрашивать все его порты - странно как-то.

Если в целом всё действительно так работает, то должна помочь корректировка интервала ожидания ответа, ибо 500мс это я уж не знаю для каких устройств сделано)

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

Debug пишет в лог вообще все что отправляется-принимается в шину.

Обратите внимание:

Oct 25 16:12:44 wirenboard-AM75Z4F3 wb-mqtt-serial[16835]: DEBUG: [modbus] </dev/ttyRS485-1 115200 8 N 2> modbus:221 write 1 (type 0)(s) @ 114
Oct 25 16:12:44 wirenboard-AM75Z4F3 wb-mqtt-serial[16835]: DEBUG: [port] /dev/ttyRS485-1: Sleep 0 us
Oct 25 16:12:44 wirenboard-AM75Z4F3 wb-mqtt-serial[16835]: DEBUG: [port] /dev/ttyRS485-1: Write: dd 06 00 72 00 01 fb 4d

запись То есть какое-то ПО пытается записать что-то в модуль, не учитывая статус контрола (meta/error=rw) забивая очередь записи.
Соответственно настройкам по умолчанию:
Screenshot_20251125_102746
Соответственно каждая попытка записи - добавляется в очередь, первые строки которой удалятся через 600 секунд.

Не воспроизводится…
То есть не смог подобного добиться.

В документации описано:

А как понять что оно включилось?

Не обязательно. Достаточно не писать что-то в устройства если у них статус ошибка.

Ясно, спасибо. Вот это уже ближе к делу. Там действительно есть ряд строк, где в устройство записывается значение без учёта его статуса. Плюс в последней версии ПО выпал кусок анализа статуса, в итоге количество таких записей возросло. Я это обнаружил, но специально не вносил исправлений, пока ошибка четко выявлялась (чтобы либо убедиться в этом проблема, либо не замаскировать выявление, если ошибка не в этом). Попробую устранить все записи и посмотрю на сколько изменится результат.

Тут есть довольно интересный нюанс, про который многие почему-то забывают при проектировании.
Совсем не редкость ситуация, когда из-за повреждения шины устройство slave продолжает получать запросы от master.
Ну да, пусть не все, но какую-то часть успешно получает.
А ответы slave до master - не доходят совсем.
То есть: контроллер выставляет у себя статус meta/error “r”. И периодически снова пытается опросить устройство. Устройство получая какую-то часть корректных запросов в безопасный режим не переходит.
То есть расчет на то что например модуль реле перейдет в безопасный режим может не оправдаться.

Для избегания такого при появлении и сохранении в течении 5 секунд ошибки чтения я один раз отправляю в реле состояние “безопасного” режима. Явно их переключаю.
Драйвер будет в течении 10 минут пытаться записать - и в случае односторонней связи скорее всего запишет.

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

2 Likes

В общем, существенно, но не полностью урезал такие записи, сделал тайм-аут ответа равным 100мс вместо 500мс, попробовал отключить, сначала опрос модуля шёл где-то раз в 9 секунд, минут через 10-15 стал в районе 20-22 секунд. В промежутках я перезапускал mqtt-serial для включения отладки интерфейса. В этот раз модуль snmp восстановился после восстановления связи.
Не идеально конечно, но уже проще и жить можно.

А попытки записать уже после отключения устройств - были?

В момент отключения пару секунд точно были записи, пока он не понял, что отключился. Я выждал 12 минут, чтобы те 600 секунд списались, и посмотрел скорость обмена.

В этот период записей, по идее не велось. Считывание из mqtt через считывание dev точно производилось.