ПР103. Измерение скорости энкодером.

[B.S.V]

Я так понимаю, Вы лёгких путей не ищете, в смысле, время цикла программы можно посмотреть в сервисном меню ПР200, а ещё проще в ОЛ, после заливки программы(проекта) в ПР.

ПР103 ). А про ОЛ не подумал

[B.S.V]

Ну вот если главная задача (?) отмерить заданное расстояние, то каждый импульс это 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 см/мин. мм/мин я отбрасываю.

[Dimensy]

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]

Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!

[B.S.V]

Не понял, зачем считать импульсы, если энкодер и так их считает?
Берите разность за определенный период времени и обсчитывайте по пропорции

В первом варианте так и делал. Потом решил попробовать привязаться к началу фронта... нечего не поменялось. Но причина понятна. Я теряю "полуимпульсы" которые накапливаются при пересчете в минуты. Если считать за минуту - точность должна быть приемлемой. Но минута на ожидание реальной скорости - не приемлемо ))

[B.S.V]

Мне кажется, быстрый вход(ы) лучше сконфигурировать в режим счётчика импульсов, а не АВ энкодера, в смысле, использовать для этой функции оставшиеся(неиспользованные) быстрые входы тогда будет в 4 раза меньше импульсов, счётчик энкодера считает по фронту и спаду каждого из двух каналов, тогда и период следования импульсов(что нам важно) будет в 4 раза больше, соответственно и точность возрастёт!

В момент реза происходит откат на пару мм. Счет энкодером компенсирует, а счетчик их приплюсует как я понимаю.

[B.S.V]

Завтра попробую через период посчитать. Нашел ошибку в алгоритме.
Такой вопрос : если к примеру разделить 1 секунду на 625 мс получится 1 мс или 1.6 мс ?

[Сергей0308]

Завтра попробую через период посчитать. Нашел ошибку в алгоритме.
Такой вопрос : если к примеру разделить 1 секунду на 625 мс получится 1 мс или 1.6 мс ?

1 секунда это 1000 мс, если разделить на 625 мс, получится просто "1,6", в смысле, "мс" сократятся!

[B.S.V]

1 секунда это 1000 мс, если разделить на 625 мс, получится просто "1,6", в смысле, "мс" сократятся!

То есть, произойдет преобразование типов из TIME в REAL ?
Проверил - преобразования не происходит )

[EFrol]

Самый точный, но тоже скачущий спидометр у меня получился так:
Owen.jpg

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

Чтобы не скакало использовал фильтр + сглаживание