Меняем, напишите почту , можно в ЛС.
Кажется у меня недостаточный уровень для личных сообщений. И E-mail видимо.
Кажется источник проблем локализован.
Для истории, что есть
- Wirenboard 6.
- На первую шину MODBUS (ttyRS485-1) подключено 5 разных промышленных датчиков, разных производителей.
- Свой софт, снимающий измерения по шине, достаточно часто - раз в секунду. За пределами проблемы вопрос “почему так ?”
- Wirenboard регулярно перезагружается. Периодичность от нескольких минут до более 2 часов.
Контроллер не работал более 3-х часов после включения - Проблемы начались только после установке на площадке, в лаборатории перезагрузок не замечено.
- Внешнее соединение - через GSM
Подозрения падали на перезагрузку по watchdog при превышении загрузки CPU выше установленного уровня
ОТВЕРГНУТО, поскольку перезагружается и при отключенном watchdog и НЕ перезагружается на стрессовом тесте
Подозрения падали на слабый БП, поскольку модему GSM может не хватать мощности в условиях слабого сигнала.
ОПРОВЕРГНУТО, поскольку замена БП на существенно более мощный проблемы не решило.
Подозрения падали на собственный софт, который каким то неведомым образом рушит контроллер.
Доказанного опровержения нет,но
- ничего подозрительного по коду не найдено
- в лабораторных условиях не перезагружается
ОДНАКО, при последовательном отключении блоков и датчиков найдено, что, если отключить один из датчиков ( Serveron TM1), то перезагрузок не происходит.
Все остальные датчики при этом остаются включенными и передают данные.
С датчика считывается всего 2 16-битных регистра.
При этом датчик остается подключенным к шине - его просто не опрашивают.
Теперь вопрос, это как же этот датчик может влиять на перезагрузку при том, что он проводит все собственные измерения и только не опрашивается ?
По документации производителя и информации от работников площадки, датчик не подключен к Vout.
Интересно. А он, датчик, опрашивается вашим софтом? Возможно, где-то происходит переполнение /исключение?
Если для проверки остановить ваш софт и запустить в цикле
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a82 -t0x03 -r250
где -a82 - адрес десятичный (82)
-r250 - читаемый регистр.
Может он ответить не успевает. wb-mqtt-serial у нас корректоно обрабатывает ошибки.
Он отвечает и вполне осознанными пакетами, с нормальной CRC.
Таймауты вроде нормально везде контролируются и обрабатываются.
Exception перехватываются и логируются.
Поскольку код на C# вряд ли он так без следов вырубился бы, а ни в системном логе, ни в нашем, ни в консоли никаких следов. Я грешу на качество подключения.
Питается он по документации от 220. Может земля плохая?
Вот запросил площадку
Ответ “ТМ1 - добавил GND (до этого не было).” Ну вот как тут не ругаться матом ?
Включил опрос датчика.
Если 3 часа проживет, то, скорее всего враг найден и обезврежен, а вывод “проверять землю”.
Отпишусь по результату
…
Результат - перегружается. TM1 питание MODBUS не использует. Есть, конечно, вариант, что и сейчас что то криво соединено по земле.
А этот же датчик “на столе” - работал? Хм, А питание на него, на датчик идет от той же фазы что и на блок питания… Хотя - это вряд ли повлияет, проблема только при опросе. Есть возможность включить логирование запросов-ответов?
Есть возможность включить логирование запросов-ответов?
В смысле ? Дамп пакетов MODBUS ?
Можно, включены, но это ничего не даст - пакеты то нормальные
Пример
MODBUS devices statistic Last moment Duration Received Errors
SlaveID=2 PortName = ttyrs485-1 PortSpeed=9600 PortPara = 8N1
hydrogen content [0] 2020/07/03 12:55:32.262 26 2777 0
Last success Send=02-03-00-00-00-01-84-39 Receive=02-03-02-00-00-FC-44
Last error Send=none Receive=none
content dynamics [1] 2020/07/03 12:55:32.309 26 2777 0
Last success Send=02-03-00-01-00-01-D5-F9 Receive=02-03-02-00-00-FC-44
Last error Send=none Receive=none
Расшифровка.
Отдельно выводится последний успешный пакет и последний ошибочный пакет.
Количество снятий (2777) - 1 снятие в 500мс от последней инициализации
Duration (26) - миллисекунды - время на одно снятие ( всего м.б. 5 попыток до первой успешной) как правило попытка одна. Это время БЕЗ учета “времени тишины” ( задержка перед отправкой следующего пакета)- оно сейчас 20мс
Если с пакетом что то не так, то выводится отдельно строка лога на каждый пакет.
но их нет !
Хм. Не было земли - глючил. Появилась - тоже глючит. Может не то, не так или не туда присоединили?
Надеюсь, что так. Пытаемся привлечь производителя датчика
Может корпус датчика задемлили? Если у него развязанный гальванически выход - то “землю” (минус шины 485) надо подключать именно к предназначенному контакту. Вообще да, при работе передатчика устройства (именно при “ответе”) без земли может на линию давать импульсы.