Здравствуйте! WB-MAI6 (s/n 354361, fw2.4.2) измеряет напряжение на последовательно соединенной батарее гелевых АКБ по 200Ач каждая. Естественно - через VDIV. Не совсем понимаю, причины появления на графике в разделе “история” таких всплесков (скриншот), которые явно за пределами реальных значений. Параметры канала - на скриншоте.
Справочно: АКБ на постоянной основе подключены к силовому инвертору, но поступление с той стороны всплесков такой амплитуды не выглядит реалистичным. Тем более, что нагрузка на инверторе в этот период минимальная.
Добрый день!
Сможете повторить измерения на отключенной от инвертора аккумуляторной батареи? Так мы точно поймем, что со стороны инвертора нет всплесков и проблема в измерении.
Добрый день!
Вам удалось проверить на отключенной батарее?
Добрый день! Увы, пока возможности обесточить узел не было. При этом производитель инвертора (“Микроарт”) считает фактически невозможным всплески с такой амплитудой.
Попробуем, конечно, еще обесточить, как-то для проверки. Но сложно это.
Можно ли еще что-то предпринять, чтобы выяснить причину такого поведения?
Я бы предложил измерить напряжение на любом другом отключенном от внешних источников аккумуляторе. Нам нужно понять - с вашим WB-MAI6 что-то происходит или все же внешние факторы.
Входы высокоомные, поэтому не следует исключать наведенное напряжение при коммутациях нагрузки.
Измерения лучше проводить коротким кабелем и вдали от возможных источников помех.
Добрый день! А это неожиданное поведение.
Попробую воспроизвести, а вас попрошу выслать диагархив.
Для диагностики проблемы пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в документации.
Приложено
приложен диагностический архив, доступен только сотрудникам поддержки
(466,8 КБ)
Добрый день!
На моём MAI6 с прошивкой 2.4.2 такое поведение не воспроизводится. По присланному архиву видно, что у вашего модуля есть проблемы со связью – по контрольной сумме и по таймауту + контроллер получил в ответ кадр от другого адреса. Такие ответы от чужого адреса встречаются только на шинах ttyMOD1 и ttyMOD2, на ttyRS485-1 и ttyRS485-2 их нет ни одного. Предполагаю, что неверный серийный номер получается из той же причины.
Что прошу проверить. Адрес 186 у вас занят дважды: это MAI6 на ttyMOD2 и WB-MR6C v.3 на ttyMOD1. Если линии физически независимы, так можно, но посмотрите, пожалуйста, не сведены ли они где-то в шкафу – общий отрезок кабеля, перепутанная пара в клеммнике, объединённые A и B и т.д. И запустите в веб-интерфейсе скан обеих шин, пришлите результат: если на одном адресе отзовутся два разных серийных номера, всё станет понятно сразу. Если будет возможность, поставьте MAI6 единственным устройством на свободный порт и посмотрите, сохранятся ли симптомы.
Добрый день! Физически линии ttyMOD1 и ttyMOD2 разные, идут в разные стороны. Разве что экран их кабелей заземлен вместе. Но проверим на всякий случай.
По кнопке “Найти и добавить устройства Wirenboard” в разделе настройки serial-устройств отображается корректно только по одному устройству с адресом 186 на линиях MOD1 и MOD2 с разными s/n.
При этом периодическое поступление от MAI6 произвольных многозначных значений своего серийного номера продолжается.
Общее заземление экранов проверять не обязательно, само по себе оно линии данных не связывает.
Тогда следующий шаг-- оставить MAI6 единственным устройством на отдельной линии. Понаблюдайте, будут ли произвольные значения серийного номера появляться там. Результат важен в любую сторону: если они останутся, значит дело в обмене с самим модулем, а не во влиянии соседей по шине; если пропадут – будем разбираться с линией ttyMOD2.
И скажите, бывает ли то же самое со вторым MAI6 на ttyRS485-2?
Попробую. Вернусь с результатом.
Ранее не замечалось. За текущие сутки проблем нет.
Добрый день!
Пожалуйста, поделитесь результатами наблюдений. Возникали ли проблемы на отдельной линии?
Добрый день! Пока выявить что-то такое, что позволило бы, на мой взгляд, локализовать проблему, не удалось. Чистой отдельной линии RS485, увы, нет. Только другие ветки доступны. Переключили. за трое суток по серийному номеру модуля разнообразия значений в логе не отмечено. Правда, есть одно обстоятельство - модуль включен на линию без физически подключенных входов. Хотя, на выдачу sn это и так не должно было бы влиять.
Еще раз посмотрел другие устройства на “старой” линии. По одному из них (MAP3E id41) также проскакивают время от времени выбросы по sn.
При этом инвертор, который исходно предполагался источником проблемы, сейчас отключен физически.
Уточните, а по другим параметрам нет подобных выбросов? Только s/n?
Там сейчас MAP3E не сильно загружен, ввиду отключенного инвертора, но по F и Urms по L1 и L3 я не вижу выбросов.
Благодарю за обратную связь!
Нам нужно понимать - это проблема связана с ПО контроллера или такие данные действительно поступают от устройств.
В этом очень помогло бы переключение драйвера в режим отладки и посмотреть принятые пакеты в момент возникновения проблемы.
На какое время допустимо режим отладки включать? В данном случае даже суток может оказаться недостаточно. А для одной линии, я так понимаю, отладку включить нельзя…
Ограничения по времени у отладки нет и держать её включённой можно сколько нужно. Ограничивает не время, а объём: в отладочном режиме драйвер пишет в журнал каждый отправленный и принятый пакет, поэтому журнал быстро растёт и начинает вытеснять сам себя, плюс это лишние записи на eMMC.
И вы правы, штатно отладка включается целиком для драйвера, выбрать отдельный порт нельзя. Но сузить вывод можно иначе: остановить сервис и запустить драйвер вручную с копией конфигурационного файла, в которой оставлен только нужный порт:
systemctl stop wb-mqtt-serial
wb-mqtt-serial -c /etc/wb-mqtt-serial.conf -d # запустить в отладочном режиме с указанием пути к конфигурационному файлу
Тогда в журнал попадёт обмен только по этой линии. Минус – остальные порты в это время опрашиваться не будут. Команды и способы включения отладки описаны здесь:
Попробуйте на время диагностики задать для канала с серийным номером этого устройства период чтения 500 мс.
Отключение других линий от опроса - увы, не вариант. Подумаю, как организовать с предлагаемой частотой опроса.