Вопрос актуален и встал еще более остро! Техподдержка ОВЕНа ответьте!
Сегодня на объекте попробовал изменять время вызова высокочастотного таймера в широком диапазоне.
Результаты удивили.
При времени вызова 20, 40, 60 - процесс затыкался, контроллер перезагружался.
При времени вызова 80 работал. Из этого вопрос.
Как он работал со временем вызова 80 мкс, если по измерениям, проведенным мною (по методу изложенному в посте 9), минимальное время выполнения моего кода 160 мкс?
В основном цикле программу, вызываемую по прерыванию высокочастотного таймера, вызывать бессмысленно, и уж тем более измерять время ее выполнения, вызывая в основном цикле.
Если хотите посмотреть действительное время исполнения программы по прерыванию, то считывайте системное время непосредственно внутри самой программы, вызываемой по прерыванию.
Если время исполнения алгоритма внутри программы по прерыванию превысит 20мкс, должен сработать сторожевой таймер.
Т.к. сторожевой таймер будет срабатывать при превышении 20 мкс для программы, вызываемой по прерыванию, то ситуация, которую Вы описываете невозможна.Сообщение от Спорягин Кирилл
В основном цикле я ее вызываю только для того, чтобы измерить время. Почему-то когда ФБ CurTime я вызывал внутри самой программы, а программу вызвал по прерываниям высокочастотного таймера, то время выполнения было равно 0. Я предположил, что в высокочастотном таймере CurTime не работает.
А вот почему измерять время выполнения в основном цикле бессмысленно прошу пояснить подробнее.
Как пояснил выше, почему-то это не работало. Возможно я где-то ошибся. Уточните, пожалуйста, ФБ CurTime должен работать в программе вызываемой по высокочастотному таймеру.
Не понимаю, почему Вы взяли величину 20 мкс? Время вызова такое, какое объявляется в функции SetIRQ. Можно ли говорить о том, что если при 20, 40 и 60 мкс, моя программа не работает, а при 80 работает, то значит время выполнения моего кода меньше 80, но больше 60? И если это так, то поясните, все же почему измерения в основной программе дают другие значения.
Возможно, на старых ПЛК110 есть проблемы с расчетом системного времени в программе, вызываемой по прерыванию вчт, на новых ПЛК110 [М02] этот функционал работает корректно, но в любом случае программа по прерыванию не может выполняться дольше 20 мкс (иначе сработает сторожевой таймер) - это касается и старых и новых ПЛК110. При этом не важно с какой периодичностью вызывать программу по прерыванию (через SetIRQ), сторожевой таймер сработает при превышении 20 мкс, при любой периодичности вызова.
Если Вы правы, то это серьезно расходится с моими представлениями о том, как работает ВЧТ.
Но тогда не понятно, почему при вызове раз в 20, 40 и 60 мкс программа затыкается, а при вызове 80 мкс и более работает?
И все же хотел бы получить ответ на вопрос, почему измерения моего куска кода дают минимальную оценку времени выполнения в 160 мкс, а исходя из Вашего ответа, получается, что код мой выполняется менее 20 мкс. Куда уходят 140 мкс при выполнении в основной программе?
П.С. Могу выложить проект, если это необходимо.
На сколько я помню, как раз на прошивке 2.14.0 прерывания не работали и контроллер перезагружался при периоде вызова ниже 80 мкс. На 2.10.9 можно вызывать программу по прерыванию с периодом менее 80 мкс, но наиболее ровные фронты выходных сигналов получались при периоде вызова программы не менее 80 мкс.
Сейчас затрудняюсь ответить на этот вопрос, необходимо полностью понять организацию прерываний в старых ПЛК110, а чтобы не дезинформировать, пока не буду выдвигать никаких предположений ...
программа в ПЛК не захватывает процессор в монопольный режим, там крутиться множество всякой фоновой мишуры. Не совсем понятна конечная цель ваших экспериментов - если необходимо оценить время выполнения своего кода - то просто запустите программу и смотрите время цикла в модуле статистике, это не даст точных значений, но понять хватает или не хватает производительности вполне возможно.
Кстати, для написания тела быстрого таймера рекомендую использовать IL, код значительно быстрее аналога на ST
Изначально, цель экспериментов была в том, чтобы оценив время выполнения кода, понять с какой частотой можно вызывать ВЧТ. После комментария Евгения Гарчева, все только запуталось. Я все же думаю, что он не прав и программа в ВЧТ может выполняться больше 20 мкс, но не может выполняться дольше чем, частота вызова ВЧТ. Т.е. если я вызываю его с частотой 80 мкс, то время выполнения кода, исполняемого по ВЧТ, должно быть меньше чем 80 мкс.
В целом это мне было понятно. Именно так я трактовал результаты эксперимента (см. пост 9). А именно, когда на время выполнения не попало (или попало мало) фоновой мишуры, мы имеем минимальное время выполнения, т.е. 160 мкс. Если же попало много фоновой мишуры, то имеем время выполнения до 500 мкс. В этом разразе заявление Евгения кажется еще более неправдоподобным, потому как получается, что мой код занимает менее 20 мкс. Что же тогда фоновая мишура от 140 до 480 мкс?
Модуль статистики дает оценку всей программы, я же выполняю в ВЧТ только часть.
--------------------------
В конечном счете, моя задача, добиться минимального времени выполнения ВЧТ и быть уверенным, что не будет в дальнейшем каких-либо отклонений от заложенной функциональности.
Попробовал исполнить свой код (прикрепляю) на ПЛК110 М02.
Результаты следующие. Вызов функции CurTime в ВЧТ работает.
Время выполнения программы в ВЧТ получилось примерно 5-6 мкс. Иногда время получается отрицательное (см. Время выполнения в М02.jpg)!
Если в М02 код исполняется 5-6 мкс, то по моим оценкам, код в ПЛК110 старой модификации будет выполняться 75-90 мкс (в 15 раз медленнее). Явно дольше чем 20 мкс.
Ваши права
Ответить с цитированием