О версии пакета wb-mqtt-serial. Какая стоит на WB6?
Для диагностики в данном случае видео - совершенно бесполезно.
Что происходит между ПО и устройством? На контроллере использую для лога трафика обыкновенный tcpdump -i eth0 host 192.168.2.15 -X. Скорей всего для Windows есть какой-то аналог. Нужно чтобы было видно содержимое пакетов и направление передачи.
Нет, на предидущих версиях wb-mqtt-serial логика записи чуть отличалась и была изменена как раз для того чтобы появилась возможность отследить корректную запись.
Если обновите ПО до актуального - поведение будет точно такое же.
Slave обязан в соответствии со стандартом Modbus ответить на какждую посылку мастера.
Если не отвечает - это ошибка, что и отображается в интерфейсе. Ну и попытки записи будут продолжаться 10 минут.
Доброе утро! Ну сказать можно только одно. Запись от Wirenboard прекрасно проходит на контроллер ПУ, но ответ, видимо, теряется или как-то криво обрабатывается. Поэтому и статус красным. На конфигураторе, вижу, ни одного потерянного пакета нет. В конце виде возникла такая ситуация, что контроллер Wirenboard пытается повторными действиями записать значение уставки температуры 27 градусов в контроллер ПУ и, тем самым, “перепахивает” уже новое значение уставки из конфигуратора. В общем, нужно выяснить, что не нравится контроллеру Wirenboard в ответе на запрос записи.
Ну, тут вопрос именно в том, отвечает ли на команду записи устройство. Если по утверждению поддержки (нет повода сомневаться) ответ есть - надо его попробовать поймать. Как я и предлагал выше - проверить с компьютера что ответ приходит. Если действительно, приходит - то что стоит между контроллером и устройством? Хотя, не верю в фильтрацию именно ответов на команду записи.
Подскажите что нужно сделать и как проверить? Какой доступ дать и тд. Провод ethenet идет через свитч передает на WB, промежуточных устройств других нету. Эта же вентиляция без каких либо изменений и настрой работала на WB6, если бы он у меня был, думаю что завелось бы. Явно где-то проблема в новой системе обработки запросов на релизе 2204.
Проверить - просто. Выполните запись в регистр, не обязательно с контроллера, с компьютера или другого устройства - даже лучше и покажите трафик между ним и breezart.
Ну или, как вариант (сложнее) - можно включиться в сеть между контроллером и breezart
Ну и, отдельно, для сравнения - прочитайте тот же регистр.
Система запросов никак не влияет на ответы, на чтение ответы приходят.
Вариант по ссылке выше не подходит? Программа JL Configurator этот как раз между ними на хабе, подключение через тот же Modbus TCP, ошибок не выдает, получается и отправляет ответы корректно. Или это не то что мы хотим проверить?
Я если честно не знаю как еще проверить, здесь явно проблема в запросах с WB идет, несколько лет полет был нормальный, других вариантов просто не вижу.
Не факт что “программа” как-то реагирует на отсутствие корректного ответа.
То есть что происходит сейчас:
на контроллере не получая ответа на запись значения драйвер продолжает попытки записи. При этом значение успешно записывается. Анализ пакетов теорию подтверждает.
из программы-конфигуратора на компьютере ошибок не видно. Хочется проверить - возвращается ли корректный ответ на запись.
Как проверить: Я снял трафик с интерфейса. Рекомендую сделать так же и показать.
Если действительно устройство возвращает корректный ответ - надо разбираться. Как стабильный так и тестинг релизы на правильную работу по Modbus TCP я проверил - ошибок нет. Ну и на вашем контроллере другое оборудование подключено через Ethernet - на нем тоже нет ошибок.
Про “проблема в запросах” - какая? Я тщательно изучил трафик и не увидел отступлений от стандарта. То есть что должно происходить?
Можем сделать проще, я дам вам доступ на виндовс, поставите любую программу и проверите. Я конечный пользователь и на кипер, программист или пусконаладчик. Мне чтобы сделать даже простую мелочь приходится лопатить кучу статей в разных мест.
Все что я могу на данный момент констатировать что проблема появилась после обновления на новый контроллер, целый год на WB6 жили мирно. Либо могу предположить что проблема в новой логике очередности запросов. Подскажите кто и когда сможет подключить как вы говорите в между и протестировать как вам нужно?
В общем могу попробовать разобраться. Давайте RDP, толкьо предваорительно - инструкции мне как с этой системы отправить запрос по Modbus TCP.
Я вижу запрос в сеть. Не вижу ответа на него. Я не понимаю как может быть связана очередность с тем что ответ не получен. Все Modbus TCP устройства - работают.
На этом же контроллере другие Modbus устройства по Ethernet - работают. То есть хотите убедить меня в том что одни устройства работает верно а другое, одно - нет?
