Здравствуйте, раньше использовали модули WB-MWAC и все работало нормально, сейчас при сработке датчика протечки реле(К1 и К2) срабатывают с задержкой около 5-10 секунд.
В чем может быть проблема?
Здравствуйте!
То есть модуль работал нормально какое-то время, а потом возникла эта проблема? Или вы приобрели новые модули и заметили в них такую особенность?
Пришлите, пожалуйста, фото наклейки с серийным номером проблемного модуля. Производилась ли дополнительная настройка модулей после покупки?
Проверьте, как срабатывают реле на модуле, замыкая соответствующие входы модуля проводом на клеммниках (клеммы Fx и iGND), чтобы исключить сами датчики протечки.
Приобрели новые модули и в них заметили такую особенность.
Дополнительная настройка проводилась, управление сработкой сделано через скрипт:
Менялись также регистры:
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r384 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r385 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r386 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r387 4;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r388 4;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r389 4;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r392 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r393 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r400 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r401 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r408 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r409 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r410 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r416 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r417 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r418 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r424 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r426 0;
modbus_client --debug -mrtu -pnone -s2 /dev/ttyRS485-1 -a10 -t0x10 -r425 0;
Замыкаю проводом на клеммниках, диод у F1 загорается сразу, а реле К1 срабатывает с задержкой.
На прошлых объектах с точно такой же настройкой все работало штатно
Но зачем обрабатывать программно? Это решение делает неработоспособным систему при выклченном контроллере.
По теме вопроса - сколько устройств на шине, нет ли ошибок опроса, как заданы приоритеты?
Есть функционал, который не реализовать без программной обработки.
Устройство одно, при опросе ошибок нет, приоритет не задавал.
Подпишитесь на топики, через какое время публикуется новое состояние после замыкания-размыкания?
От 5 до 10 секунд
Интересуюсь просто для расширения кругозора. А о каком функционале идет речь?
Так, а как сейчас настроен порт и опрос устройства? покажите wb-mqtt-serial.conf потом запустите с включенным debug и покажите вывод, с периодом когда изменяется состояние входа.
До этого когда тестировал удалял и отключал остальные устройства и использовал только модуль wb-mwac, но видимо как то старые устройства не до конца удалились.
В данный момент если использовать только модули wb-mwac, то все работает нормально, но как только начинаю добавлять еще устройства по modbus(mrc6, несколько диммеров mdm3), то с добавлением каждого устройства немного увеличивается задержка. И в итоге если к модулям добавлено еще 10 устройств задержка на сработку около 8-10 секунд.
Опрос устройств установлен “в порядке очереди”
Это настройки порта:
Покажите полностью настройки порта, лучше файл wb-mqtt-serial.conf целиком.
Ну и лог опроса.
Конфиг:wb-mqtt-serial.conf (3.2 КБ)
Лог такого типа нужен? :
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial client] </dev/ttyRS485-1 9600 8 N 2>19145160: Wait until 19145191
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 02 00 00 00 01 b8 b1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 02 01 00 a3 ac
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 02 00 01 00 05 e8 b2
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 02 01 04 a2 6f
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [register] new val for <modbus:10:discrete: 3>: 1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial port driver] channel ‘F1’ of device ‘wb-mwac_10’ ← 1, error: “”
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial port driver] setting device register: <modbus:10:coil: 0> ← 1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial port driver] setting device register: <modbus:10:coil: 2> ← 1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 21 02 00 00 00 01 be aa
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 21 02 01 00 aa 48
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [modbus] write 1 coil(s) @ 0 of device modbus:10
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 05 00 00 ff 00 8d 41
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 05 00 00 ff 00 8d 41
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [register] new val for <modbus:10:coil: 0>: 1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial port driver] channel ‘K1’ of device ‘wb-mwac_10’ ← 1, error: “”
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [modbus] write 1 coil(s) @ 2 of device modbus:10
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 05 00 02 ff 00 2c 81
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 05 00 02 ff 00 2c 81
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [register] new val for <modbus:10:coil: 2>: 1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial port driver] channel ‘Alarm’ of device ‘wb-mwac_10’ ← 1, error: “”
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 02 00 00 00 01 b8 b1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 02 01 00 a3 ac
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0b 04 00 20 00 01 30 aa
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0b 04 02 00 3b 60 e2
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 26 03 00 01 00 01 d3 1d
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 26 03 02 00 04 8d 80
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [serial client] </dev/ttyRS485-1 9600 8 N 2>19145435: Wait until 19145440
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 0a 02 00 00 00 01 b8 b1
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] ReadFrame: 0a 02 01 00 a3 ac
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 8000 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 0 us
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Write: 21 02 00 01 00 01 ef 6a
Sep 23 16:36:43 wirenboard-AIKG4CTX wb-mqtt-serial[5792]: DEBUG: [port] Sleep 10000 us
Из лога видно что discrete input 01-05 устройства 0xa был за секунду прочитан 4 раза.
Я не вижу ошибок или задержек.
то есть:
нули
поднят dinput 0x03:
Установлены состояния выходов
Опять нули:
То есть утвержение о “задержках” - несостоятельно.
Да с логах выглядит как будто все работает штатно, но по факту срабатывает с задержкой
Вот ссылка на видео работы:
Видео просмотрел, естественно.
И на каком этапе обработки задержка?
После замыкания F1 , реле К1 замыкается только примерно через 5 сек.
Да, я и прошу показать сколько времени занимает обработка какждого события в цепочке. Поскольку воспроизвести именно такое поведение не удается.
Не совсем понимаю как именно я могу вам показать время обработки каждого события в цепочке
Покажывать как раз не обязательно, достаточно просто определить - какое время каждый этап занимает.
Ведь все очень прозрачно:
- изменение физического состояния
- чтение состояния wb-mqtt-serial
- публикация в топик входа
- выполнение правила
- публикация состояния в топик реле
- запись в устройство
- изменение физического состояния.
Все, кроме первого и последнего можно записать в лог, проверить.
Либо - дайте пример воспроизводящий подобное.
Здравствуйте, решили проблему установкой опроса в 1000мс на каналы куда заходят датчики