Статистика опроса модулей ОВЕН

[Трофимов Артем]

данный расчёт слишком точен, тут необходимо добавить время задержки ответа от модуля , времена переключения портов из приёма в передачу и обратно , также цикл контроллера ( а лучше два, т.к. окончание посылки может попасть в самое начало фазы обработки программного кода (после фазы вычитки входных параметров) , т.е. завершение работы приёма будет только в окончании следующего цикла , т.к. буфер будет дочитан полностью и будет подана команда на готовность к передаче) .
все эти микро- и милли-задержки складываются, потому мы обычно , чтобы не вдаваться в подробности рекоммендуем и говорим сразу +10 а то и +15 мс на такой скорости к расчитанной по математике.
пару вопросов :
1) каково реальное время исполнения программы у Вас на ПЛК? если смотреть в модуле статистики
2) в таймерах используете такты цикла или опираетесь на время? ( погрешность при переключении стадий тоже может внести свою лепту, но это уже очень глубокий анализ)

[Спорягин Кирилл]

Ответ в целом понятен. Спасибо.

пару вопросов :
1) каково реальное время исполнения программы у Вас на ПЛК? если смотреть в модуле статистики
2) в таймерах используете такты цикла или опираетесь на время? ( погрешность при переключении стадий тоже может внести свою лепту, но это уже очень глубокий анализ)

1. Реальное время исполнения программы указываемое в модуле статистики 100 мкс. MinCycleLength указан = 1 мс.
2. В таймере использую функцию Time(). Первый раз вызываю ее в начале опроса (при взводе Enable). Второй раз вызываю, как только получил ответ (Complete = tue). По разнице определяю время опроса. Более подробно можно понять посмотрев библиотеку GCTimer.lib (прикреплена в посте №1).

Артем, встречный вопрос.
Из-за чего возникают ошибки модуля МУ110 на скорости 115200?
Быть может какой-то процент ошибок в сети RS-485 является нормой?