Вид для печати
ДОбрый день.
ПОмогите разобраться со счетчиками быстрых входов.
У них есть переменная "Период импульса". По логике вещей период импульса - время между фронтами соседних импульсов. Но что-то у меня не вяжется. По значению примерно то-же что и "Длительность импульса" (значение по моим наблюдениям соответствует реальной длительности импульса.
Что за значения сохраняются в переменной "Период импульса" и как правильно их обрабатывать?
Заранее признателен
Никто не может пояснить? Где почитать?
Может я не правильно пояснил - Вопрос не о выходах, а о счетных входах. На входе не задается ни длительность импульса, ни период. В этих переменных (если быть точным то в каналах счетных входов) сохраняются измеренные значения параметров импульсов на быстром входе. И вопрос или непонимание в том, что в канале "Период импульса" сохраненное значение не соответствует реальному периоду импульса. Соответственно либо я не правильно настроил к***** либо туда ядром (или RTE) записывается неправильное значение.Цитата:
Сообщение от capzap
А мне очень желательно использовать этот функционал для более точного измерения параметров входного импульса. Но пока не очень получается
Я так понимаю Вы вообще не поняли сути вопроса! Я не спрашиваю о очевидных вещах, я спрашиваю почему там где должно быть записано значение ПЕРИОДА ИМПУЛЬСА его нет?Цитата:
Сообщение от capzap
Поясняю подробнее. Я специально сделал скрин. Для быстрого входа 3 "канала" (они так названы): 1. Значение счетчика - количество посчитанных импульсов с начала работы программы или с момента последнего сброса счетчика (думаю с этим все понятно). Канал доступен на чтение/запись; 2. Период импульса - то есть это ДОЛЖНА БЫТЬ длительность между фронтами двух соседних импульсов. Кратно 5 мкс. Но по факту полная чушь. ниже поясню (если кому надо объяснить очевидные вещи). 3. Длительность импульса - время между передним и задним фронтом импульса.
Если здесь все ясно, перехожу к описанию проблемы: Написал простейший код, привязал переменные к указанным каналам входа, подал периодический прямоугольный сигнал (допустим с периодом 1 Гц). Длительность импульса - 300 мс, период - 1 с. В канал "Значение счетчика"(1) - пишется сколько импульсов пришло, в "Длительность импульса"(3) - длительность импульса ( для 300 мс. это 60000), НО в канале "Период импульса" - расчетное значение 200000 (1 сек), а по факту от 60000 до 80000. Вопрос - почему такое значение.
И, кстати, если частота входного сигнала будет меняться какое значение будет записано в канал "Период импульса" - последнее измеренное, среднее, минимальное, максимальное? какое?
Вы издеваетесь или прикалываетесь?Цитата:
Сообщение от capzap
При чем здесь немцы?Цитата:
Сообщение от capzap
Я Вам сообщаю - RTE (или ядро) пишет значения в канал которые не соответствуют реальным величинам. Или каналу дали не правильное название. Или Вы разрабатывали таргет-файлы и можете что-то сообщить по этому поводу?
Вы скрин смотрели? я прикрепил в первом постеЦитата:
Сообщение от capzap
Вопрос был "Что за значения сохраняются в переменной "Период импульса" "Цитата:
Сообщение от capzap
Я что-то пропустил?
Это Вы считаете ответом на вопрос: "Что за значения сохраняются в переменной "Период импульса"Цитата:
Сообщение от capzap
Среда исполнения, я так понимаю. Входы и каналы описаны в таргете. Я в них ничего не пишу, только читаю.
Если-бы в них писал я, то не стал-бы задавать вопросов другим.
Опишу свой проект и способ обнаружения проблемы.
В моем проекте на быстрый вход повешен выходной сигнал сервопривода, который переключается из низкого логического уровня на высокий при достижении заданного положения. В данный момент я ловлю событие на указанном входе в MAIN_TASK через R_TRIG. Цикл вызова MAIN_TASK - 8ms. Время выполнения кода 500-700us с джиттером +- 1- 1,5 ms. В коде минимальный период импульса - 100-150ms максимальный 1-1,2 секунды (!) . Период и длительность импульса меряется вполне удовлетворительно, никаких пропусков или глюков нет. Т.е. сигнал 100% не имеет периода, соизмеримого с длительностью импульса, Период значительно больше, но TARGET-функционал ПЛК считает иначе.
Изначально я хотел использовать функционал ПЛК для мониторинга и более точной оценки временных характеристик сигнала, НО возникла описанная выше проблема. ПОэтому я изменил код в соответствии с описанием в данном посте.
Я, конечно, чтобы снять все вопросы выход этого-же ПЛК настрою на ШИМ, и померяю чего там на входе, дабы самому убедиться что у меня все верно, ну и отдать более развернутый диагноз.
Вопрос мне покоя не дает. Т.к. решение этой проблемы повысило бы качество работы проекта.
ДОброго времени.
Наконец-то смог вернуться к проекту и таки разобрался с быстрыми входами. По факту - не такие уж они и быстрые :).
Что сделал. Перевел один из быстрых (:D) выходов в режим генератора импульсов (Период = 1 с.; Длительность = 0,5с.) и через реле завел сигнал на быстрый вход.
У быстрого входа имеется "Настройка фильтра дискретных входов" и два параметра "Период измерений фильтра", "Количество измерений фильтра".
Описания данных параметров я не нашел, отсюда и путаница.
Интуитивно догадываюсь что "Период измерений фильтра" определяет с какой периодичностью будет опрашиваться состояние входа , а "Количество измерений фильтра" - сколько раз. И, видимо, по определенному алгоритму определяется состояние входа (0, 1) ну и характеристики сигнала (длительность, период).
Так вот, если значения оставить по умолчанию: т.е. период опроса 5 мкс, количество - 1 раз, то получается полная чехарда, из-за помех, дребезга контактов и пр.
При
Я поставил период опроса - 1 мс. Количество раз - 16. И параметры сигнала стали более-менее соответствовать реальному.
Но что получается в этом случае? Мы 16 раз через 1 мс. проверили состояние входа и только после вычислили характеристики сигнала. Т.е. речь уже идет не о микросекундах, а о мили. В таком случае это уже и не такой быстрый вход.
Возникает вопрос - какие значения параметров ("Период измерений фильтра", "Количество измерений фильтра") являются приемлемыми?
И более того - чтобы счетчик работал корректно мне должны быть известны (хотя-бы приблизительно) характеристики входного сигнала. А если характеристики неизвестны?
С периодом фильтра 50 мкс и количеством измерений - 8. Для сигнала 1/0,5 сек. считает +- точно. При количестве измерений = 2: много ошибок
Они описаны в документации по таргет-файлам:Цитата:
Описания данных параметров я не нашел, отсюда и путаница.
https://ftp.owen.ru/CoDeSys3/11_Docu...rgets_v2.4.pdf
Цитата:
получается полная чехарда, из-за помех, дребезга контактов и пр.
Вас это удивляет? Или вы ожидаете, что ПЛК должен каким-то образом устранить "помехи и дребезг контактов"?Цитата:
Т.е. речь уже идет не о микросекундах, а о мили. В таком случае это уже и не такой быстрый вход.
Критерии приемлемости определяются внешними факторами (например, характеристиками входного сигнала).Цитата:
Возникает вопрос - какие значения параметров ("Период измерений фильтра", "Количество измерений фильтра") являются приемлемыми?
Тогда требуется установить их экспериментальным путем.Цитата:
И более того - чтобы счетчик работал корректно мне должны быть известны (хотя-бы приблизительно) характеристики входного сигнала. А если характеристики неизвестны?
Тут тогда получается вот какая штука (применительно к моему "клиническому" случаю):
При характеристиках сигнала 1/0,5 быстрый вход начинает корректно работать при периоде 50 мкс, 16 измерений (надежно, без ошибок и т.д.) определенная погрешность есть (я ее не считал), визуально отклонение +- 0,5 милисекунды. Для меня более чем. 50 * 16 = 0,8 милисек. При том, что у меня цикл MAIN_TASK 8 мс. использование быстрого входа дает прирост точности более чем 5 раз.
Таким образом использование быстрого входа освобождает часть программных ресурсов и упрощает обработку прогнозируемого, изменяющегося в небольшом диапазоне входного сигнала.