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

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

Я бы раз так сделать, да по условию задачи не проходит. 100% достоверные данные получаются при времени между запросами 130 мс, а мне надо минимум в 2 раза чаще.

Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.

Я хочу понять, реле не успевает опрашивать, или модуль отдает с перебоями.

Используйте переменные статуса для модуля и переменных, для контроля обмена.

Еще не так давно сопрягал ПР200 с модулем ICP, у которого период опроса 100 мс и была такая же проблема с пропусками, которые исчезали при тех же 130 мс. Наводит на размышления. Сформулирую вопрос по другому. Какое минимально возможное время опроса может обеспечить реле, при условии, что модуль будет отвечать вовремя? При времени цикла 1, 2 и 4 мс.

Период опроса или все же время ответа, если у модуля время ответа 100ms, то и тайм аут и период опроса должны быть больше этого значения.
Время на прием одного пакета будет: время пачки на запрос+ "вовремя"+время пачки на ответ+ 3.5 симовла на соответствующей скорости.

Где найти подробное описание работы ПР200 по RS485, чтобы учитывать все факторы?
Если по истечении времени опроса сетевая переменная не изменилась, можно ли узнать - модуль ответил вовремя и вернул такое же значение, или запрос (ответ) не прошел?

В руководстве пользователя есть информация, но она не настолько глубокая, как хотелось бы. Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.

[Mike HG]

Вы так и не ответили на каком проекте значения периода 130 ms, на "чистом" или с временем цикла 4 ms? приложите его в тему.

Так Вы об этом не спрашивали. Полный проект большой, время цикла 4 мс. Пока провожу эксперименты по получению данных на "чистом" проекте, с временем 1 мс, 130 мс на "чистом". Вот проект. Измерения делаются в циклах. С переменными статуса пробовал. Статус модуля всегда в 1. Если какой-то запрос не пройдет, он наверное падает в 0, но на следующем запросе снова встает в 1. Как увидеть 0? По статусу переменной вообще непонятно, там целое число, и у меня всегда было 0. Как с ним обращаться? Сколько кстати сохраняется статус, до следующего запроса или ответа?

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

Так Вы об этом не спрашивали. Полный проект большой, время цикла 4 мс. Пока провожу эксперименты по получению данных на "чистом" проекте, с временем 1 мс, 130 мс на "чистом". Вот проект. Измерения делаются в циклах. С переменными статуса пробовал. Статус модуля всегда в 1. Если какой-то запрос не пройдет, он наверное падает в 0, но на следующем запросе снова встает в 1. Как увидеть 0? По статусу переменной вообще непонятно, там целое число, и у меня всегда было 0. Как с ним обращаться? Сколько кстати сохраняется статус, до следующего запроса или ответа?

Ок, если завтра время позволит, проверю обмен на наших модуляx расширения, по умолчанию у них время ответа 2 ms.

[Одесса]

Ок, если завтра время позволит, проверю обмен на наших модуляx расширения, по умолчанию у них время ответа 2 ms.

После проверки отпешитесь пожалуйста. Потому ,что любопытная ситуация. Я предполагаю ,что у Овеновских модулей все
получится. Для интереса посмотрел модули ,которые автор цепляет к ПР ,так у них сложный алгоритм обработки аналогового
сигнала. Предполагаю,что этот специфический алгоритм занимает много времени и в результате такой долгий ответ. Предполагаю
также,что автор сам задал эту длительную обаботку аналогового сигнала, хотя производители этих модулей предлагают и короткую
обработку,чем автор вопроса не воспользовался. Ставлю 3 к 1.,что на Овеновских модулях все будет ОК.

[Mike HG]

С этого момента можно по подробнее? Что за длительная или короткая обработка, и где она задается?

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

И так, провел серию опытов, еще вчера для быстрой проверки настроил ПР200 мастером, и через AC4 подключил к эмулятору слейва на ПК:


Видно опрос 2 float, по адресу 512 и 514, так как группового запроса нет, идет 2 запроса подряд. Ставил минимальное время 10 ms, таймаут ответа поставил 100 ms. Обмен стабильный, ошибок нет.

Затем, уже сегодня подключившись анализатором, посмотрел, за какое время приходят ответы. Видно, что от ПК с симулятором ответ приходит через ~30ms, сами посылки запрос/ответ на этом фоне занимают очень мало времени, ~0,7ms. Весь пакет запроса одного регистра занимает ~35ms. Запрос на чтение следующего регистра идет через ~ 20 ms.



Таким образом, за секунду получается 28 запросов.



Далее, нагрузил логику до времени цикла 7ms, можем видеть, что запросы стали реже, за 1 сек. получаем 17 запросов.



Сетевые настройки делал минимальными.

Меняя значения и сравнивая результаты, у сделал следующие выводы:

-интервал между запросами при значениях <8ms, не оказывает влияния на обмен, т.е это минимально возможное значение
-период опроса аналогично, чаще чем 10 ms у меня не получилось опрашивать, это без логики в программе, т.е. только опрос 2 переменных.
-таймаут ответа, если значение будет низким, будут ошибки, если кол-во попыток >1, еще и перезапросы, обмен завалится. Лучше ставить с запасом 100-500 ms.

