обновлен контроллер сегодня.
Вопрос в следующем:
При физическом отключении устройства от modbus мы получаем meta тег error = r практически моментально. Хотя по логике хотелось бы его получить после 10 неответов по 500 мс, то есть через 5 секунд. У нас есть подозрение, что мы получаем ошибку модбас с первой же неудачной попытки чтения данных с устройства. И нам от этого плохо.
Добрый день.
Да, meta меняется при первой ошибке.Это как раз верное поведение.
Логично при ошибке получать уведомление немедленно. Если нужна задержка - она реализуется программно при необходимости.
А вот в чем логика? тогда мета надо делать 2 значения. warning и error. Почему я должен программно отслеживать то, для чего был написан mqtt serial, который работает в режиме реального времени и имеет для этого все возможности и даже настройки. Но я не хочу падать в ошибку как только по модбас проходит сбой одного пакета. И я не хочу запускать таймеры, которые будут грузить и так загруженную систему. Я хочу получать ошибку, когда mqtt serial точно установил факт невозможности соединения с устройством в соответствии со своими настройками.
Вот прям очень удивился ответу. При написании кода исходил из другой логики. Проблем не возникало из-за идеальной работы модбас, видимо…
Пошли писать код с поддержкой таймаута
wb-mqtt-serial - это драйвер, не его дело вести статичтику. Ошибка - он рапортует. А прикручивать к нему еще ведение статистики - это ИМХО излишне.
Статистики тут нет. Но давайте для примера вспомним как ведет себя драйвер HDD на плохом кластере. Он внутри себя пытается раз 5 прочитать данные, и только в случае полной неудачи передает ошибку наверх, в приложение. И количество попыток чтения прописано где-то в настройках драйвера. И уж если не смогла, то не смогла. Тогда ошибка уходит в приложение верхнего уровня.
Но это полемика ни о чем. Я бы послушал альтернативные мнения, но похоже никто с такой проблемой особо не сталкивался. Либо алгоритмы там другие.
Буду все равно стучать в вас с этой проблемой.
Вот сейчас, при подключении WB к MasterScada подобная логика передачи ошибок дает о себе знать в полный рост. У нас демочемодан. Там на втором модбасе висит MAP12 и Милур 305. Они вроде и работаю, но сыпят кучей ворнингов в логи по ошибкам шины. Каждый такой ворнинг отдается в скаде ошибкой связи в модальном окне и требованием квитирования данного сообщения оператором. При этом специалисты WB всегда говорили, что единичные ошибки на ModBus дело нормальное и не является поводом для паники. Согласен. Но тогда хотелось бы иметь флаг, что устройство (канал устройства) недоступны именно по таймауту и превышению количества попыток связи, которые определяются в конфиге mqtt-serial, а не по любой разовой помехе пробежавшей по шине.
Это не задача СКАДА системы контролировать таймауты и количество неудачных обращений к модбас устройствам. Это задача mqtt-serial (либо любого другого драйвера).
root@wirenboard-AQ75RAPC:/etc/apt/sources.list.d# journalctl -f | grep mqtt-serial
Aug 29 10:56:07 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:56:08 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: invalid crc [slave_id is milur:25]
Aug 29 10:56:14 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [modbus] failed to read 4 input(s) @ 4284 of device modbus:23: Serial protocol error: malformed response: invalid crc
Aug 29 10:56:22 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [modbus] failed to read 8 discrete(s) @ 0 of device modbus:56: Serial protocol error: malformed response: invalid crc
Aug 29 10:56:26 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:56:29 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:56:39 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:56:45 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:56:49 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [modbus] failed to read 6 input(s) @ 32 of device modbus:68: Serial protocol error: malformed response: invalid crc
Aug 29 10:56:53 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: invalid crc [slave_id is milur:25]
Aug 29 10:57:02 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [modbus] failed to read 14 input(s) @ 270 of device modbus:21: Serial protocol error: malformed response: invalid crc
Aug 29 10:57:04 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:57:17 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:57:21 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:57:30 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: request timed out [slave_id is milur:25]
Aug 29 10:57:35 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [serial device] TSerialDevice::ReadRegister(): Serial protocol error: invalid crc [slave_id is milur:25]
Aug 29 10:57:43 wirenboard-AQ75RAPC wb-mqtt-serial[6736]: WARNING: [modbus] failed to read 14 input(s) @ 270 of device modbus:21: Serial protocol error: malformed response: invalid crc
Мы сейчас рассуждаем о работе с использованием OPC UA. Там по OPC признак достоверности передается внутри самого OPC протокола. И Скада реагирует именно на этот признак. А признак берется сквозняком из mqtt-serial.
Правила wb-rules в данном случае в процессе никак не участвуют. Это лишний слой в данном случае.
Я запишу это в пожелания.
Добавлено в текущей версии шлюза, тема: OPC UA, MODBUS и MasterScada нет сквозной передачи признака достоверности - #29 от пользователя PeteK