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

[Mike HG]

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

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

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

[Одесса]

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

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

Попробуйте следующее. 1. Проделайте любые сетевые манипуляции с другим прибором из серии Овен, о котором Вы говорили.
Ecли будет та же ситуация, то на 90% есть вероятность что с ПР что то не Але. Может даже не на физическом уровне. Для
выяснения этого запишите в ПР программу ,которая кроме обслуживания модбаса больше ничем не занимается,чтобы до миниму
ма сократить время внутреннего цикла. И будем посмотреть.

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

Я бы раз так сделать, да по условию задачи не проходит. 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.,что на Овеновских модулях все будет ОК.

[rwg]

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

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

[Одесса]

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

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