Соответственно, при времени цикла в программе 7 ms, обработка одной посылки занимает 40 ms. Прибавляем сюда немного увеличившийся период опроса, получаем около 17-18 опросов в секунду.

Далее, симулятор, заменяем реальным модулем ввода MB110-2AC, сменяем значение регистров на 264 и 267, для чистоты эксперимента, так же читаем 2 float, в модуле ставим время ответа 2 ms.
Видим, что модуль отвечает за 2,64ms, и за секунду можем сделать около 90 запросов регистров в формате float. Время одного пакета запрос/ответ ~3,5 ms.



При времени цикла 7 ms, за секунду получаем ~(17-18) запросов
Надеюсь что ответил на большинство Ваших вопросов.

[Одесса]

И так, провел серию опытов, еще вчера для быстрой проверки настроил ПР200 мастером, и через AC4 подключил к эмулятору слейва на ПК:


Видно опрос 2 float, по адресу 512 и 514, так как группового запроса нет, идет 2 запроса подряд. Ставил минимальное время 10 ms, таймаут ответа поставил 100 ms. Обмен стабильный, ошибок нет.

Затем, уже сегодня подключившись анализатором, посмотрел, за какое время приходят ответы. Видно, что от ПК с симулятором ответ приходит через ~30ms, сами посылки запрос/ответ на этом фоне занимают очень мало времени, ~0,7ms. Весь пакет запроса одного регистра занимает ~35ms. Запрос на чтение следующего регистра идет через ~ 20 ms.



Таким образом, за секунду получается 28 запросов.



Далее, нагрузил логику до времени цикла 7ms, можем видеть, что запросы стали реже, за 1 сек. получаем 17 запросов.



Сетевые настройки делал минимальными.

Меняя значения и сравнивая результаты, у сделал следующие выводы:

-интервал между запросами при значениях <8ms, не оказывает влияния на обмен, т.е это минимально возможное значение
-период опроса аналогично, чаще чем 10 ms у меня не получилось опрашивать, это без логики в программе, т.е. только опрос 2 переменных.
-таймаут ответа, если значение будет низким, будут ошибки, если кол-во попыток >1, еще и перезапросы, обмен завалится. Лучше ставить с запасом 100-500 ms.

Соответственно, при времени цикла в программе 7 ms, обработка одной посылки занимает 40 ms. Прибавляем сюда немного увеличившийся период опроса, получаем около 17-18 опросов в секунду.

Далее, симулятор, заменяем реальным модулем ввода MB110-2AC, сменяем значение регистров на 264 и 267, для чистоты эксперимента, так же читаем 2 float, в модуле ставим время ответа 2 ms.
Видим, что модуль отвечает за 2,64ms, и за секунду можем сделать около 90 запросов регистров в формате float. Время одного пакета запрос/ответ ~3,5 ms.



При времени цикла 7 ms, за секунду получаем ~(17-18) запросов
Надеюсь что ответил на большинство Ваших вопросов.

Спасибо Юрий за кропотливый труд и за то что подтвердили мои теоретические предположения в последнем моем посте.
К Вашему исследованию с симулятором отношусь с недоверием,т.к. показания симмулятора переносятся с головы автора этого
симмулятора на симмулятора,а что там в голове автора одному богу известно. А вот второй части Вашего исследования охотно
верю. И вывод я сделал однозначный- если ПР управляет Овеновскими ВУ ,то все в порядке. Если же к ПР цеплять ВУ других производителей,то это нужно делать с осторожностью ,вникая в их индивидуальные алгоритмы работы.
Спасибо.

[Aviator_VZh]

Спасибо. Юрий.
Очень интересно и познавательно.

[Одесса]

С этого момента можно по подробнее? Что за длительная или короткая обработка, и где она задается?

Мне лень повторно поднимать документацию на Ваш прибор,но по памяти помню,что обработка аналогового входного сигнала
Вашим прибором имеет два решения. 1. Упрощённая обработка,как у Овна и сложная с разными интерполяциями и интеграциями.
И выбор делаете Вы ,между этими двумя методами,установив какой то там флажок. Я не знаю и не работал с Вашими приборами.
И не могу утверждать,что моя гипотеза верна. Но не допускаете ли Вы,что на эту интерполяцию аналогового сигнала и уходит много
времени ,которого вам не хватает для боллее частого снятия информации. Повторяю-я это не удтверждаю,а только предполагаю.

[rwg]

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

В моём понимании, получив запрос на содержимое ячеек, Модбас-слейв должен тут же несмотря ни на что с минимальной задержкой передать мастеру их значения. Но авторы протокола поступили мудрее и предусмотрели ситуацию, когда данные в этих ячейках ещё не готовы. В этом случае слейв вместо содержимого ячеек шлёт сообщение об ошибке 05 ACKNOWLEDGE. "Слейв принял запрос и обрабатывает его, но ему требуется много времени. Этот ответ возвращается для предупреждения ошибки тайм-аута мастера" . Или 06 SLAVE DEVICE BUSY "Слейв обрабатывает долго выполняемую команду. Мастер должен повторно передать запрос позже, когда слейв освободится"