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

[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

[игорь68]

Вопрос не по циклам. Что вы такое возите на таких скоростях. Как бывший сотрудник Отис так для сравнения могу сказать что модель европа2000 едет со скорость 0,8мСекунду. Может можно как то по другому управлять скорость тележка.

[nickbeljaev]

Игорь какая разница чего она возит? Она сейчас это возит вот с этой самой скоростью, и это не лифт. Меня просто спросили зачем таймер я максимально подробно рассказал с привлечением конкретного примера, теперь Вы спрашиваете чего мы возим, следующий вопрос сколько мы за это получаем наверное

[игорь68]

Не. Ваша ЗП неинтересует. А протележку спрашивал потому как сам дела передаточную тележку(выкинули японца).

[nickbeljaev]

Не. Ваша ЗП неинтересует. А протележку спрашивал потому как сам дела передаточную тележку(выкинули японца).

Ну слава богу кроме того она все равно такая маленькая, что стыдно было бы сказать Тележка не передаточная, скорее это стапель на колесиках, современные Западные ездят еще быстрее до 6 км/ч, а у нас все по старинке - чуть больше 3-х.

[nickbeljaev]

Я не капли не сомневаюсь что Вы бы все настроили грамотно, но Вы надеюсь достаточно заняты другими задачами и нашей тележке ваша "настройка" пока не угрожает. Что касается немецкого "контроллера", то у него 16-ти битный 25МГц. проц из 90-х. А у Овеновского "реле" 32-х битный 72МГц так кто из них скорее "реле", а кто "контроллер"? С аппаратной периферией у немца конечно получше, но это чисто заслуга Овена из маркетинговых соображений постеснявшегося заюзать все то, чем так богаты современные СТшки.

[nickbeljaev]

как же Вас "порвет", когда Вы догадаетесь обнаружить что в ПР нет массивов, нет управления передачей данных по последовательному порту и т.д. и т.п.

Да я уже неделю этим занимаюсь - все уже обнаружил и все переписал в симуляторе, кроме вот этого злосчастного времени цикла, массивы не нужны, ком не нужен, от кана бы не отказался, но даже не заикаюсь об этом, тем более нашел как обойтись за счет двух АО. Если время цикла действительно фиксированное то вопрос закрыт - можно идти "пугать" Заказчика изделием отечественных заводов, что он на это скажет это уже следующий вопрос, мое дело испытания проводить Есть вопросы по динамике аналоговых входов но судя по тому что там можно малые постоянные времени ставить тоже все нормуль. Вообще я конечно понимаю что херней занимаюсь - мне начальство так и сказало, но тут чисто спортивный интерес есть.

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

Да я уже неделю этим занимаюсь - все уже обнаружил и все переписал в симуляторе, кроме вот этого злосчастного времени цикла

Я тоже уже это пережил и взывал дать системные миллисекунды. Безуспешно. Это наверное очень сложно... Выкрутиться можно косвенными методами через подсчёт циклов. Так все пока делают. Хотите готовый макрос измерения интервала в мс? Досадно что приходится делать лишние вычисления при и так большой программе. Макрос который в базе чрезмерно навороченный.

[nickbeljaev]

Я тоже уже это пережил и взывал дать системные миллисекунды. Безуспешно. Это наверное очень сложно... Выкрутиться можно косвенными методами через подсчёт циклов. Так все пока делают. Хотите готовый макрос измерения интервала в мс? Досадно что приходится делать лишние вычисления при и так большой программе.

Сергей, благодарю, этот макрос я уже посмотрел, все там просто - посчитали количество циклов за одну секунду пусть будет х, тогда tau_us=(1000000+shr(x,1))/x, вопрос только в одинаковости этих циклов - на него пока нет строго ответа - в документации про это не сказано, а Юрий и Kapzar выразили, кажется, свое предположение на эту тему. Кроме того должен заметить, что миллисекундного таймера не достаточно - предположим мы хотим что то дифференцировать по времени примерно 100 раз в секунду - вполне реально для этого "реле", в мс таймере мы получим период 9, 10 или 11 в зависимости от того как карта ляжет, это разрешающая способность 10% это плохо. Стандартный таймер для современных ПЛК это мкс, тогда даже ничего пересчитывать не надо - куча готовых алгоритмов доступна. Но Юрий уже вроде объяснил, что у них нет желания создавать конкуренцию своим ПЛК, лично мне этого не понять - если не купят ПР то купят допотопного но не урезанного и надежного немца, или мутного но суперсовременного китайца, тут кажется не до внутренней конкуренции - внешнюю бы перемочь. Но где я со своим мнением и где Овен со всеми его манагерами, бухгалтерами и экономистами, хотя я это тут пишу не просто так пишу, конечно, а в надежде на подвижки.