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





Ответить с цитированием