Здравствуйте! при попытке подключить С2000ПП ко второму каналу RS485 выяснилось следующее: установка времени таймаута никоим образом не влияет на его значение по ЛОГ файлу. Например: при установке в 200мс в логе идет указание на 9000 мкс. и соответственно, поскольку сам С2000ПП имеет задержку на ответ около 35 мс(по осциллографу), драйвер вылетает по тайм ауту. Посылка не принимается. При этом некоторые посылки все же доходят. Возможно нет синхронизации счетчиков времени.
Как исправить?
Похожую проблему решил, подбирая значения.
Здравствуйте!
Посмотрите пожалуйста вот эту тему про подключение прибора конвертера С2000-ПП:
Параметр guard_interval_us значением 50000 помог решить проблему.
Также для информации вот ссылка на инструкцию по подключению сторонних устройств:
https://wirenboard.com/wiki/WB_FAQ/thirdparty-modbus-devices-conection
1 лайк
Судя по ЛОГУ параметр guard_interval_us обеспечивает задержку перед отправкой запроса в канал связи. Зачем? Есть же интервал полинга. Надо правильно отрабатывать задержку тайм аута. Должно быть: мастер отправляет запрос в канал связи, выдерживает 3,5 интервала , включает таймаут, и если ответа от устройства нет - выдает признак ошибки “таймаут” и идет к следующему. Так понятно и логично. А судя по логу ??? зачем везде ждать 9 мс? Зачем в настройках порта задавать время Response Time out,если драйвер прибора на нее никак не реагирует? Есть спецификация протокола modbus RTU, давайте будем её придерживаться.
Всё происходит так, как вы описываете. Возможно, вас вводит в заблуждение строка Sleep: 9000us? Это время ожидания отправки пакета в шину в мс. В логе нет информации о времени ожидания ответа. Есть только сообщения об ошибке, если истёк таймаут ожидания.
В текущем драйвере сделана оптимизация при работе с modbus. Если к одному и тому же устройству идёт несколько последовательных запросов, они отправляются без ожидания 3,5 символов после ответа. Наши и многие другие устройства корректно реагируют на такие запросы, так мы можем полнее использовать шину. Но это не по стандарту. Если устройство строго следует стандарту, мы рекомендуем использовать guard_interval_us, как предложили выше.
1 лайк
Тогда Вы вводите в заблуждение пользователя. У меня прибор отвечает через 35 мс после отправки ему запроса. и в логе я ожидаю увидеть эту задержку после запроса мастера. ,а она стоит ДО. Но примочка помогла, мигание красным у параметров прекратилось(кстати это не нашел где описано - что ошибка).
правильно ли я понимаю, что у Вас guard стоит до запроса(судя по логу). Мне не понятно зачем До? перенесите в логе ее ПОСЛЕ, будет логично.
И почему не работает задержка Response Time Out ?
Кстати, недавно нашёл в вики красивую картинку с интервалами, на всякий случай скину:
1 лайк
Задержка должна работать. Но дело в том, что после ожидания и успешного получения ответа от устройства, контроллер может сразу отправить новый запрос на чтение следующего регистра. А ваше устройство его не примет, так как не выдержан нужный интервал. Для этого служит параметр guard_interval_us.
Получается ,что WB требование о интервале 3,5 после запроса заменено на 0 для более быстрой работы Ваших контроллеров. Для чужих надо ставить самому Guard_interval. Ну тут понятен порядок Ваших рассуждений. не совсем точно , но выдержано соответствие протоколу.
Но пока я вижу, что response time out корректно не работает. и в логе нет сообщений о соответствующей ошибке. Вы говорите, должна, а я не вижу. Как проверить? Если я ставлю Response 200мс, то я не должен видеть следующего запроса от мастера, пока не пройдет интервал в 200мс, при условии, что прибор не отвечает, Надеюсь программисты, которые драйвера пишу просматривают трафик по каналу при помощи осциллографа.
Просто путаница в терминологии.
По истечении этого таймаута вывалится ошибка, что дивайс не ответил.
А то, что Вам надо, называется почему-то frame_timeout, хотя должно бы - delay_before_request.
Да, все так и есть. Вот логи из актуальной версии ПО (добавил свои комментарии после знака #):
Oct 29 15:28:26 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Sleep 0 us
Oct 29 15:28:26 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Write: c3 06 00 71 00 0a 49 34 # Запрос к отсутствующему устройству, response timeout = 2000 мс
Oct 29 15:28:26 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Sleep 10000 us
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: WARNING: [modbus] failed to write: <modbus:195:holding: 113>: Serial protocol error: request timed out # прождали 2 с - ответа не дождались, выдали сообщение
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Sleep 8000 us
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [modbus] read 2 input(s) @ 32 of device modbus:81
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Sleep 0 us
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Write: 51 04 00 20 00 02 7c 51 # следующий запрос к подключенному устройству произведен только через 2000 мс
Oct 29 15:28:28 wirenboard-ATHXPBSP wb-mqtt-serial[23842]: DEBUG: [port] Sleep 10000 us
Если включаете отладочные сообщения для диагностики проблемы, то, пожалуйста, не забудьте их отключить - иначе размер лог-файлов будет очень большим.
Спасибо Всем , перепроверю. прошлый раз было не так…