WB-MSW v.3 - детекция движения, скорость срабатывания

Скорость порта 115200, на линии 17 устройств, (счетчик электроэнергии - 5сек опрос, 5 модулей для штор через WB-MIO, и 10 датчиков msw) на почти всех устройствах стоит время опроса 1 секунда, на некоторых датчиках msw3, где критична скорость срабатывания, я поставил 100мс
Но по факту, датчик движения срабатывает только через 2-3 секунды на любом устройстве.

Вопросы:

  1. как можно замерить производительность линии?
  2. увеличится ли скорость опроса, если упростить шаблоны, убрав из них ненужные значения?
  3. что можно предпринять для оптимизации времени опроса в моем случае?

Из опыта, по 2 пункту однозначно скорость опроса увеличится.
Если есть свободные порты RS-485, повесить на них часть устройств.

у меня и так 4 порта и все распределены…

удалил ненужное, скорость не увеличилась

Возможно, в конфигурации присутствуют модули или параметры, которые по каким-то причинам не доступны (подсвечиваются красным в Settings).
При опросе этих параметров появляются дополнительные таймауты ожидания, что также увеличивает общее время опроса.

По моему мнению, использовать датчик движения при циклическом опросе в Modbus, не удачное решение изначально.

  1. Ну… самый простой вариант - секундомером. Как вариант берёте подключаете кнопку на один вход и один из выходных модулей на этой же шине на соседний. По сработке кнопки запускаете таймер и подаёте команду на включение выхода, подключенного на другой входной канал. По изменению состояния второго входного канала останавливаете таймер.
  2. Да, увеличится. Опрос ненужных регистров будет занимать время. Attention: опрос шестнадцати дискретных каналов индивидуально это в шестнадцать раз медленнее, чем их групповой запрос состояния.
  3. Увеличить скорость сети. Attention: если вы использовали не нормальные кабели для RS-485, а абы что (типа эээ “официально рекомендованных” кабелей для ОПС и СКУД) - скорость, возможно не удастся поднять. Убедитесь, что есть терминаторы на концах линий. Так же некоторые устройства могут не работать на более высокой скорости. Не забудьте сконфигурировать устройства на работу с более высокой скоростью до изменения скорости интерфейса.

На таких “неудачных” решения работает огромное количество систем распределённого ввода/вывода в промышленных АСУ, управляющих промышленными же производствами и переваривающие значительно большее число сигналов. Причём без задержек в пару секунд. Работа “по прерываниям” в физике RS-485 это аварийные события и соответствующие протоколы.

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

Итак, при 18 устройствах средняя задержка 2000-3000мс, максимальная 6000мс.
Если считать в попугаях, то 3-4 шага до срабатывания датчика движения.

Я пробовал разные скорости линии, пробовал отключать девайсы через UI (Enable device), оставлял только 1 на линии, скорость значительно увеличивалась, средняя задержка 1000мс, 600-1500мс. - но все равно это очень и очень много.

Игрался с разными параметрами, тут не все подписаны что делают и за что отвечают:
max_read_registers ставлю 0
device_timeout - 100мс, зачем делать задержку в 3000, если девайс вдруг не ответит
delay before accessing - не понял что это

Не самая лучшая методика проведения замеров, потому что в измеряемое время включается задержка, с которой датчик освещенности заметит включение света.
max_read_registers в целях оптимизации лучше увеличить до 30-50.
max_reg_hole = 20, max_bit_hole = 80.

а где эти параметры установить? поставил датчика max_read_registers = 30
да, со светом не очень получилось, я заметил, что сам датчик намного реже отдает значения, чем датчик шума

В файле шаблона устройства.

Отпишись по результатам исследований, пожалуйста, на сколько удалось повысить скорость?

никакого результата нет, все как было так и осталось, срабатывание крайне медленное
если на линии 1 устройство, то срабатывает в 3-4 раза быстрее , чем 18 устройств

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

При попытки записи в RED LED или Buzzer - не срабатывает, или срабатывает крайне редко. Проблема наблюдается не на всех датчиках.

очень интересно, 3 из 10 датчиков плохо работают, попробую отключить их, надо разбираться

Поборол проблему с неотвечающими датчиками, продолжаю попытки увеличения скорости линии, нашел примерный способ замера скорости, и вот результаты:

скорость ответа от количества датчиков
1 - 8-16 раз в секунду
2 - 2-3
3 - 1-2
4 - 1
16 - 1 ответ в 2-5 секунд…

Что может так тормозить? 1 датчик очень быстро отвечает, 2 - уже сразу заметно медленнее, а 16 - это катастрофа.
Причем многим девайсам прописал опрос раз в 5000мс или 1000мс, оставил 6 быстрых с опросом 250мс - но они не успевают.

Вот дебаг лог, видно, что идет опрос 10 датчиков, опрос занимает 2 секунды и начинает опрашивать устройство, с которого начал, ошибок нет, много регистров поудалял. - Скорость 200мс на устройство, как такое может быть?

messages_copy2.txt (31.6 КБ)

Вот еще интересный момент: при старте порта идет 5 опросов (где co2 лишний, в зеленой рамке, co2 опрашивается со всеми датчиками). В синей рамке видим, что включается фича “disabling holes” и опросов становится больше. Теперь 7 опросов. Может можно было бы это оптимизировать, опрашивать 0-11 регистры сразу. Исключить пустоты. Ведь 4 опроса быстрее, чем 7.

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

2 лайка

подумаем над этим, спасибо

Одни 7 запросов, обведённые красненьким, занимают

1 / 9600  * 11  [бит в байте] * (8 [байт в запросе] + 4 [байт задержка перед ответом]) * 7 [запросов] = 100мс

А ещё есть ответы, которые даже чуть длиннее. Так что всё сходится.

Только скорость линии составляет 57600!
а значит: 1 / 57600 * 11 * 8 + 4 * 7 = 28мс !

А попробуйте вот такую прошивку пожалуйста:msw3-48mh__4.9.2_a1_feature-disable-rts-deassert-delay-workaround_17fb004.wbfw (21.4 КБ)

Ничего не изменилось, 7 опросов на датчик.