Да, ssh к контроллеру - могу посмотреть.
Вопрос решить не удалось, проблема осталась. Если у кого-то возникнет такая же проблема и найдутся пути решения - просьба отписать в данную тему, буду благодарен.
Устройство не отвечает на часть запросов к нему, к сожалению это не правится никакими настройками.
Откуда такой вывод? Проблема возникает со стороны контроллера. На тестовом стенде производителя все работает корректно. Можно грешить на одно устройство как брак и тд, но у меня их два и ситуация одинаковая. Здесь я все придерживаюсь мнения что проблема была и остается со стороны контроллера Wirenboard.
Собственно поэтому и просьба если у кого-то будет подобная ситуация и получится заставить стабильно работать - отпишитесь, буду только раз победить эту проблему.
Анализ логов, ethernet трафика. Запрос (коррекный) - уходит, в ответ ничего не возвращается. Точнее, не возвращается ответ с каким-то шансом.
Дополню коллегу. Он говорит о том, что устройство часть запросов просто игнорирует. Это не является нормальным поведением для Modbus устройств, поэтому наш драйвер, если устройство несколько раз не ответило, помечает соотв. контролы красным. На стенде производителя все будет работать - производитель все нюансы своего оборудования знает, и может, например, игнорировать неотвеченные запросы. Ответило устройство один раз на пять запросов - ну и слава богу. Поэтому стенд производителя не показатель.
Что бы сделал я:
- Посадил это устройство на отдельный порт.
- Увеличил в шаблоне устройства вот эти значения:
// (При возникновении ошибки) Интервал после последнего успешного обмена данными с устройством,
// по истечении которого (а также "device_max_fail_cycles") устройство будет помечено отключенным и будет опрашиваться в ограниченном режиме
"device_timeout_ms": 3000,
// Количество неудачных циклов опроса устройства
// Если в течение указанного количества полных циклов опроса ни по одному регистру устройства не поступило данных (а также истек "device_timeout_ms"),
// устройство будет помечено отключенным и будет опрашиваться в ограниченном режиме
"device_max_fail_cycles": 2,
- Поговорил бы с техподдержкой производителя словами. Описал ситуацию, что их устройство игнорирует часть запросов. Показал бы документацию по нашему драйверу:
GitHub - wirenboard/wb-mqtt-serial: Wiren Board MQTT serial protocol driver
Попросил бы их помочь правильно настроить драйвер. - Рассказал бы здесь, чем дело кончилось.
- Возможно, что полноценной работы добиться не удастся. Но, если данные все же приходят, то я бы игнорировал периодическое “покраснение” контролов. Создал бы виртуальное устройство, в нем скриптом обрабатывал бы ситуацию полного отсутствия связи (“покраснение” на 5 минут, например). И в интерфейс бы вывел его.
Ну и давайте называть вещи своими именами. Проблема со стороны контроллера - это когда стороннее устройство ведет себя стандартно, а контроллер его не понимает. В вашем случае стороннее устройство ведет себя некорректно, это подтверждается экспериментом.
2 лайка
В данном случае подключение через WB-MIO-E v2 по ethernet, все никак руки не дойдут попробовать напрямую подключить, возможно сам шлюз добавляет проблем.
С производителем уже год веду диалог, перепробовали все варианты, у них уже не осталось совета кроме замены контроллера на другого производителя ) что я собственно делать не собираюсь.
Ну и, для начала я б поменял Modbus over TCP на Modbus TCP, порт на стандарный 502.
Но да, можно радикально, подключить по RS-485. Кстати, а терминатор на шине стоит?
Хорошо, попробую. терминатор стоял, проверю, несколько раз переподключалось может уже и нету.
терминатор нету, а он нужен при таком подключении, от станции до WB-MIO 1 метр, а дальше ethernet кабель уже идет.
Если работет без него - это хорошо. Но лучше ставить всегда, независимо от расстояния.