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

[Mike HG]

Время от 20 до 250 мс. И что не так? Влияет сам факт добавления блока. Не зависимо от того запускается он или нет.

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

Время от 20 до 250 мс. И что не так? Влияет сам факт добавления блока. Не зависимо от того запускается он или нет.

Думал, может установлены минимальные значения. То что блок не запущен, не значит что он не оказывает влияния на время цикла, при старте программы время рассчитывается исходя из худших условий, благодаря этому получаем время цикла независимое от того запущен узел логики или нет, как-то так, возможно и таймер так считается, и так как его минимальное время 1ms, то это влияет на общий цикл, а это время в свою очередь на обмен по сети. Этот момент требует уточнения.

[Mike HG]

Возможно Вы не поняли. У меня ПР200 мастер опрашивает один модуль. Частота опросов падает у мастера по мере усложнения программы. Когда программа усложняется настолько, что время цикла увеличивается на 1 мс - частота опросов восстанавливается. При дальнейшем усложнении программы все повторяется. По крайней мере до 4 мс. Влияют как раз таймеры и счетчики. Описывал выше, что при добавлении одного блока частота опросов уменьшалась почти в 2 раза.

[Mike HG]

Какой период запросов стоит на мастере?

65535 мс. Переменную "Запуск чтения" ставлю в 1. Запросы идут с минимально возможным периодом.

Как измеряете частоту ответов?

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

Вообще-то добавление блока не может заметно изменить время цикла.

Реле устанавливает время цикла в зависимости от сложности программы с дискретностью 1 мс. Поэтому по мере добавления элементов время цикла не меняется, а потом с добавлением очередного элемента сразу увеличивается на 1. А вот период опроса с добавлением элементов возрастает, почти пропорционально. На самой границе, когда до увеличения времени цикла остается добавить один элемент - вообще зависает!

[Mike HG]

Думаю попадают, просто не понимают в чем дело. Когда я только начинал использовать в ПР 485 интерфейс, у меня было подобное. Без всякой видимой причины останавливался опрос. Мог проработать 30 сек, а мог несколько часов. Обращался в техподдержку, ничего конкретного не посоветовали. Заменить интерфейс, проверить все соединения, отключить все внешние устройства и подключать по одному, использовать экранированную витую пару для соединений (на длине линии 10 см). Если не поможет, отправить устройство в сервисный центр. Потом само рассосалось.
Период запроса именно такой. greenshot_2018-09-28_07-40-21.png Поставил максимально возможное значение. Запросами управляю с помощью флага "Запуск чтения" переменная R_2. Это запрос конкретного регистра по требованию. Как я понял - исполняется немедленно при установке в 1 и имеет приоритет перед запросами по расписанию. При постоянной 1 запросы идут один за другим без всяких таймаутов. удобная функция, когда с одного устройства нужно запрашивать несколько регистров с разным периодом.

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

65535 мс.
Считываю сетевую переменную, сравниваю ее с нулем, если не равна нулю, значит пришел ответ, запоминаю результат, переменную обнуляю. Замеряю количество циклов между ответами, умножаю на время цикла. Отдельно считаю количество ответов за 1 сек. Засекаю по внутренним часам. Все результаты вывожу на дисплей.

А она точно должна быть "0" если ответ не пришел? Не знаю как у Вас меняется сигнал, но для float можно попробовать сравнивать на неравенство предыдущему значению.

[Mike HG]

Если я ее обнуляю, то она 0. Способ работает. Поначалу пытался сравнивать с предыдущим. Для float нет функции сравнения на равенство. Приходится преобразовывать в int и использовать функцию EQ. При преобразовании в int отрезается дробная часть. А если сигнал меняется в 4 или 5 знаке после запятой? Значит сначала нужно умножить на 100000. И еще в начале темы я уже писал, что у меня модуль не всегда вовремя обновляет данные в регистре, и я просто на очередной запрос получаю такое же значение, и спрашивал, как с этим разобраться. Таким способом я не могу определить - не пришел ответ, или пришел с таким же значением. Теперь момент ответа фиксируется четко. Для измерения сделал на втором ПР "генератор сигнала". С помощью ЦАП на аналоговом выходе сигнал постоянно меняется в заданном диапазоне. Либо смотрю шумы модуля. При 24 разрядном АЦП и отключенных фильтрах в 4-5 знаке шумит очень хорошо.

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

Если я ее обнуляю, то она 0. Способ работает. Поначалу пытался сравнивать с предыдущим. Для float нет функции сравнения на равенство. Приходится преобразовывать в int и использовать функцию EQ. При преобразовании в int отрезается дробная часть. А если сигнал меняется в 4 или 5 знаке после запятой? Значит сначала нужно умножить на 100000. И еще в начале темы я уже писал, что у меня модуль не всегда вовремя обновляет данные в регистре, и я просто на очередной запрос получаю такое же значение, и спрашивал, как с этим разобраться. Таким способом я не могу определить - не пришел ответ, или пришел с таким же значением. Теперь момент ответа фиксируется четко. Для измерения сделал на втором ПР "генератор сигнала". С помощью ЦАП на аналоговом выходе сигнал постоянно меняется в заданном диапазоне. Либо смотрю шумы модуля. При 24 разрядном АЦП и отключенных фильтрах в 4-5 знаке шумит очень хорошо.

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

[Mike HG]

fGT - Сравнение на большее значение. Будет работать, только если сигнал будет изменятся в одну сторону - увеличиваться или уменьшаться. Но он же не может меняться до бесконечности, в конце концов выйдет за пределы диапазона. Поэтому я его меняю периодически вверх - вниз. С шумами тоже не прокатит.

[Mike HG]

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

В общих свойствах мастера нет периода. Если Вы про интервал между запросами, то у меня там 0. Юрий здесь писал, что меньше 8 разницы нет, типа ограничения на уровне железа.