Особенности работы драйвера wb-mqtt-serial

Добрый день! В документации драйвера wb-mqtt-serial, а именно в разделе “Таймауты и количество неудачных циклов” описано как драйвер “позволяет тратить меньше времени на отключенные устройства”.

У меня для теста три одинаковых устройства на одном порту WB RS485 с адресами 1, 2 и 3 соответственно, у каждого устройства один Coil и один Holding, настроены с использованием шаблона.

Вопросы:

  1. как сделать так, чтобы устройство попавшее в ограниченный режим опроса драйвером опрашивалось только по одному регистру (конкретному назначенному или первому в очереди опроса на данном этапе нет разницы).

  2. При ошибке опроса драйвер следующий опрос такого устройства совершал через несколько циклов или через некоторое время. В идеальном варианте, чтобы драйвер ставил в отдельную очередь отсутствующие устройства и от попыток их найти в сети “не страдали” другие устройства, с которыми есть связь.

В шаблоне устройства добавил раздел “setup” с указанием регистра holding для попытки записи конкретного значения, но разницы в поведении драйвера не заметил. Каждый цикл происходит опрос всех устройств, их регистров с ожиданием ответа (500мс). Прикладываю изображение опроса, который повторяется с отключенными устройствами на 2 и 3 адресах, устройство с адресом 1 в сети и отвечает, но время между опросами такого устройства в сети не радует.

Оборудование: WB 8.4.4, релиз wb-2501
Устройства для теста виртуальные.


Добрый день.
Перечитал документацию, потыкал в стенд.

Такой возможности нет.
Логика описана тут - то есть устройство помечается отключенным ели ни один регистр не ответил.

А для чего такое может быть применено? Отсутствие устройства - авария.

Добрый день!

Такой возможности нет.
Логика описана тут - то есть устройство помечается отключенным ели ни один регистр не ответил.

Логику именно из этого ресурса и брал.

А для чего такое может быть применено? Отсутствие устройства - авария.

Отсутствие одного устройства замедляет опрос остальных, что еще в сети.

В других контроллерах с которыми работал было такое и в тех, где есть возможность на уровне кода выключать опрос устройства, которое не отвечает или отвечает с ошибками, применял аналогичный алгоритм.

Для каждой линии связи (RS485-1, RS485-2 и т.д.) можно задавать отдельные настройки.
Пример таких настроек прикладываю:

Где:
Detection Interval (s): seconds to wait when a server device is marked as Offline and a retry to check if the server device is back online
Retries: numbers of retries to do to set a server device as offline
Last Polling Loop Time (ms): the linked variable will contain the duration of the last polling cycle
Number of Polling Loops: the linked variable will contain how many polling loops have been executed since the start of the application
Polling Delay (ms): time to wait before starting a new polling cycle, this is used to slow down the polling rate

Важное тут то, что аварийное устройство, которого может еще нет на объекте или оно обесточено, опрашивается редко, не все регистры и необходимое количество раз, чтобы уйти на таймаут до следующей попытки (в примере - 20 сек).

У себя в алгоритме я создаю очередь из таких аварийных устройств, которые поочередно с заданным интервалом (обычно 2-5 сек) опрашиваются. Ключевое - поочередно.
Результат такого опроса:

  1. устройство попадает в обычный опрос
  2. устройство попадает в конец очереди опроса аварийных
    *Если аварийное устройство одно, то его с таким интервалом и ищу.
    **При первом запуске опроса, аварийных устройств еще нет, опрашиваю сразу всех.

При таком алгоритме аварийные устройства рано или поздно будут подключены к обычному опросу, а остальные запросы не страдают от такого метода поиска устройств в сети.

В расширении протокола modbus под названием «Быстрый Modbus» используются широковещательные команды, которые позволяют обойтись без поочередного опроса каждого регистра. При таком подходе к опросу устройств в сети и вопросов не возникает, всё быстро работает.

Если подскажете как выключать устройства из опроса и не перезаписывать *.conf файлы системы, буду очень рад.
Остальное напишу сам.

Заранее спасибо!

Добавил в список предложений.

Только на таймаут ответа, который можно выставить в 3мс, например.

Сейчас нет управления опросом через RPC. Точнее можно - но методы не документированы.