Вид для печати
Во многих проектах применяю таймеры сделанные на принципе суммирования или вычитании секундных импульсов, выдаваемых генератором (BLINK,GEN_PULSE и т.п) и дальше на CTU или ADD, при малых интервалах времени всё нормально, но при интервалах час и более погрешность довольно существенная, как убрать эту погрешность?
использовать встроенные таймеры ... или выделять в отдельный таск BLINK + все где ADD или CTU
С родными таймерами то-же геморроя много например при сохранении в файл, в отдельный выделить не получиться если только тактовый генератор, да и не думаю что это сильно повлияет
А от RTC ПЛК синхронизироваться не пробовал ?
Каким образом вытянуть секундный(или милисекундный) импульс если по изменению то время уйдет на обработку, опять погрешность
Звучит как накопление погрешности. Покажите конкретные примеры кода.
Да так оно и есть, весь код не выкладываю именно счетчики так примерно как они реализованы в программе, только по упрощенной схеме, без включений, блокировок и т.д т.пЦитата:
Сообщение от Yegor
Вложение 18550
если родные часы ПЛК трындят, то что с чем будем синхронизировать ?
На сколько трындят ?Цитата:
Сообщение от melky
Как Чистопольские часы , командирские .:pЦитата:
Сообщение от Вольд
А где наши столпы capzap и валенок?
А что ? Что "Столпы" то?Цитата:
Сообщение от жекон
Возможный рецепт :
1. Задействовать Task Manager. (Возможно принудительный запуск задачи "нагнет" ПЛК более дисциплинированно выполнять-обслуживать цепочку вызовов).
2. Создать задачу + программу с периодом вызова 1с .
3. В программе написать что-нибудь типа - Time_tik_1s:=Time_tik_1s+1 ; Flag_1s:=true;
Пробуйте
потому что программных способов не существует повысить точность дешевых часов реального времени в плк, поэтому и сказать нечего
ну так для информации, я пользуюсь функцией TIME(), а не блинкерами всякими. А если синхронизировать часы, то брать их если не из ntp, то хотябы с панели
В ПЛК "ОВЕН" используются дешевые низкостабильные кварцевые резонаторы и в этом вся проблема. Если синхронизироваться от RTC ПЛК, то раз в сутки надо делать программную корректировку времени. Например, если RTC уходят за сутки на 50 сек., то эти самые 50 сек. надо вычитать из текущего времени.
Да речь не том чтобы повысить точность часов , хотя бы получить более менее стабильный импульс , с панели брать не уверен что там лучше часики стоят потому как время корректирую иногда
Мысли и были в развитие этого сценария но пока только мысли попробую отпишусьЦитата:
Сообщение от Sergey666
По моему опыту работы в датчикостроении, Вы наговариваете на изготовителей кварцев. Любой кварц может не завестись. Но если завёлся, свою частоту держит достаточно точно, в пределах секунды в сутки.Цитата:
Сообщение от Вольд
Поддерживаю целиком и полностью. Когда пишу на ST, только так, никаких TON и TOF. Особенно после того, как убедился, что и они гарантируют накопление ошибки из-за того, что программа всегда выполняется спустя какое то время после срабатывания таймера. Эта разница времён и накапливается в каждом цикле, всегда с одним знаком.Цитата:
Сообщение от capzap
Повторюсь еще раз мне не важно что таймер будет накапливать, мне нужно что-бы он отрабатывал здесь и сейчас с максимально возможной точностью
Всё правильно так как лажануть негде кусок камняЦитата:
Сообщение от rwg
этому камню обеспечено стабилизированное питание, хоть какая нибудь система охлаждения?Цитата:
Сообщение от жекон
Кварцевые резонаторы бывают разные. Относительная погрешность настройки частоты кварцевого резонатора с резонансной частотой 32768 Гц (часовой кварц) много больше чем у кварцевого резонатора с частотой 10 мГц.Цитата:
Сообщение от rwg
"При выборе резонатора для генератора особое внимание следует обращать на добротность резонатора - чем она выше, тем стабильнее частота. Наибольшей добротностью обладают вакуумированные резонаторы. Но чем добротнее резонатор, тем он дороже. Часто встречаются резонаторы с большим уровнем побочных резонансов."
Таким образом, все дело в кварцевом резонаторе. Он единственный источник погрешности при отсчете времени.
Скорее всего фирма "ОВЕН" использует в своих приборах хреновенькие часовые (32768 Гц) кварцевые резонаторы.
Повторюсь, не пользуйтесь таймерами, сделанными на принципе суммирования секундных импульсов, пользуйтесь функцией TIME. Только так Вы можете обеспечить максимально высокую точность. Погрешность 10 мсек в секунду у Вас оборачивается погрешностью 40 секунд в час.Цитата:
Сообщение от жекон
Если бы около 10 минут, т б если выдержка 4 часа то в реале получается 4,4Цитата:
Сообщение от rwg
И вся фишка в том что ПЛК отрабатывает свой цикл Пытался попробовать его вычислить путем подбора на том же блинке ни фига не получилось
Если секундные импульсы суммировать с периодом работы программы 100мс, то так вполне может получиться. Импульсы будут прибавляться раз в 1,1 секунды.Цитата:
Сообщение от жекон
У меня есть задача вести временной отсчет текущего процесса с точностью встроенных часов. Каким образом можно получить импульсы со встроенных часов для последующего подсчета?
При каждом новом цикле процесса начинается новый отсчет. Как еще можно реализовать обратный временной отсчет?
Проект в Codesys 3.5.
Это можно реализовать вычитаением. Сохраняете момент начала цикла, потом вычитаете из заданного времени разницу между текущим временем и сохранённым - получите обратный остчёт.Цитата:
Сообщение от СергейНовосиб
Подскажите по функции TIME(). Достигнув максимального времени 49d17h2m47s295ms (4194967295 ms) отсчёт начнётся с 0? Решил отказаться от таймеров TON, TP... Но я так понимаю, что при использовании TIME() нужно раз в 49 дней производить коррекцию текущих счётчиков, основанных на этой функции?Цитата:
Сообщение от capzap
сперва попробуйте вычесть из например 15 число 4294967285, где предположим 4294967285 - начало замера времени, 15 - соответственно конецЦитата:
Сообщение от Sergeba
Пока не пробовал, но в справке нашёл такую фразу: "Переменной TIME можно присвоить результат вычитания двух других переменных типа TIME. Отрицательное время не определено."Цитата:
Сообщение от capzap
Тип данных TIME - аналог типа данных UDINT (0...4294967295).Цитата:
Сообщение от Sergeba
При вычитании из меньшего большего произойдет переход через "0", с учетом нуля как полноценного шага измерения.
К примеру, при вычитании из 1ms 4294967295ms мы получим на выходе 2 ms.
Эту "особенность" необходимо учитывать при работе с типом данных TIME.