Страница 43 из 81 ПерваяПервая ... 33414243444553 ... ПоследняяПоследняя
Показано с 421 по 430 из 806

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

  1. #421
    Пользователь Аватар для petera
    Регистрация
    06.05.2011
    Адрес
    Минск
    Сообщений
    3,825

    По умолчанию

    Цитата Сообщение от nickbeljaev Посмотреть сообщение
    А как он определил, что "очень точно", это конечно у него надо спрашивать, так что если 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 заметил, что время цикла в меню прибора и в ОЛ иногда отображается с сотыми долями мс. Для этой версии точность таймера не проверял.
    Последний раз редактировалось petera; 22.01.2020 в 01:22.
    Мой канал на ютубе
    https://www.youtube.com/c/ПетрАртюков
    Библиотека ГМ для СП300
    https://disk.yandex.com/d/gHLMhLi8x1_HBg

  2. #422

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    стесняюсь спросить это формула чего? Что она доказывает в преимуществе использования микросекунд и миллисекунд? Закономерность изменения от количества циклов одна и таже
    Я тоже вопрос не понял, это целочисленная функция превращающая количество циклов случившихся за 1с во время одного цикла в микросекундах при обязательном условии, что время всех циклов одинаково! Если её же записать в миллисекундах то в числителе надо 1000000 заменить на 1000, но тогда будет очень плохая разрешающая способность.

  3. #423

    По умолчанию

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

  4. #424

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    на графике как раз обе подстановки и 1000000 и 1000, просто микросекундный график поделен на тысячу, так хоть как то заметна разность, а нормировав сигнал они в точности повторяют друг друга.
    О какой разрешающей способности идет речь? При величине цикла в 2мс между ними разница 0.5мс. А если учесть что актуальные данные появляются перед началом цикла, а исполнительные механизмы получают управляющий сигнал в конце цикла, хоть в начале схемы делай расчет, хоть в конце, к временам всё равно нужно будет прибавлять время цикла, поэтому о точных мат.расчетах можно забыть, остается только прогнозирование, а его без разницы на чем делать, но предпочтительнее в тех единицах измерений, на которых работает программируемое устройство
    Видимо Вы рассуждаете в числах с плавающей точкой. Я рассуждаю в целых, дело в том, что мне жалко времени на программное деление чисел с плавающей точкой. Если вести все расчеты в числах с плавающей точкой, то Вы правы - единицы времени роли почти не играют. Хотя когда речь идет о 32 битных числах с плавающей точкой возможны сюрпризы с точностью.

  5. #425
    Пользователь Аватар для petera
    Регистрация
    06.05.2011
    Адрес
    Минск
    Сообщений
    3,825

    По умолчанию

    Цитата Сообщение от nickbeljaev Посмотреть сообщение
    Благодарю. То есть если я все правильно понял суммы периодов одинаково большого количества циклов почти равны между собой. Но меня интересует несколько другое - насколько различаются периоды самих циклов внутри этих сумм. То есть для пояснения: если все циклы равны между собой то достаточно 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
    Мой канал на ютубе
    https://www.youtube.com/c/ПетрАртюков
    Библиотека ГМ для СП300
    https://disk.yandex.com/d/gHLMhLi8x1_HBg

  6. #426

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    вот результаты при целочисленном делении.
    Не верно, ступени мкс много мельче.

  7. #427

    По умолчанию

    Цитата Сообщение от petera Посмотреть сообщение
    В начале я тоже пытался считать количество циклов за достаточно большой промежуток времени таким способом
    Захват-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; 22.01.2020 в 20:24.

  8. #428
    Пользователь Аватар для petera
    Регистрация
    06.05.2011
    Адрес
    Минск
    Сообщений
    3,825

    По умолчанию

    Цитата Сообщение от nickbeljaev Посмотреть сообщение
    Это может свидетельствовать о том, что циклы разные по времени, такое происходит например из-за программной арифметики, например деление даже целых может занимать разное количество тиков в зависимости от операндов. Так что надо ждать какой то реакции от авторов - или добавления таймера или заверения, что все циклы одинаковые. Вообще это ни о чем не свидетельствует, возможно у в вашей программе нет ветвлений или операнды из раза в раз одинаковые.
    В Лоджике нет никаких ветвлений!
    Вся схема выполняется полностью.
    Мой канал на ютубе
    https://www.youtube.com/c/ПетрАртюков
    Библиотека ГМ для СП300
    https://disk.yandex.com/d/gHLMhLi8x1_HBg

  9. #429

    По умолчанию

    Цитата Сообщение от capzap Посмотреть сообщение
    предыдущая картинка была с шагом 25, теперь с шагом один со 125 до 500
    Это разве что то поменяет, есть определенное количество циклов, где единицы измерения роли не играют
    Ступеньки на мкс ровно в 1000 раз мельче чем на мс

  10. #430

    По умолчанию

    Цитата Сообщение от petera Посмотреть сообщение
    В Лоджике нет никаких ветвлений!
    Вся схема выполняется полностью.
    Petera вы знаете как там устроено деление двух целых? Это итеративный процесс, количество итераций в котором зависит от операндов, например деление на 2 занимает мало тиков, а деление большого числа на 3 много , поэтому ветвления там есть, даже если Вы их не видите. Тем не менее способ обеспечить постоянство цикла имеется, для этого нужно запускать пользовательский цикл по прерыванию таймера с таким расчетом что бы в самом длинном случае он успел закончится за некоторое время до начала следующего, при этом надо следить, что бы данное прерывание не было отложено.

Страница 43 из 81 ПерваяПервая ... 33414243444553 ... ПоследняяПоследняя

Похожие темы

  1. Универсальные макросы для OWEN Logic
    от rovki в разделе Среда программирования OWEN Logic
    Ответов: 827
    Последнее сообщение: 22.12.2023, 13:20
  2. OWEN Logic v1.7
    от Евгений Сергеевич в разделе Среда программирования OWEN Logic
    Ответов: 404
    Последнее сообщение: 25.08.2020, 15:17
  3. OWEN Logic v1.7
    от Евгений Сергеевич в разделе Программируемые реле
    Ответов: 401
    Последнее сообщение: 28.07.2016, 19:46
  4. ПО OWEN Logic !!!
    от Ельцов Андрей в разделе Программируемые реле
    Ответов: 3
    Последнее сообщение: 11.10.2011, 16:33
  5. OWEN Logic 1.2.0.14b
    от Ельцов Андрей в разделе Программируемые реле
    Ответов: 40
    Последнее сообщение: 21.02.2011, 14:16

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •