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

Добрый день!

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

Контроллер 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 и последовательный порт вообще разные сервисы, почему они друг на друга влияют (если это связано между собой)

Добрый день!

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

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