Макросы в онлайн базе OWEN Logic

[nickbeljaev]

Юрий, в данном случае это обыкновенная дифф составляющая регулятора связанного с релейным позиционированием, желательно что бы она работала на каждом цикле пока тот находится в интервале 5..10мс, можно конечно переделать регулятор, но тогда его нужно будет согласовать, что организационно не удобно, но вообще использование этого таймера весьма частое явление в ПЛК, и применений много.
Сергей я не думал никого пугать - работаю с автомобильной промышленностью и у нас "на стене" висит перл выданный кем то с автоваза по поводу робкого желания пользователей перейти на более совершенный способ цинкования, "коррозионная защита автомобилей соответствует их классу", так что иллюзий по поводу "пугания" "отечественного производителя" я не испытаю. Просто жаль, что имеется такой изъянчик - в остальном девайс кажется симпатичный.

[nickbeljaev]

Сергей, а как это про два цикла? Можно подробнее? Чем меньше будет время интегрирования тем больше будет погрешность, к тому же циклы все разные из-за ветвлений.

[Сергей0308]

Сергей, а как это про два цикла? Можно подробнее? Чем меньше будет время интегрирования тем больше будет погрешность, к тому же циклы все разные из-за ветвлений.

Например генератор импульсов поставить, с временем включённого-выключенного состояния = 1мс, тогда период импульсов будет = 2 мс, если время цикла программы не более 1 мс(зависит от сложности программы)! В любом случае время включённого-выключенного состояния не может быть меньше времени цикла программы!

[nickbeljaev]

Например генератор импульсов поставить, с временем включённого-выключенного состояния = 1мс, тогда период импульсов будет = 2 мс, если время цикла программы не более 1 мс(зависит от сложности программы)! В любом случае время включённого-выключенного состояния не может быть меньше времени цикла программы!

Хорошо, я сделал генератор с периодом состояния ровно в цикл, дальше, как мне узнать чему был равен период этих состояний.
Как это работает сейчас - есть ФБ (или системная переменная, без разницы) возвращающий тики какого то однородного счетчика (с известным периодом) в недрах ПЛК, беря на каждом (или не на каждом, а когда надо) шаге циклическую разность с ранее сохраненным значением этого счетчика я получаю весьма точный интервал времени в мкс прошедший с крайнего сохранения этого значения, такой подход удобен - есть во всех кодогенераторах с которыми я имел дело, применяется в куче алгоритмов вычисляющих всякие там скорости нарастания. На сколько я знаю по своему опыту, в реализации тоже ничего невозможного нет - так же как секунды отдают пользователю, так и микросекунды циклические можно отдавать. Не вижу причин к сопротивлению. Можно, конечно дифференцировать по фиксированному периоду, но фишка в том что он на самом деле не такой уж фиксированный, например TON 1с при качании времени цикла вокруг 10мс будет составлять от 1 до 1.01 (1% джитера в принципе приемлемо), а если нужно дифференцировать чаще, например 10 раз в секунду то период будет врать в том же времени цикла то есть уже 10% неопределенности и ваш объект управления перестает попадать цель. Возможно мотивация Овена чисто маркетинговая - "вон вам ПЛК за 30 - его и покупайте, и нечего на ПР тут миллиметры ловить", но ПЛК у них пока не конкурентные (прошу прощения за такую оценку - ноя думаю у Овена еще все впереди и искрене желаю удачи), а вот ПР при его современном и быстром проце мог бы попробовать заменить многие устаревшие модели иностранных ПЛК. Тем более сейчас растет спрос на бюджетную автоматику "для бедных".

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

Возможно мотивация Овена чисто маркетинговая - "вон вам ПЛК за 30 - его и покупайте, и нечего на ПР тут миллиметры ловить", но ПЛК у них пока не конкурентные, а вот ПР при его современном и быстром проце мог бы попробовать заменить многие устаревшие модели иностранных ПЛК. Тем более сейчас растет спрос на бюджетную автоматику "для бедных".

В общем +- так и есть, даже если гипотетически вывести микросекундные тики, они Вам чем помогут, если время цикла будет 5 мс. Точнее чем 1 мс все равно не получится считать, именно на этом и построен макрос Time_U/D, внутри автоматом выбирается точность вывода времени, в зависимости от времени цикла программы, который кстати, рассчитывается в самом начале, и не должен меняться, независимо от ветвлений или других процессов.

[Сергей0308]

Кажется "petera" писал(точно не помню), что делал таймеры на основе подсчёта количества циклов программы и время очень точно отсчитывалось!

[Серёга Букашкин]

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

[nickbeljaev]

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

Ну я в курсе, что в CODESYS, можно иногда настраивать события, но вот как то не разу этим не воспользовался, я вообще уже довольно давно "этим" занимаюсь, начинал еще с Z80, наверное поэтому достаточно быстрый раундробин с учетом фактического времени кажется мне идеалом, зачем мне думать о конкурентном доступе, о инверсии приоритетов и прочих космически сложных для меня вещах, когда простецкая циклограмма справляется.

[nickbeljaev]

Кажется "petera" писал(точно не помню), что делал таймеры на основе подсчёта количества циклов программы и время очень точно отсчитывалось!

А как он определил, что "очень точно", это конечно у него надо спрашивать, так что если Petra прочитает то это вопрос, что значит очень точно и как мерили?

[petera]

А как он определил, что "очень точно", это конечно у него надо спрашивать, так что если Petra прочитает то это вопрос, что значит очень точно и как мерили?

Пример подсчета кол. циклов https://owen.ru/forum/showthread.php...l=1#post315708

Таймер с паузой основанный на этом принципе https://owen.ru/forum/showthread.php...l=1#post317326
Абсолютная погрешность вычисления интервалов времени не более половины времени цикла во всем допустимом диапазоне уставки в мс от Тц до 4294967295/Tц, где Тц - время цикла ПР
Описание макроса таймера https://owen.ru/forum/showthread.php...l=1#post316645
Как мерил?
Можно секундомером, можно самим ПР, сравнивая со стандартным таймером с большой уставкой
Например
Захват-2.png

здесь нагрузка ПР - цепочка макросов вычисления логарифма
Захват-3.png

Заявленная точность проверялась в версии ОЛ до 1.13, когда для самых разных программ время цикла в меню прибора и в ОЛ всегда оказывается кратным строго 1 мс - 1.00; 2.00;..15.00; 16.00 и тд
По этому используется целочисленная арифметика при расчете времени цикла и в таймере.

В версии 1.16 заметил, что время цикла в меню прибора и в ОЛ иногда отображается с сотыми долями мс. Для этой версии точность таймера не проверял.