Разброс во времени опроса по RS-485.

[Mike HG]

Здравствуйте. Опрашиваю на ПР200 модуль аналогового ввода WAD-AIK-BUS компании "Акон" протокол ModBus RTU, скорость 115200, расположены рядом. Модуль имеет четыре канала, значения в формате float. Для двух каналов нужна скорость опроса минимум 15 Гц. Устанавливаю период опроса 65 мс, таймаут ответа 10 мс. Измеряю и вывожу на дисплей время между изменениями сетевой переменной для одного из каналов. От 3 до 10 запросов проходят нормально, примерно 65 мс, потом пропуск - время 130 мс. Если увеличить период опроса, то пропуски становятся реже. При 100 мс пропуски через 2-5 сек. При 130 мс пропусков нет. От количества опрашиваемых каналов не зависит. Опрашивал один к***** два и четыре - результат одинаковый. Как определить кто виноват? Реле не успевает опрашивать, модуль не успевает обновлять значения в регистрах, или я что-то не так настроил? Время цикла 1 мс. На этой же линии висит модуль МУ110-225.6У, но он пока не опрашивается, адреса разные. По идее мешать не должен.

[Филоненко Владислав]

Судя по временам, у вас периодически нет ответа на запрос либо ПР не успевает формировать запросы. Снифер подскажет где проблемы.
Также можно протестировать ПР с эмулятором slave на PC.

[Ревака Юрий]

Здравствуйте. Опрашиваю на ПР200 модуль аналогового ввода WAD-AIK-BUS компании "Акон" протокол ModBus RTU, скорость 115200, расположены рядом. Модуль имеет четыре канала, значения в формате float. Для двух каналов нужна скорость опроса минимум 15 Гц. Устанавливаю период опроса 65 мс, таймаут ответа 10 мс. Измеряю и вывожу на дисплей время между изменениями сетевой переменной для одного из каналов. От 3 до 10 запросов проходят нормально, примерно 65 мс, потом пропуск - время 130 мс. Если увеличить период опроса, то пропуски становятся реже. При 100 мс пропуски через 2-5 сек. При 130 мс пропусков нет. От количества опрашиваемых каналов не зависит. Опрашивал один к***** два и четыре - результат одинаковый. Как определить кто виноват? Реле не успевает опрашивать, модуль не успевает обновлять значения в регистрах, или я что-то не так настроил? Время цикла 1 мс. На этой же линии висит модуль МУ110-225.6У, но он пока не опрашивается, адреса разные. По идее мешать не должен.

Добрый день, нужны скрины настроек, есть еще в настройках "Интервал между запросами" его можно уменьшить до 1-2 ms, таймаут ответа лучше увеличить.

[Одесса]

Добрый день, нужны скрины настроек, есть еще в настройках "Интервал между запросами" его можно уменьшить до 1-2 ms, таймаут ответа лучше увеличить.

Разрешите с Вами не согласиться. Представьте себе, я поставлю интервал между как Вы рекомендуете 1mc. Скорость
115200, т.е в секунду передается 11520 байт. Для простоты расчета округляем до 10000 байт/сек. Т.е. 1 байт передается за 100
МКС. Запрос состоит,как минимум из 8 байт- 6 байтов команды+2 байта контрольной суммы. Итого 8 байт запроса. Время прохож
дения запроса = 8х100=800мкс= 0.8 мс. Служебные биты не учитываю. Т.е. время на прохождение запроса стоит на грани времени
между запросами. В результате описанная ситуация. Даллее. Нужно время для получения ответа. Рассчитываем его. Так,как формат
флоат, а это 4 байта. В ответе присутствует на 1 байт больше чем в запросе т.е. 9 байт. Всего 8+9=17 байт. На запрос и получение
ответа необходимо 17х100мкс=1700 МКС= 1.7мс. И это при условии ,что устроство ответит мгновенно. Но такого в реальной жизни
не бывает. Поэтому прибавьте ,как минимум 1мс. Получаетя,как минимум 3мс. А Вы ему собираетесь лупить запросы каждую
миллисекунду. А ,если прибор вообще задумчивый и миллисекунд 40 соображает(что похоже по описанию автора) Вот пусть автор
Вопроса и ставит свои 130мс и не морочит себе голову. Единственное решение для задающего вопрос по уменьшению времени
опроса-это разобраться с ответчиком,почему он так долго отвечает. Во многих приборах Овен, время ответа можно изменять в кон
фигураторе. Может и его устройство имеет такое свойство.
Т.е нужно сделать наоборот,как Вы советуете. Интервал между запросами увеличить, а тайм
акт ответа уменьшить.

[Ревака Юрий]

