Просмотр полной версии : ПР103. Измерение скорости энкодером.
День добрый!
Собственно с быстрого входа получаем целочисленное значение количества импульсов энкодера.
Для замера скорости надо ловить фронт импульса. Типа померить время между соседними передними или задними фронтами.
Встает вопрос: как из "INT" сделать типа "CLK" ? или как поймать соседние фронты в переменной инт ?
Заранее благодарен!
kondor3000
03.08.2025, 12:21
Вот делал для энкодера ЛИР, 1024 импульса на оборот (можно убрать). Измерение каждую секунду.85138
Добавлен эмулятор энкодера, для проверки работы и частотомер.
Благодарю!
Есть нюанс )). Ты измеряешь количество импульсов за промежуток времени. При большой скорости или высоком разрешении энкодера - точность нормальная.
У меня энкодер делает оборот примерно за минуту (600 имп/об) (экструдер) Измеряю не обороты в минуту а скорость метры/минуту, хотя это не важно.
При замере скорости подсчетом импульсов скорость скачет от измерения к измерению +- до 5 см/мин. Думаю это потому, что измерение надо привязать к фронту.
А лучше вообще померить время между фронтами.
kondor3000
03.08.2025, 13:24
Благодарю!
Есть нюанс )). Ты измеряешь количество импульсов за промежуток времени. При большой скорости или высоком разрешении энкодера - точность нормальная.
У меня энкодер делает оборот примерно за минуту (600 имп/об) (экструдер) Измеряю не обороты в минуту а скорость метры/минуту, хотя это не важно.
При замере скорости подсчетом импульсов скорость скачет от измерения к измерению +- до 5 см/мин. Думаю это потому, что измерение надо привязать к фронту.
А лучше вообще померить время между фронтами.
Это пример работы, возможно измерять надо не раз в секунду, а раз в 10 -60 сек, тогда точность будет выше.
Там даже изначально, было измерение раз в минуту (или раз в 10 сек). Константы только поменять.
Для измерения времени между фронтами, можно использовать таймер в мс, точнось измерения мс, зависит от времени цикла программы.
Новый таймер TON_P c ET и паузой, на ST, Версия 2.6.345.0____https://owen.ru/forum/showthread.php?t=38239&page=42#420
Это пример работы, возможно измерять надо не раз в секунду, а раз в 10 -60 сек, тогда точность будет выше.
Там даже изначально, было измерение раз в минуту (или раз в 10 сек). Константы только поменять.
Для измерения времени между фронтами, можно использовать таймер в мс, точнось измерения мс, зависит от времени цикла программы.
Новый таймер TON_P c ET и паузой, на ST, Версия 2.6.345.0____https://owen.ru/forum/showthread.php?t=38239&page=42#420
Да, увеличивая время измерения - увеличивается точность но снижается оперативность. С таймером проблем нет. Вопрос - как выделить фронта ? )) Как сделать F_TRIG для целочисленной переменной ))
Сергей0308
03.08.2025, 13:50
День добрый!
Собственно с быстрого входа получаем целочисленное значение количества импульсов энкодера.
Для замера скорости надо ловить фронт импульса. Типа померить время между соседними передними или задними фронтами.
Встает вопрос: как из "INT" сделать типа "CLK" ? или как поймать соседние фронты в переменной инт ?
Заранее благодарен!
Так можно отслеживать изменение значения переменной, время между изменениями и будет периодом следования импульсов.
kondor3000
03.08.2025, 13:56
Да, увеличивая время измерения - увеличивается точность но снижается оперативность. С таймером проблем нет. Вопрос - как выделить фронта ? ))
Сравнением предыдущей переменной с новой, на линии задержки 85150
Импульс при изменении переменной, запускает таймер на нужное время.
Сравнением предыдущей переменной с новой, на линии задержки 85150
Импульс при изменении переменной, запускает таймер на нужное время.
ВО !!!!! Я чувствовал что есть простое решение, но сам дойти не смог )))
Благодарю !!
Сергей0308
03.08.2025, 15:31
В принципе значения счётчика быстрых входов могут меняться гораздо быстрее цикла программы, поэтому лучше искать разность значений и для определения среднего периода следования импульсов надо подсчитанное вами время делить на эту разность.
В принципе значения счётчика быстрых входов могут меняться гораздо быстрее цикла программы, поэтому лучше искать разность значений и для определения среднего периода следования импульсов надо подсчитанное вами время делить на эту разность.
Согласен. Но в данный момент длительность цикла порядка 2 мс а период импульсов порядка 10-15 мс
Сергей0308
03.08.2025, 18:10
Согласен. Но в данный момент длительность цикла порядка 2 мс а период импульсов порядка 10-15 мс
Мне кажется лучше не начинать каждый проект с "0", в смысле, создать более-менее универсальный макрос для той или иной функции и можно его использовать не только в текущем проекте, но и в любом последующем, не потребуется его заново придумывать и создавать!
Мне кажется лучше не начинать каждый проект с "0", в смысле, создать более-менее универсальный макрос для той или иной функции и можно его использовать не только в текущем проекте, но и в любом последующем, не потребуется его заново придумывать и создавать!
Согласен )).
Как же удачно подобран энкодер под задачу.;)
Как же удачно подобран энкодер под задачу.;)
что не так ? Вообще то его задача измерять длину. И с этой задачей он хорошо справляется. Измеряет с точностью 0,5 мм
что выше крыши в несколько раз. А измерять скорость - это хотелка, возникшая в последствии.
.............А измерять скорость - это хотелка, возникшая в последствии.
Тут вы 100% правы, это хотелка на качество изделия никак не влияет, да? Измеряйте за 30 сек и не парьтесь.
Можно использовать сглаживание (https://pro.arcgis.com/ru/pro-app/3.4/tool-reference/spatial-statistics/how-time-series-smoothing-works.htm)
Тут вы 100% правы, это хотелка на качество изделия никак не влияет, да? Измеряйте за 30 сек и не парьтесь.
Я не парюсь )). Если есть возможность решить задачу хорошо - зачем ее решать плохо ? Да, и по ходу решения, обретаются новые знания и опыт.
Из этой ветки я вынес хорошие знания. А пошел бы я по Вашей схеме - я бы этих знаний не приобрел )
Можно использовать сглаживание (https://pro.arcgis.com/ru/pro-app/3.4/tool-reference/spatial-statistics/how-time-series-smoothing-works.htm)
Благодарю! Обязательно изучу. Интересная тема.
....ну длительность цикла порядка 2 мс а период импульсов порядка 10-15 мс
Расчёт делать в момент изменения кол-ва импульсов, но за базовый период не менее 200..300мс (2мс / 0.01). Это даст и точность до 1% и реактивность.
Ну и определится с максимальным временем между 2 импульсами больше которого расход считается 0-ым. А толкание расхода определять не ранее 2-ого импульса после определения факта 0-ого расхода но и не ранее базового периода. Но если нужен сам факт начала расхода - то просто со 2-ого.
Всё эти сглаживания сводятся к игранию с базовым периодом.
Ничего более универсального просто нет.
Например совет ВЕТРА (уж не знаю как склонять) то же самое, только избыточная точность.
B.S.V
делает оборот примерно за минуту (600 имп/об) (экструдер)
Экструдер делает что? Если ПП\ПЭ лист методом проката (судя по медленности процесса), то почему бы не использовать фактическую скорость двигателя прокатного вала, которую можно прочитать в самом ПЧ. В таких делах проскальзывание приводит к браку, поэтому точность измерения весьма высока. Т.е. скорость двигателя*коэфф=линейная скорость поверхности вала.
B.S.V
Экструдер делает что? Если ПП\ПЭ лист методом проката (судя по медленности процесса), то почему бы не использовать фактическую скорость двигателя прокатного вала, которую можно прочитать в самом ПЧ. В таких делах проскальзывание приводит к браку, поэтому точность измерения весьма высока. Т.е. скорость двигателя*коэфф=линейная скорость поверхности вала.
Какой грамотный совет... учитывая что нету никакого прокатного вала ))))
B.S.V
У меня на производстве три разных вида экструдеров. Кардинально разных. Ни у одного не сделан замер скорости продукта энкодером по продукту. Практически на всех от скорости валов. Вы не указали тип своего экструдера.
Расчёт делать в момент изменения кол-ва импульсов, но за базовый период не менее 200..300мс (2мс / 0.01). Это даст и точность до 1% и реактивность.
Ну и определится с максимальным временем между 2 импульсами больше которого расход считается 0-ым. А толкание расхода определять не ранее 2-ого импульса после определения факта 0-ого расхода но и не ранее базового периода. Но если нужен сам факт начала расхода - то просто со 2-ого.
Всё эти сглаживания сводятся к игранию с базовым периодом.
Ничего более универсального просто нет.
Например совет ВЕТРА (уж не знаю как склонять) то же самое, только избыточная точность.
Обожаю Ваши комментарии. После них чувствую себя полным идиотом )))
Что Вы подразумеваете под "расходом" ?
B.S.V
У меня на производстве три разных вида экструдеров. Кардинально разных. Ни у одного не сделан замер скорости продукта энкодером по продукту. Практически на всех от скорости валов. Вы не указали тип своего экструдера.
Речь не про экструдер, поэтому и не указывал тип экструдера ). Полимерная фасадная доска. никаких тянущих нет. Измерительное колесо катится по доске. По нему происходит отрез
заданной длины.
.. Что Вы подразумеваете под "расходом" ?
А не все ли равно? Вы видите 2 вещи - импульсы и время. Отсюда есть только счёт и частота.
А к импульсу что прикрутите, то и будет по времени. Обьем/массу - будет расход. Миллиметры/парсеки - скорость. Ну можете еще 2-ю производную по времени взять, получите скорость изменения расхода и ускорение соответственно.
Что делать универсально с частотой - выше привёл. Всё остальное - вариации этого. Но во всех случаях следует учитывать неточность кванта времени относительно периода измеряемого времени.
А не все ли равно? Вы видите 2 вещи - импульсы и время. Отсюда есть только счёт и частота.
А к импульсу что прикрутите, то и будет по времени. Обьем/массу - будет расход. Миллиметры/парсеки - скорость. Ну можете еще 2-ю производную по времени взять, получите скорость изменения расхода и ускорение соответственно.
Что делать универсально с частотой - выше привёл. Всё остальное - вариации этого. Но во всех случаях следует учитывать неточность кванта времени относительно периода измеряемого времени.
Вот теперь понял! Благодарю!
.........Измерительное колесо катится по доске. По нему происходит отрез заданной длины.
Наконец то секретные данные выложил. Т.е. постоянно знать точную скорость не нужно и ничего от этой скорости не зависит.
Так вам тут и импульсы не нужны. Засекайте время между запусками ножа, расстояние уже известно.
Ну или засекайте время через каждые полметра например, или 50 мм если доска очень медленно идёт.
Из-за того, что начало периода измерения может смещаться относительно начала периода следования импульсов, то при последовательной фиксации подсчитанных импульсов будет какое-то количество с +1 импульсом. И при большом весе импульса - это очень заметно. Мне помогло сглаживание.
Т.е. ФБ подбирает период следования так, чтобы расчетное кол-во импульсов совпадало с фактическим во время фиксации.
Численных методов синхронизации на любой вкус! (скорость схождения, ширина мертвой зоны, глубина отсчета, время реакции и т.д.)
Наконец то секретные данные выложил. Т.е. постоянно знать точную скорость не нужно и ничего от этой скорости не зависит.
Так вам тут и импульсы не нужны. Засекайте время между запусками ножа, расстояние уже известно.
Ну или засекайте время через каждые полметра например, или 50 мм если доска очень медленно идёт.
Постоянно не нужно. Но операторы к ней привязываются когда разгоняют экструдер. Задача стояла резать с точностью +- 5мм. Я сделал что бы резало с точностью +- 1 мм.
Они: Круто! А скорость мерить может? Я - Конечно ! И встрял )))
Из-за того, что начало периода измерения может смещаться относительно начала периода следования импульсов, то при последовательной фиксации подсчитанных импульсов будет какое-то количество с +1 импульсом. И при большом весе импульса - это очень заметно. Мне помогло сглаживание.
Т.е. ФБ подбирает период следования так, чтобы расчетное кол-во импульсов совпадало с фактическим во время фиксации.
Численных методов синхронизации на любой вкус! (скорость схождения, ширина мертвой зоны, глубина отсчета, время реакции и т.д.)
Про какой ФБ речь идет ? Я нормальной точности пока не получил.
При замере скорости подсчетом импульсов скорость скачет от измерения к измерению +- до 5 см/мин.
Я правильно понимаю, что Вы подсчитываете импульсы за какой-то интервал и умножаете на вес импульса (1 имп = ? см)?
Вы можете измерить именно число накопленных импульсов от измерения к измерению за тот же интервал времени?
Надеюсь Вы понимаете, что считывание счетчика быстрого входа происходит асинхронно? Т.е. интервал может меняться +- несколько мс.
Если Вы найдете максимальную разницу (дельту) между измерениями и объявите её мертвой зоной, то сможете избавиться от скачков при индикации.
Т.е. если следующее измерение не превысело текущее на величину дельты, то сохраняем текущее значение, иначе изменяем его на измеренное.
А лучше на среднеарифметическое между текущим и следующим.
Надеюсь, что написать свой ФБ Вы сможете самостоятельно.
Сергей0308
05.08.2025, 20:44
Насколько понял, он измеряет период следования импульсов, я так понимаю циклами программы, короче, при заявленных времени цикла программы = 2 мс и периодом следования импульсов 10 - 15 мс, точность измерения составит один цикл программы или плюс-минус 20%.
AlexandrGr
05.08.2025, 21:26
А цикл программы фиксированный?
А цикл программы фиксированный?
А какая разница? Реальный фронт может прийти в любой момент на протяжении супер-пупер-фиксированного времени и вы всегда будете получать плюс минус 2мс к супер-пупер-точным измеренным 10-15мс.
И наоборот, как бы не болтался рандомно цикл, за сотню таких циклов точность частоты приблизится к 1%. Нужно точнее - больше циклов, нужно реактивнее - меньше. Ничего другого не будет
Я паралельно иду двумя путями.
Первый - подсчет импульсов за период времени.
Второй - замер времени между импульсами.
Погрешность примерно одинаковая, но странно большая.
Для определения длительности цикла использовал Овеновский фб CycleTime. Это чисто понять - успею посчитать или нет. Он показал цикл 2 мс.
Примерная скорость 0,4 м/мин . Измерительное колесо 600 имп на 300 мм. Получается имеем 800 имп в минуту. ~ 1 имп в 77 мс. - технически времени выше крыши.
Для измерения времени использую GET_TIME().
Я бы понял если бы погрешность была бы +- пару мм/мин. я имею сантиметры в минуту
щас приложу свои фб
function_block Speed
var_input
xPuls : bool;
end_var
var_output
Q : real;
end_var
var
rPuls : real := 0;
Time_1 : TIME := T#0ms;
Time_2 : TIME := T#0ms;
end_var
//**********************************************
//**********************************************
IF Time_1 = T#0ms THEN
Time_1 := GET_TIME();
END_IF
Time_2 := GET_TIME();
IF (Time_2 - Time_1) < T#30000ms THEN
if xPuls then
rPuls := rPuls + 1;
end_if
else
Q := rPuls / 1000;
Time_1 := T#0ms;
rPuls := 0;
end_if
end_function_block
Не понял как вставлять. Извините.
Считаю импульсы. Здесь за период 30 сек. Пробовал и за 300 мс.
На вход подаю импульсы через сравнение с линией задержки как подсказал Kondor3000
Погрешность доходит до шести сантиметров - это 120 импульсов !!!
Измерительное колесо 600 имп на 300 мм. Получается имеем 800 имп в минуту. ~ 1 имп в 77 мс. - технически времени выше крыши.
Ну вот если главная задача (?) отмерить заданное расстояние, то каждый импульс это 0.5мм, а между импульсами это расчетное время (неплохой период - да)
Если скорость постоянная (? важно! потому что ТС сам не знает походу - см. ниже) то можно по последнему интервалу рассчитываться.
Заданное расстояние => в кол-во импульсов. Дробное!!
А дальше целое кол-во фронтов + доля времени к последнему периоду (который тут то 10 то 15 то около 77)
Стартовую позицию учесть по времени до 1-ого фронта с коррекцией последней доли и, возможно, общего кол-ва целых импульсов.
Не понятно - учитывать ли инерционность механизма или старт/стоп компенсируют друг друга.
Примерная скорость 0,4 м/мин .
скорость скачет от измерения к измерению +- до 5 см/мин.
2мс/77мс при замере между фронтами даст скачки 2..3%. Это не 10..15% (5см/0.4м) - но нужно ли это вообще?
И что это
Но в данный момент длительность цикла порядка 2 мс а период импульсов порядка 10-15 мс
~ 1 имп в 77 мс. -
В общем чётче - что имеете как обратную связь (импульсы и всё/не всё/звонок другу) и что имеете как управление. Кто скоростью рулит?
Сергей0308
05.08.2025, 23:22
Я паралельно иду двумя путями.
Первый - подсчет импульсов за период времени.
Второй - замер времени между импульсами.
Погрешность примерно одинаковая, но странно большая.
Для определения длительности цикла использовал Овеновский фб CycleTime. Это чисто понять - успею посчитать или нет. Он показал цикл 2 мс.
Примерная скорость 0,4 м/мин . Измерительное колесо 600 имп на 300 мм. Получается имеем 800 имп в минуту. ~ 1 имп в 77 мс. - технически времени выше крыши.
Для измерения времени использую GET_TIME().
Я так понимаю, Вы лёгких путей не ищете, в смысле, время цикла программы можно посмотреть в сервисном меню ПР200, а ещё проще в ОЛ, после заливки программы(проекта) в ПР.
Я так понимаю, Вы лёгких путей не ищете, в смысле, время цикла программы можно посмотреть в сервисном меню ПР200, а ещё проще в ОЛ, после заливки программы(проекта) в ПР.
ПР103 ). А про ОЛ не подумал
Ну вот если главная задача (?) отмерить заданное расстояние, то каждый импульс это 0.5мм, а между импульсами это расчетное время (неплохой период - да)
Если скорость постоянная (? важно! потому что ТС сам не знает походу - см. ниже) то можно по последнему интервалу рассчитываться.
Заданное расстояние => в кол-во импульсов. Дробное!!
А дальше целое кол-во фронтов + доля времени к последнему периоду (который тут то 10 то 15 то около 77)
Стартовую позицию учесть по времени до 1-ого фронта с коррекцией последней доли и, возможно, общего кол-ва целых импульсов.
Не понятно - учитывать ли инерционность механизма или старт/стоп компенсируют друг друга.
2мс/77мс при замере между фронтами даст скачки 2..3%. Это не 10..15% (5см/0.4м) - но нужно ли это вообще?
И что это
В общем чётче - что имеете как обратную связь (импульсы и всё/не всё/звонок другу) и что имеете как управление. Кто скоростью рулит?
Это экструдер. Скорость можно считать постоянной. Сложно раскачать экструдер что бы скорость скакала +- 5-6 см за минуту.
10 - 15 это было на вскидку. 77 - посчитано на Ваших глазах.
Нет обратной связи. Только импульсы с квадратурного энкодера + таймер в ПР. Скоростью рулит частотник который даже незнает про энкодер, да и не нужно ему это.
Расстояние я отмеряю с точностью 1 мм. ( 0,5 мм на 6 метрах сложно померить рулеткой) А вот скорость измеряю с точностью +- 5-6 см ! Хотя в теории - должен до +- 0,5 мм.
Но я понял проблему подсчета количества импульсов за дробную единицу времени.
Думаю надо идти по пути измерения времени между соседними фронтами. Я уже пробовал но забуксовал в обработке переменных типа TIME. Кривой алгоритм получился.
Точность нужна до 1 см/мин. мм/мин я отбрасываю.
function_block Speed
var_input
xPuls : bool;
end_var
var_output
Q : real;
end_var
var
rPuls : real := 0;
Time_1 : TIME := T#0ms;
Time_2 : TIME := T#0ms;
end_var
//**********************************************
//*****************
IF Time_1 = T#0ms THEN
Time_1 := GET_TIME();
END_IF
Time_2 := GET_TIME();
IF (Time_2 - Time_1) < T#30000ms THEN
if xPuls then
rPuls := rPuls + 1;
end_if
else
Q := rPuls / 1000;
Time_1 := T#0ms;
rPuls := 0;
end_if
end_function_block
Не понял, зачем считать импульсы, если энкодер и так их считает?
Берите разность за определенный период времени и обсчитывайте по пропорции
Сергей0308
06.08.2025, 00:35
Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!
Не понял, зачем считать импульсы, если энкодер и так их считает?
Берите разность за определенный период времени и обсчитывайте по пропорции
В первом варианте так и делал. Потом решил попробовать привязаться к началу фронта... нечего не поменялось. Но причина понятна. Я теряю "полуимпульсы" которые накапливаются при пересчете в минуты. Если считать за минуту - точность должна быть приемлемой. Но минута на ожидание реальной скорости - не приемлемо ))
Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!
В момент реза происходит откат на пару мм. Счет энкодером компенсирует, а счетчик их приплюсует как я понимаю.
Завтра попробую через период посчитать. Нашел ошибку в алгоритме.
Такой вопрос : если к примеру разделить 1 секунду на 625 мс получится 1 мс или 1.6 мс ?
Сергей0308
06.08.2025, 01:16
Завтра попробую через период посчитать. Нашел ошибку в алгоритме.
Такой вопрос : если к примеру разделить 1 секунду на 625 мс получится 1 мс или 1.6 мс ?
1 секунда это 1000 мс, если разделить на 625 мс, получится просто "1,6", в смысле, "мс" сократятся!
1 секунда это 1000 мс, если разделить на 625 мс, получится просто "1,6", в смысле, "мс" сократятся!
То есть, произойдет преобразование типов из TIME в REAL ?
Проверил - преобразования не происходит )
Самый точный, но тоже скачущий спидометр у меня получился так:
85201
function_block Freq
var_input
in : real; // Вход с текущим значением счётчика
end_var
var_output
F : real; // Частота или скорость
end_var
var
inOLD : real; // старое значение счётчика
tsOLD, ts : udint; // Фиксация системного таймера
end_var
ts := time_to_udint(get_time()); // Текущее значение системного таймера в мс
if ts - tsOLD >= 1000 then // ПР может проскочить 1000 мс период
F := (in - inOLD) / udint_to_real(ts - tsOLD); // Текущая разница за реальный период
tsOLD := ts; inOLD := in; // Фиксируем как предыдущие значения
end_if
end_function_block
Чтобы не скакало использовал фильтр + сглаживание (https://owen.ru/forum/showthread.php?t=41726&p=469389&viewfull=1#post469389)
if ts - tsOLD >= 1000 then // ПР может проскочить 1000 мс период
Чет не пойму, это условие же никогда не выполнится. Значение tsOLD присваивается в теле IF и до этого равно нулю...
kondor3000
06.08.2025, 09:39
Чет не пойму, это условие же никогда не выполнится. Значение tsOLD присваивается в теле IF и до этого равно нулю...
Выполнится, для кого сделали Отладку ФБ, в том числе пошаговую ? 85203
Выполнится, для кого сделали Отладку ФБ, в том числе пошаговую ? 85203
Ух тыыы !!! А я и не знал )))
Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!
Ваша идея имеет право на жизнь )) Ведь у меня есть один свободный быстрый вход ) Я сразу не сообразил что Вы про запаралелить входа
Только откуда информация что счетчик считает и восходящие и спадающие фронта ?
Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!
Всегда думал, что счетчик считает по фронту канала В, при этом, если А высокий, то значение прибавляется, если А низкий - вычитается
Сергей0308
06.08.2025, 15:49
Всегда думал, что счетчик считает по фронту канала В, при этом, если А высокий, то значение прибавляется, если А низкий - вычитается
Сигналы А и В представляют собой меандр и сдвинуты на 90 градусов относительно друг друга(для определения направления вращения), счёт осуществляется по фронту и спаду каждого импульса для обеспечения более точного позиционирования, в 4 раза(что существенно), короче, было бы просто обидно иметь точность в 4 раза меньшую из-за незнания, это как строить акведук зная закон сообщающихся сосудов!
Сигналы А и В представляют собой меандр и сдвинуты на 90 градусов относительно друг друга(для определения направления вращения), счёт осуществляется по фронту и спаду каждого импульса для обеспечения более точного позиционирования, в 4 раза(что существенно), короче, было бы просто обидно иметь точность в 4 раза меньшую из-за незнания, это как строить акведук зная закон сообщающихся сосудов!
Я не нашел информации, что ПРка именно так считает импульсы от энкодера.
Сергей0308
06.08.2025, 17:58
Я не нашел информации, что ПРка именно так считает импульсы от энкодера.
Так было задумано, чтобы использовать возможности энкодера по полной!
Я конечно понимаю, что на самолёте можно и по дороге ехать, но задумка была другая!
Можно проверить на практике если есть ПР с быстрыми входами, для обычных входов я здесь выкладывал макрос работы с энкодером:
https://owen.ru/forum/showthread.php?t=39392&p=434001&viewfull=1#post434001
https://owen.ru/forum/showthread.php?t=9398&p=385600&viewfull=1#post385600
https://owen.ru/forum/showthread.php?t=25067&p=404346&viewfull=1#post404346
И, довольно давно, не менее года назад, в одной из тем форума один товарищ жаловался на то, что счётчик энкодера считает в 4 раза больше импульсов, чем он ожидал!
Так было задумано, чтобы использовать возможности энкодера по полной!
Я конечно понимаю, что на самолёте можно и по дороге ехать, но задумка была другая!
Можно проверить на практике если есть ПР с быстрыми входами, для обычных входов я здесь выкладывал макрос работы с энкодером:
https://owen.ru/forum/showthread.php?t=39392&p=434001&viewfull=1#post434001
https://owen.ru/forum/showthread.php?t=9398&p=385600&viewfull=1#post385600
https://owen.ru/forum/showthread.php?t=25067&p=404346&viewfull=1#post404346
И, довольно давно, не менее года назад, в одной из тем форума один товарищ жаловался на то, что счётчик энкодера считает в 4 раза больше импульсов, чем он ожидал!
У меня, в режиме энкодера , считает ровно столько сколько указано на энкодере. Получается только один фронт на одном канале. В режиме счетчика завтра проверю.
Сергей0308
08.08.2025, 12:19
У меня, в режиме энкодера , считает ровно столько сколько указано на энкодере. Получается только один фронт на одном канале. В режиме счетчика завтра проверю.
И, о чём это говорит?
Короче, если Вы возьмёте нормальный прибор для работы с энкодером, то точность позиционирования вырастет в 4 раза, у Вас частота и длительность сигналов позволяет работать и с обычными(не быстрыми) входами, ссылку на макрос работы с энкодером я постом выше давал!
Видимо Овен неисправим, в смысле, всегда стремится всё сделать через заднее место по принципу "и так сойдёт", наверно он мультик одноимённый не смотрел про зайчика и к каким печальным результатам это может привести!
https://www.youtube.com/watch?v=D3tr1lQIoOk
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot