После обновления до wb-2501 кастомные устройства перестали отвечать на запросы контроллера.
В логе wb-mqtt-serial только такое:
WARNING: </dev/ttyMOD1 19200 8 N 1>: closed due to repetitive errors|
WARNING: </dev/ttyRS485-1 19200 8 N 1>: closed due to repetitive errors|
Шаблон корректный (во вложении). На физическом уровне проблем нет, на отдельных шинах висит по 2 таких устройства, витая пара с экраном, концы обжаты в НШВИ, на концах шины терминаторы. До этого шина работала 2 года без сбоев. Длина трассы менее 10 метров.
UPD. При чтении значений регистров через modbus_client всё читается
Предыдущий релиз не подскажу, но версия примерно 2023 года.
По поводу диагностики я написал выше, там ничего полезного, только сообщения “closed due to repetitive errors”.
Никаких других ошибок и предупреждений нет.
Да, запросы есть, но ответы контроллер воспринимает как шум.
Повторюсь, при запросе из modbus_client всё работает штатно. Возможно на это могут влиять какие-то параметры шаблона? Возможно frame_timeout_ms?
Какие ответы? Они точно совпадают с ожидаемыми? Выглядит как байты с временем между ними более двух периодов передачи одного байта, что противоречит спецификации Modbus.
Я не могу отследить корреляцию того что прилетает как шум с ожидаемыми ответами, но устройства и шина 100% рабочие и ранее они работали корректно. Сейчас при опросе modbus_client вручную, всё тоже работает хорошо. У меня только два предположения, или в текущей версии изменился парсер шаблона устройств или что-то изменилось в wb-mqtt-serial, поэтому все устройства этого типа отвалились одновременно
Проблема в том, что у меня есть шина на RS485-2, на которой висит порядка 30 устройств и шум может быть из неё, в дебаге не указано какая именно шина шумит.
Спойлер
<7>DEBUG: [port] /dev/ttyRS485-2: Write: 44 46 18 0d 04 01 18 04 01 00 00 01 0f 00 00 01 00 30 12
<7>DEBUG: [port] /dev/ttyRS485-2: Sleep 3629 us
<7>DEBUG: [port] /dev/ttyMOD1: ReadFrame: 0d 03 0e 00 00 00
<7>DEBUG: [port] read noise: 00 00
<7>DEBUG: [port] read noise: ee
<7>DEBUG: [port] /dev/ttyRS485-1: ReadFrame: 0a 03 0e 00 00 00
<7>DEBUG: [port] read noise: 00 24
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: ee 00
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: dc
<7>DEBUG: [port] read noise: 00 59 00
<7>DEBUG: [port] read noise: 25 59 00 00 03 00
<7>DEBUG: [port] read noise: 00
<7>DEBUG: [port] read noise: 86
<7>DEBUG: [port] read noise: fe
<7>DEBUG: [port] read noise: 7f
<7>DEBUG: [modbus] failed to read 1 discrete(s) @ 47 of device </dev/ttyRS485-1 19200 8 N 1> modbus:10: Serial protocol error: malformed response: invalid crc
<7>DEBUG: [serial client] </dev/ttyRS485-1 19200 8 N 1>141270949: Wait until 141270949
<7>DEBUG: [modbus] failed to read 1 discrete(s) @ 11 of device </dev/ttyMOD1 19200 8 N 1> modbus:13: Serial protocol error: malformed response: invalid crc
<7>DEBUG: [port] /dev/ttyRS485-2: ReadFrame: 44 46 18 02 09 00 27 a0
<6>INFO: [serial client] Events are enabled for <modbus:68:input: 280>
<6>INFO: [serial client] Events are disabled for <modbus:68:input: 281>
<6>INFO: [serial client] Events are disabled for <modbus:68:input: 282>
<6>INFO: [serial client] Events are enabled for <modbus:68:input: 283>
<6>INFO: [serial client] Events are disabled for <modbus:68: reboot>
<7>DEBUG: [port] /dev/ttyRS485-2: Sleep 0 us
<7>DEBUG: [port] /dev/ttyRS485-2: Write: 44 03 00 61 00 01 db 41
<7>DEBUG: [serial client] </dev/ttyMOD1 19200 8 N 1>141270957: Wait until 141270957
<7>DEBUG: [port] /dev/ttyRS485-2: Sleep 1528 us
<7>DEBUG: [port] /dev/ttyRS485-2: ReadFrame: 44 03 02 00 01 b4 4b
<7>DEBUG: [register] new val for <</dev/ttyRS485-2 57600 8 N 2> modbus:68:holding: 97>: 1
<7>DEBUG: [serial port driver] channel 'LED Period (s)' of device 'wb-msw-v3_68' <-- 1
<7>DEBUG: [serial client] </dev/ttyRS485-2 57600 8 N 2>141270962: Wait until 141270962
<7>DEBUG: [port] /dev/ttyRS485-2: Sleep 678 us
<7>DEBUG: [port] /dev/ttyRS485-2: Write: fd 46 10 00 f8 00 00 79 5b
<7>DEBUG: [port] /dev/ttyRS485-2: Sleep 1719 us
<7>DEBUG: [port] /dev/ttyMOD1: Sleep 18000 us
<7>DEBUG: [port] /dev/ttyMOD1: Sleep 2005 us
<7>DEBUG: [port] /dev/ttyMOD1: Write: 0d 02 00 0c 00 01 79 05
<7>DEBUG: [port] /dev/ttyRS485-1: Sleep 18000 us
<7>DEBUG: [port] /dev/ttyRS485-1: Sleep 2005 us
<7>DEBUG: [port] /dev/ttyRS485-1: Write: 0b 02 00 0a 00 01 99 62
Обратите внимание, что в первом сообщении в логе от mbклиента устройство именно 0х3 … отвечает.
Я бы вообще взял usb-485 и посмотрел бы шину com port toolkit или подобным.
Ну, там-то и команда 3. И ответ на нее.
То есть тут ничего неожиданного нет. А вот когда на команду 2 возвращается от устройства ответ с 03 - это странное, очень. Как вариант - это ответ на прошлый запрос.
Но - тогда он пришел после таймаута, то есть после умолчальных 100мс, но по короткому куску лога непонятно.
Вы когда запускаете клиент, то wb-mqtt-serial останавливаете?
Может там быстрый модбас или какие-то другие сообщения на шине сбивают ваши устройства? Можно как-то отключить опрос всего лишнего, оставив только эти устройства и шаблон?
Вот этот кусок с ответом 0c 03 0e 00 00 тройкой тоже не логичен - в представленном шаблоне нет запроса такого параметра с таким длинным ответом, в шаблоне всего 1 регистр с функцией 3. Так что это действительно какой-то мусор. Я бы глянул независимым устройством что на шине творится.
Мысль с запросом 02 была здравой, действительно при изменении в шаблоне устройства типа регистра с discrete на holding всё завелось. Загадкой остаётся то, почему до обновления всё работало)
Всем спасибо за помощь