Здравствуйте, имеется 96 MIO-E v.2 модулей с подключенными к ним HVD-8 (да, это снова я).
К 4м из них подключены счётчики MAP3E.
На топиках постоянно возникают ошибки чтения, вроде (пока что) к проблемам не привело, но хотелось бы узнать, нормальное ли это поведение или нет.
Приложил результат работы скрипта, подписанного на /meta/error.
errors.txt (218,9 КБ)
Добрый день.
К сожалению - информация о самом факте возникновения ошибки совершенно ничего не говорит о ее причинах.
Рекомендую посмотреть в логи wb-mqtt-serial. Например Драйвер wb-mqtt-serial — Wiren Board
Какая, кстати, задержка была принята расчетной для шин, какой таймаут сейчас установлен?
И, попробовать опросить то же устройство и те же регистры с помощью Утилита «modbus_client» — Wiren Board
Вот вроде лог wb-mqtt-serial, по крайней мере его часть.
wb-mqtt-serial_20240417T103053.log (1,0 МБ)
По поводу таймаута, вручную он не изменялся, чем стоит руководствоваться при его настройке?
Опрос с помощью modbus_client работает, но в некоторых случаях регистр считывается не с первого раза.
Так, ну что ж… В логе вижу только таймауты.
Итак, нормальный путь запроса: wb-mqtt-serial ставит в очередь сетевого драйвера пакет. Пакет Modbus TCP (или over TCP, это кстати важно) отправляется в ethernet шлюз, где принимается и отправляется в RS485 шину как modbus RTU. Уже WBIO шлюз принимает из шины Modbus RTU пакет - и отвечает на него. Ну и ответ следует обратным путем.
При проблеме на любом этапе - мастер не получит ответа.
То есть:
- запрос может не дойти до slave
- может не дойти ответ slave
- может дойти но позже чем установленный таймаут.
Для начала определить именно сетевую задержку, запустить пинг к шлюзам, к нескольким. Если задержка более 10мс
Вот типичное:
ping 10.0.0.8 -s 20 -R -c 100
PING 10.0.0.8 (10.0.0.8) 20(88) bytes of data.
28 bytes from 10.0.0.8: icmp_seq=1 ttl=62 time=88.2 ms
RR: 10.77.0.101
10.78.0.1
10.0.0.2
10.0.0.8
10.0.0.8
10.78.0.16
10.77.0.1
10.77.0.101
28 bytes from 10.0.0.8: icmp_seq=2 ttl=62 time=59.1 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=3 ttl=62 time=74.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=4 ttl=62 time=74.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=5 ttl=62 time=87.4 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=6 ttl=62 time=80.3 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=7 ttl=62 time=57.4 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=8 ttl=62 time=156 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=9 ttl=62 time=74.8 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=10 ttl=62 time=155 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=11 ttl=62 time=84.3 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=12 ttl=62 time=69.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=13 ttl=62 time=79.3 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=14 ttl=62 time=89.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=15 ttl=62 time=31.8 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=16 ttl=62 time=65.9 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=17 ttl=62 time=66.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=18 ttl=62 time=72.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=19 ttl=62 time=31.3 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=20 ttl=62 time=85.9 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=21 ttl=62 time=85.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=22 ttl=62 time=88.1 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=23 ttl=62 time=60.9 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=24 ttl=62 time=31.0 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=25 ttl=62 time=141 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=26 ttl=62 time=69.5 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=27 ttl=62 time=91.5 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=28 ttl=62 time=58.5 ms (same route)
28 bytes from 10.0.0.8: icmp_seq=29 ttl=62 time=147 ms (same route)
Естественно что если время больше чем установленное в шаблоне ("response_timeout_ms": 100 как пример) то все запросы вернувшиеся после таймаута - будут пропущены.
Тут например их 4 из ~30
Рекомендую продиагностировать - ну и перепроверить расчет.
Пинговал 20 шлюзов -задержка не более 4мс, по умолчанию таймаут 5000мс.
Кажется что не должно быть таймаутов.
Все не так радужно оказалось, получил задержку в 27мс для одного модуля.
Тогда не в таймауте дело, с такой задержкой.
Это нормально, в общем.
Включите debug для wb-mqtt-serrial, пусть поработает с включенным несколько минут и выложите сюда диагностический архив пожалуйста.
приложен диагностический архив, доступен только сотрудникам поддержки
(157,4 КБ)
Мало, в логе всего 2 секунды обмена, выгрузите лог wb-mqtt-serial за пару-тройку минут пожалуйста.
Включал на минут 6, странно
Попробуем этот
приложен диагностический архив, доступен только сотрудникам поддержки
(156,9 КБ)
Нет, в файл выгрузите. В архиве все равно мало, количество строк ограничено.
Около 5 минут лога, 16 мб файл
19 ошибок за 6 минут, если поделить на количество шин - вполне можно считать в пределах нормы.
Ethernet, в общем, не дает гарантии 100% доставки пакетов, целостность (обычно) обспечивается повторной пересылкой.
Т.е. периодическая красная волна в mqtt топиках это не страшно?
Высоковероятно в момент массовых ошибок в сети что-то происходит, возможно какое-то оборудование занимается широковещаниемм. Для проверки можно отключить сеть с контроллером и шлюзами, изолировать ее.
Проверил. Использовал массовый flood в сегмент сети к которой подключен интерфейс контроллера и два шлюза. Да, вызывает ошибки.