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

[nickbeljaev]

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

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

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

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

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

[nickbeljaev]

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

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

[nickbeljaev]

стесняюсь спросить это формула чего? Что она доказывает в преимуществе использования микросекунд и миллисекунд? Закономерность изменения от количества циклов одна и таже

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

[nickbeljaev]

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

Видимо Вы рассуждаете в числах с плавающей точкой. Я рассуждаю в целых, дело в том, что мне жалко времени на программное деление чисел с плавающей точкой. Если вести все расчеты в числах с плавающей точкой, то Вы правы - единицы времени роли почти не играют. Хотя когда речь идет о 32 битных числах с плавающей точкой возможны сюрпризы с точностью.