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

[Сергей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 заметил, что время цикла в меню прибора и в ОЛ иногда отображается с сотыми долями мс. Для этой версии точность таймера не проверял.

[nickbeljaev]

Пример подсчета кол. циклов 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 заметил, что время цикла в меню прибора и в ОЛ иногда отображается с сотыми долями мс. Для этой версии точность таймера не проверял.

Благодарю. То есть если я все правильно понял суммы периодов одинаково большого количества циклов почти равны между собой. Но меня интересует несколько другое - насколько различаются периоды самих циклов внутри этих сумм. То есть для пояснения: если все циклы равны между собой то достаточно 100 секунд поделить на количество циклов за эти сто секунд и результат использовать как время любого цикла. Если же суммы равны статистически, но не состоят из одинаковых периодов, то применение данного подхода будет вносить в работу регулятора непредсказуемую погрешность. Мой случай выглядит так (f(x,y,z...)+shr(dt,1))/dt, вот сейчас я это dt беру как разность значений аппаратного таймера в мкс, в версии ПО для ПР я это dt ,беру как частное от (большой промежутк времени)/(количество циклов за этот промежуток), тот специалист, кто будет верифицировать мою программу обязательно попросит меня обосновать, что полученное таким образом dt действительно соответствует времени прошедшему между событиями, а сейчас я этого сделать не смогу. Поэтому пытаюсь уговорить Овен дать пользователю таймер или дать пояснение о том, что время всех циклов равно между собой.

[petera]

Благодарю. То есть если я все правильно понял суммы периодов одинаково большого количества циклов почти равны между собой. Но меня интересует несколько другое - насколько различаются периоды самих циклов внутри этих сумм. То есть для пояснения: если все циклы равны между собой то достаточно 100 секунд поделить на количество циклов за эти сто секунд и результат использовать как время любого цикла. Если же суммы равны статистически, но не состоят из одинаковых периодов, то применение данного подхода будет вносить в работу регулятора непредсказуемую погрешность. Мой случай выглядит так (f(x,y,z...)+shr(dt,1))/dt, вот сейчас я это dt беру как разность значений аппаратного таймера в мкс, в версии ПО для ПР я это dt ,беру как частное от (большой промежутк времени)/(количество циклов за этот промежуток), тот специалист, кто будет верифицировать мою программу обязательно попросит меня обосновать, что полученное таким образом dt действительно соответствует времени прошедшему между событиями, а сейчас я этого сделать не смогу. Поэтому пытаюсь уговорить Овен дать пользователю таймер или дать пояснение о том, что время всех циклов равно между собой.

В начале я тоже пытался считать количество циклов за достаточно большой промежуток времени таким способом
Захват-2.png
и даже по нарастающей, чтобы в начале иметь хоть какие-то приблизительные значения
Захват-1.png
время цикла получал как число с плавающей точкой и вот после 8 сек получал число близкое к тому, что показывали штатные средства ПР и ОЛ
однако в зависимости от величины реального времени цикла имела место некая разная погрешность между показаниями и вычислениями.
Захват-6.png Захват-7.png Захват-8.png

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

По этому в последнем варианте использую целочисленную арифметику деления с округлением
Не смотря на то, что время подсчета количества циклов уменьшил до 500мс
Получил значения совпадающие с показаниями которые дают штатные средства ПР и ОЛ
Вот результат для тех же некрасивых значений
Захват-3.png Захват-4.png Захват-5.png

Ну и сам макрос целочисленного деления с округлением результата
Захват-9.png

[nickbeljaev]

В начале я тоже пытался считать количество циклов за достаточно большой промежуток времени таким способом
Захват-2.png
и даже по нарастающей, чтобы в начале иметь хоть какие-то приблизительные значения
Захват-1.png
время цикла получал как число с плавающей точкой и вот после 8 сек получал число близкое к тому, что показывали штатные средства ПР и ОЛ
однако в зависимости от величины реального времени цикла имела место некая разная погрешность между показаниями и вычислениями.
Захват-6.png Захват-7.png Захват-8.png

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

По этому в последнем варианте использую целочисленную арифметику деления с округлением
Не смотря на то, что время подсчета количества циклов уменьшил до 500мс
Получил значения совпадающие с показаниями которые дают штатные средства ПР и ОЛ
Вот результат для тех же некрасивых значений
Захват-3.png Захват-4.png Захват-5.png

Ну и сам макрос целочисленного деления с округлением результата
Захват-9.png

Это может свидетельствовать о том, что циклы разные по времени, такое происходит например из-за программной арифметики, например деление даже целых может занимать разное количество тиков в зависимости от операндов. Так что надо ждать какой то реакции от авторов - или добавления таймера или заверения, что все циклы одинаковые. Вообще это ни о чем не свидетельствует, возможно у в вашей программе нет ветвлений или операнды из раза в раз одинаковые.

[petera]

Это может свидетельствовать о том, что циклы разные по времени, такое происходит например из-за программной арифметики, например деление даже целых может занимать разное количество тиков в зависимости от операндов. Так что надо ждать какой то реакции от авторов - или добавления таймера или заверения, что все циклы одинаковые. Вообще это ни о чем не свидетельствует, возможно у в вашей программе нет ветвлений или операнды из раза в раз одинаковые.

В Лоджике нет никаких ветвлений!
Вся схема выполняется полностью.