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

[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]

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

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

[nickbeljaev]

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

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