Например генератор импульсов поставить, с временем включённого-выключенного состояния = 1мс, тогда период импульсов будет = 2 мс, если время цикла программы не более 1 мс(зависит от сложности программы)! В любом случае время включённого-выключенного состояния не может быть меньше времени цикла программы!Сообщение от nickbeljaev
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Хорошо, я сделал генератор с периодом состояния ровно в цикл, дальше, как мне узнать чему был равен период этих состояний.
Как это работает сейчас - есть ФБ (или системная переменная, без разницы) возвращающий тики какого то однородного счетчика (с известным периодом) в недрах ПЛК, беря на каждом (или не на каждом, а когда надо) шаге циклическую разность с ранее сохраненным значением этого счетчика я получаю весьма точный интервал времени в мкс прошедший с крайнего сохранения этого значения, такой подход удобен - есть во всех кодогенераторах с которыми я имел дело, применяется в куче алгоритмов вычисляющих всякие там скорости нарастания. На сколько я знаю по своему опыту, в реализации тоже ничего невозможного нет - так же как секунды отдают пользователю, так и микросекунды циклические можно отдавать. Не вижу причин к сопротивлению. Можно, конечно дифференцировать по фиксированному периоду, но фишка в том что он на самом деле не такой уж фиксированный, например TON 1с при качании времени цикла вокруг 10мс будет составлять от 1 до 1.01 (1% джитера в принципе приемлемо), а если нужно дифференцировать чаще, например 10 раз в секунду то период будет врать в том же времени цикла то есть уже 10% неопределенности и ваш объект управления перестает попадать цель. Возможно мотивация Овена чисто маркетинговая - "вон вам ПЛК за 30 - его и покупайте, и нечего на ПР тут миллиметры ловить", но ПЛК у них пока не конкурентные (прошу прощения за такую оценку - ноя думаю у Овена еще все впереди и искрене желаю удачи), а вот ПР при его современном и быстром проце мог бы попробовать заменить многие устаревшие модели иностранных ПЛК. Тем более сейчас растет спрос на бюджетную автоматику "для бедных".
Последний раз редактировалось nickbeljaev; 21.01.2020 в 16:55.
В общем +- так и есть, даже если гипотетически вывести микросекундные тики, они Вам чем помогут, если время цикла будет 5 мс. Точнее чем 1 мс все равно не получится считать, именно на этом и построен макрос Time_U/D, внутри автоматом выбирается точность вывода времени, в зависимости от времени цикла программы, который кстати, рассчитывается в самом начале, и не должен меняться, независимо от ветвлений или других процессов.
С уважением, Ревака Юрий.
Инженер группы технической поддержки компании "ОВЕН"
e-mail: yu.revaka@owen.ru
Шаблон описания ошибки ПР или OL http://ftp-ow.owen.ru/softupdate/OWE...s/Shablon.docx
Видео уроки по ПР200 и OWEN Logic http://edu.owen.ru/series/pr200_rev/
Другие видеоролики по тематике ПР https://www.youtube.com/channel/UCj4...H5H3d_t6iDlQOQ
Так это Вы оперируете временем восхода и заката, а я оперирую тележкой едущей со скоростью 1м/с по цеху - все мы разные. Сейчас там работает немецкий контролер с циклом 6..8мс, но за счет грамотной математики справляется, и одной из перемененных в этой математике является время прошедшее с предыдущего цикла регулятора, причем время это не в "штуках циклов", а в микросекундах, про разницу я уже выше объяснял.
Юрий, должен ваше мнение опровергнуть, сейчас на этом месте работает немецкий контроллер с циклом 6..8мс в регуляторах которого используется период каждых 4 событий в микросекундах, события достаточно редкие что бы ПР успел их схватить программным счетчиком но делить надо на достаточно точное время, которое взять пока неоткуда, так как есть подозрения, что среднее время цикла за 1с не совсем отражает время конкретных N циклов, по крайней мере точность такого измерения не доказуема. Но если дело в маркетинге - жаль, тут конечно ничего не поделать - маркетинг он такой.
Не сразу дошло про "рассчитывается в самом начале, и не должен меняться, независимо от ветвлений или других процессов", если это так то среднее время цикла за 1с годится, но похоже это не так иначе вообще какой смысл в TIME_CYCLE вбил константу и поехал без всяких расчетов. Если бы можно было получить консультацию по этому вопросу, в смысле гарантию того что время цикла строго фиксировано (это может быть если юзерская программа крутится не раундробином, а строго по прерыванию таймера причем не маскируемого), то это решило бы проблему.
Кажется "petera" писал(точно не помню), что делал таймеры на основе подсчёта количества циклов программы и время очень точно отсчитывалось!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Вопрос не по циклам. Что вы такое возите на таких скоростях. Как бывший сотрудник Отис так для сравнения могу сказать что модель европа2000 едет со скорость 0,8мСекунду. Может можно как то по другому управлять скорость тележка.
Я не капли не сомневаюсь что Вы бы все настроили грамотно, но Вы надеюсь достаточно заняты другими задачами и нашей тележке ваша "настройка" пока не угрожает. Что касается немецкого "контроллера", то у него 16-ти битный 25МГц. проц из 90-х. А у Овеновского "реле" 32-х битный 72МГц так кто из них скорее "реле", а кто "контроллер"? С аппаратной периферией у немца конечно получше, но это чисто заслуга Овена из маркетинговых соображений постеснявшегося заюзать все то, чем так богаты современные СТшки.
Игорь какая разница чего она возит? Она сейчас это возит вот с этой самой скоростью, и это не лифт. Меня просто спросили зачем таймер я максимально подробно рассказал с привлечением конкретного примера, теперь Вы спрашиваете чего мы возим, следующий вопрос сколько мы за это получаем наверное
Ваши права
Ответить с цитированием