Разрешите с Вами не согласиться. Представьте себе, я поставлю интервал между как Вы рекомендуете 1mc. Скорость
115200, т.е в секунду передается 11520 байт. Для простоты расчета округляем до 10000 байт/сек. Т.е. 1 байт передается за 100
МКС. Запрос состоит,как минимум из 8 байт- 6 байтов команды+2 байта контрольной суммы. Итого 8 байт запроса. Время прохож
дения запроса = 8х100=800мкс= 0.8 мс. Служебные биты не учитываю. Т.е. время на прохождение запроса стоит на грани времени
между запросами. В результате описанная ситуация. Даллее. Нужно время для получения ответа. Рассчитываем его. Так,как формат
флоат, а это 4 байта. В ответе присутствует на 1 байт больше чем в запросе т.е. 9 байт. Всего 8+9=17 байт. На запрос и получение
ответа необходимо 17х100мкс=1700 МКС= 1.7мс. И это при условии ,что устроство ответит мгновенно. Но такого в реальной жизни
не бывает. Поэтому прибавьте ,как минимум 1мс. Получаетя,как минимум 3мс. А Вы ему собираетесь лупить запросы каждую
миллисекунду. А ,если прибор вообще задумчивый и миллисекунд 40 соображает(что похоже по описанию автора) Вот пусть автор
Вопроса и ставит свои 130мс и не морочит себе голову. Единственное решение для задающего вопрос по уменьшению времени
опроса-это разобраться с ответчиком,почему он так долго отвечает. Во многих приборах Овен, время ответа можно изменять в кон
фигураторе. Может и его устройство имеет такое свойство.
Т.е нужно сделать наоборот,как Вы советуете. Интервал между запросами увеличить, а тайм
акт ответа уменьшить.

Одесса, очень хорошо что вы подробно вникаете в суть вопроса, и делаете выкладки по расчетам, которых иногда очень не хватает. Но, я писал не про период опроса, а про интервал между опросами, это другой параметр и отвечает он за паузу на переключение с режима приема на передачу. А если мы говорим за период опроса, то прибавить 1ms, как Вы советуете, это будет маловато даже на 115200. Если нет данных на модуль по времени ответа, нужно подбирать.

[Одесса]

Одесса, очень хорошо что вы подробно вникаете в суть вопроса, и делаете выкладки по расчетам, которых иногда очень не хватает. Но, я писал не про период опроса, а про интервал между опросами, это другой параметр и отвечает он за паузу на переключение с режима приема на передачу. А если мы говорим за период опроса, то прибавить 1ms, как Вы советуете, это будет маловато даже на 115200. Если нет данных на модуль по времени ответа, нужно подбирать.

Хочу добавить к своей теории немного соображений из практики. Года два назад делал для своих личных нужд адаптер
типа АС4. В адаптере использовал процессор микрочиповский 16F628 с юартом на борту и классический MAX485. Прибор опрашивал МВ110-8АС. После передачи команды ( програмно отслеживал освобождение буфера передатчика) и по его освобождении ,моментально (один такт просессора) переключался на прием. По моим наблюдениям ответные данные приходи
ли через 13 мс после того,как переключился на прием. Учитывая результаты этого эксперимента,следующие адаптеры делал без
применения микропроцессора. Вместо него поставил тупо 555 таймер посхеме ждущего мультивибратора,который управлял
переключением прием-передача МАХ485. Время задающая цепочка ждущего мультивибратора 10мс. При помощи этого адаптера
снимал информацию с ТРМ 138 без проблем. Что касается ПР 200, что могу только предполагать( реверс-инженеринг ему не де
дал). Разработчики этого прибора Вам могут ответить через сколько времени прийдёт ответ только в том случае,если входные
данные вызывают прерывание. Тогда можна говорить о конкретном времени ответа. Если же механизм прерывания в этом
приборе отсутствует, то время ответа будет переменным и будет зависеть от времени цикла основной программы.

[Mike HG]

"Интервал между запросами" стоит 0. Вообще каких либо изменений от этого параметра не заметил. Таймаут ответа подобрал экспериментально - меньше 4 начинает терять данные, выше 4 никаких изменений нет. Вот скрины.
greenshot_2018-09-07_14-14-09.png greenshot_2018-09-07_14-15-45.png

[Ревака Юрий]

"Интервал между запросами" стоит 0. Вообще каких либо изменений от этого параметра не заметил. Таймаут ответа подобрал экспериментально - меньше 4 начинает терять данные, выше 4 никаких изменений нет. Вот скрины.
greenshot_2018-09-07_14-14-09.png greenshot_2018-09-07_14-15-45.png

Нулевое значение может и не стоит делать, я бы 1 ms оставил, получается Ваш модуль отвечает за ~4 ms, что в описании на него по этому поводу сказано?

[Ревака Юрий]

А если читать в INT16, если я правильно понял, там есть и такие регистры. Когда-то было подобное обращение по этим же модулям, у клиента около 20 выборок получалось.

[Mike HG]

Интересно, почему лучше 1 мс и не стоит делать 0? В описании на модуль ничего не сказано про время ответа. Есть частота опроса 30 Гц, только не уточняется, для каждого канала или делится на 4. В техподдержке тоже озвучили цифру 20, которую они реально получили при испытаниях. У меня, если поставить период опроса 50 мс, получается 14-18. То есть от 2 до 6 запросов значения повторяются. Вообще непонятно, как в цифровых устройствах могут получаться большие разбросы временных интервалов? Кстати, у ПР200 какое минимально возможное время опроса одного регистра, есть данные? И зависит ли оно от времени цикла? Если например сложная программа и время цикла 4 мс, будет ли время опроса больше? В INT16 пробовал, почти тоже самое. При периоде опроса 100 мс мне показалось, что пропусков немного меньше, при 65 мс примерно также. Вообще этот модуль 24-х разрядный, и при передаче результатов в INT16 это преимущество теряется.