Оценка времени выполнения "быстрой" функции

Разбираюсь с ПЛК110, с быстрым таймером. И собственно возник вопрос, каким образом можно оценить время выполнения функции "быстрого таймера"... ну не по зависанию контроллера же!!!

Рекомендация в руководстве "не загружать функцию объемными расчетами" понятна, но вопрос в критерии, что является критерием объемности? Что туда поместиться, инкремент двух переменных, как в примере? Или допустим какой-либо код с условиями и обработкой оных??

Может есть какая-то информация по времени выполнения команд? Где то можно посмотреть процент использования времени функцией таймера? Какой процент использования допустим для нормальной работы остальных сервисов??

/// с базовым циклом все понятно :D


кстати, при работе с "быстрым" таймером не работает "горячая" замена программы... при логине контроллер загружает программу и перегружается, программа стартует с начала

Syslibtime вам поможет

Значит так. Частота процессора 200 МГц. Обычно 1 операция в CoDeSys - это от 5 до 60 операций процессора.
Частота таймера 50 кГц, соответственно 200МГц/50кГц=4 тыс. операций.
Примем средний размер операции CoDeSys=30 опер. процессора. 133 операции CoDeSys. Т.к. мы хотим хоть немного времени дать ПЛК для других функций, ограничимся 65 операциями CoDeSys на 1 прерывание.
Для арифмет. действий можно увеличить число, для сложных переходов - уменьшить.
Внутри прерывания НЕЛЬЗЯ вызывать другие функциональные блоки и ОЧЕНЬ НЕЖЕЛАТЕЛЬНО вызывать любые функции. Это стандартное правило написания прерываний.

И вообще, в прерывании надо выполнять критические действия (включать выходы, регистрировать фронты и т.п.). Все остальные действия - вне прерывания.

"
кстати, при работе с "быстрым" таймером не работает "горячая" замена программы... при логине контроллер загружает программу и перегружается, программа стартует с начала"

Горячая замена - надо перед горячей заменой отписаться от использования прерывания, а после -снова подписаться. Прерывание работает вне цикла ПЛК и автоматизировать этот процесс невозможно.

Спасибо! Все понятно и с этим можно жить )))
Для полноты картины не хватает списка инструкций с требуемыми тактами (для ST). Есть давняя ассемблерная привычка оптимизации по требуемому времени )))
.... и вспоминая большое программирование.... практически во всех средах разработки есть дебаггеры, которые могут показывать непосредственно выполнение уже компилированного кода, т.е. можно видеть выполнение СИ-шной программы, уже разложенной на ассемблерные инструкции..... Кодесис жмет такие функции? или Вы, как производители контроллеров, не хотите показывать свою реализацию МЭК языка?

А такого списка нету... Кто ж его составит?
Компилятор закрыт и для нас.

с быстрыми входами разобрались ... теперь обычные выходы )))
.... не работает установка, ищу проблему... долго .... в конце концов делаю новый проект в котором инвертируется бит в каждом цикле и это выводится в порт... по идее на выходе должен получиться меандр с частотой 500 гц (импульс с длительностью 1мс)? ... на практике, на выводе появляется импульсный сигнал с переменной длительностью .. от 25 мс до 75 мс...
прошивка 2.07, таргет 2.06. что-то можно делать или прибор в ремонт?
или в плк110 работа со всеми выводами через специальную библиотеку?


да, если переделываю проект на "быстрый вывод" - все тип-топ - 20мкс

разобрались, вместе с тех.поддержкой прочитали паспорт .... реакция выхода на изменение программной переменной до 20 мс... типа реализация такая.

родилась идея, писать модуль скоростного таймера на "il", по идее язык низкого уровня, сходный ассемблерному. но, почему то нигде в явном виде не подчеркивается факт более быстрого выполнения программ выполненных на "il" по сравнению скажам, с "st". производительность буржуйских контроллерах приводится именно в длительности простой инструкции языка "il", и подчеркивается, что инструкция "il" переводится при выполнении в 1-3 команды собственно процессора. выше приведена инфа, что в кодесис 1 инструкция приводится в 5 - 60 операций. для какого языка это соотношение? или кодесис по барабану на чем сделан исходник. либо отсюда следует что написание кода на "il" поднимет производительность на порядок?

1. медленные выходы потому и медленные, что медленные. входы 500гц потянут.
2. тестирования какой язык быстрее не производил. компилятор оптимизирует как может но многое зависит и от алгоритма.
3. буржуйские попугаи - как раз и попугаи, т.к. чем больше попугаев, тем лучше. 30 тактов - типичная инструкция типа If...else...end_if, Case или вызов функции/функционального блока.
простейшие лог. естественно могут быть быстрее и в пределе 1 такт, если только битовая логика и мало переменных.

Размер кода в Codesys практически не зависит от выбранного языка программирования (смотрите книгу "Программируемые контроллеры" И.В. Петров). По идее скорость выполнения тоже.

да как-же. например на Sfc гораздо больше размер кода, чем аналогичный на St. но учитывая, что Sfc применяется ограниченно - это не страшно.

Цитата:

---

Сообщение от Sniper007

Размер кода в Codesys практически не зависит от выбранного языка программирования (смотрите книгу "Программируемые контроллеры" И.В. Петров). По идее скорость выполнения тоже.

---

Книгу читал.. неубедительно там как-то. А кроме того речь в книге все таки о размере кода а не о быстродействии. По опыту большого программирования даже С прога после хорошего компилятора работает в 2-3 раза медленнее, кода на макроассемблере. А размер могут дуть примочки кодесиса, ведь плюшки в виде отладки, визуализации и пр. цепляются автоматически к любому языку. Они и дадут размер (блоки то одни и теже, поэтому и размер кода сравнимый), но поскольку, (надеюсь!!) они выполняются в конце цикла (и по остаточному принципу!), собственно тело цикла выполниться быстрее!

Кроме того, зуб даю, что мой селектор на 3 - 4 ветки выполниться быстрее чем типовой "case" )))

Как вы разбрасываетесь зубами...
Отладка сделана в CoDeSys необычно и на нормальное выполнение вообще никак не влияет.