Hardella IDE

[Владимир Ситников]

Возвращаюсь к теме энкодеров на Hardella. Написанные мною модули успешно работают в железе. Однако есть небольшой недостаток - при выключении теряются показания (счетчики) энкодера, что естественно по причине того, что память PRU не энергонезависимая. Ломаю голову на тему сохранения показаний. Вопрос не приоритетный, но хочется что бы всё было по фен-шую.
В прошлых реализациях на ПЛК старой версии (без PRU) просто засовывал переменную показаний в ретайн, и этого было достаточно. Хотелось бы сделать нечто подобное и на новой версии ПЛК.

Можно сделать следующим образом:
1) У PRU переменной/FB блока ставим retain
2) При этом на КДС стороне будет создана отдельная программа (напр PRU0_RETAINS) с retain переменными
3) При "pru_memory_read" будут обновляться переменные в PRU0_RETAINS)
4) В момент PRU0Init брать значения из PRU0_RETAINS и с помощью них инициализровать PRU.

[Newcomer]

Проверили на железе этот вариант:

accel_ramp = 51492.89 + 7560.61*q - 65000*EXP(-(q-16)/100.0);
decel_ramp = accel_ramp*32

При числе импульсов 16...25 удается уложиться в промежуток от 15 до 16 мс. При 26 импульсах и более не получается уложиться в промежуток от 15 до 16 мс. Чем большее количество импульсов генерируется тем хуже результат.

Если считать accel_ramp = (2 * q)/(0,016 * 0,016); (классическая формула), а decel_ramp = 500000000;, то в для 16 <= q <= 160 все нормально. При q > 160 генерация пачки импульсов перестает укладываться в промежуток от 15 до 16 мс.

Возможно, ваша формула для accel_ramp более точна (она дает большее значение чем классическая формула) и надо просто увеличить decel_ramp.

Попробуем на железе так:

accel_ramp = 51492.89 + 7560.61*q - 65000*EXP(-(q-16)/100.0);
decel_ramp = 500000000;

[Владимир Ситников]

При 26 импульсах и более не получается уложиться в промежуток от 15 до 16 мс.

От какого момента отсчитываете 15-16мс?
В него входит время ПЛК цикла?
Есть возможность измерить длительность, которая фактически получается?
Фактическое время работы стабильно или меняется от раза к разу?

Возможно, ваша формула для accel_ramp более точна (она дает большее значение чем классическая формула) и надо просто увеличить decel_ramp.

На всякий случай: я формулу подбирал не исходя из законов физики, а исходя из фактической длительности генерации импульсов на эмуляторе. Т.е. формула подобрана именно для случая decel_ramp=accel_ramp*32 и неизвестно как она себя поведёт при других значениях decel_ramp. Попробовать-то можно, но я без понятия.

[Newcomer]

В цикле ПЛК делается проверка:

IF SteppersConfig_Pru1MemoryTransfer.STEPPER1_PRU1_st epper_state = STOP_STEPPER_RUN_STATE THEN
SteppersConfig_Pru1MemoryTransfer.STEPPER1_PRU1_st epper_enable := FALSE; END_IF

У меня цикл ПЛК = 1 мс. Крайнее значение временного интервала - 16,7 мс. Возможно, промежуток, в котором должна кончаться генерация пачки импульсов, надо задавать 14 - 15 мс. Тогда цикл ПЛК гарантированно не будет вносить погрешность.

[Владимир Ситников]

У меня цикл ПЛК = 1 мс. Крайнее значение временного интервала - 16,7 мс. Возможно, промежуток, в котором должна кончаться генерация пачки импульсов, надо задавать 14 - 15 мс. Тогда цикл ПЛК гарантированно не будет вносить погрешность.

Да, похоже на цикл ПЛК.

А что является критерием запуска генерации? Внешний импульс? Если так, то, может, его в PRU ловить, и тогда не будет зависимости от цикла ПЛК.

[Newcomer]

Да, похоже на цикл ПЛК.

А что является критерием запуска генерации? Внешний импульс? Если так, то, может, его в PRU ловить, и тогда не будет зависимости от цикла ПЛК.

Очередная генерация должна начинаться по истечению 16,7 мс. Если генерация пачки импульсов не укладывается в это время, то происходит смещение по времени начала генерации следующей пачки импульсов. Всего может быть до 15 000 пачек импульсов. Представляете какая ошибка по времени может накопиться ?

В программе ПЛК предусмотрена автокоррекция, которая позволяет на каждом шаге компенсировать временную погрешность в пределах +/- 1 мс. Если погрешность на каждом шаге больше 1 мс, то ее компенсировать нельзя. Эта погрешность накапливается и на 15 000 шагах может быть очень большой, что неприемлемо. Максимальная временная погрешность на 15 000 шагах должна быть не более 15 мс.

[Владимир Ситников]

Очередная генерация должна начинаться по истечению 16,7 мс. Если генерация пачки импульсов не укладывается в это время, то происходит смещение по времени начала генерации следующей пачки импульсов. Всего может быть до 15 000 пачек импульсов. Представляете какая ошибка по времени может накопиться ?

В программе ПЛК предусмотрена автокоррекция, которая позволяет на каждом шаге компенсировать временную погрешность в пределах +/- 1 мс. Если погрешность на каждом шаге больше 1 мс, то ее компенсировать нельзя. Эта погрешность накапливается и на 15 000 шагах может быть очень большой, что неприемлемо. Максимальная временная погрешность на 15 000 шагах должна быть не более 15 мс.

Вообще говоря, в PRU программе можно работать со временем (см pru_current_time), и точность должна быть довольно хорошей. Во всяком случае, должно быть точнее, чем цикл ПЛК.

[Newcomer]

Вообще говоря, в PRU программе можно работать со временем (см pru_current_time), и точность должна быть довольно хорошей. Во всяком случае, должно быть точнее, чем цикл ПЛК.

Погрешность, связанная с циклом ПЛК равном 1 мс, не страшна, т.к. есть автокоррекция +/- 1 мс. Страшна погрешность возникающая из-за того, что генерация пачки импульсов на каждом шаге не укладывается в заданное время.

[Владимир Ситников]

Погрешность, связанная с циклом ПЛК равном 1 мс, не страшна, т.к. есть автокоррекция +/- 1 мс. Страшна погрешность возникающая из-за того, что генерация пачки импульсов на каждом шаге не укладывается в заданное время.

Во-первых, есть гарантия, что цикл ПЛК всегда укладывается в 1мс?
Во-вторых, при некоторых значениях, генерация весьма плотно подходит к 16мс. Если там что-то добавляет ПЛК (т.е. обнаруживает завершение предыдущей генерации с задержкой на цикл ПЛК), то запросто может не уложиться в 16мс.

Т.е. тут либо переносить всю пачку в PRU -- там не будет проблем с временной синхронизацией. Можно до 5-10наносекунд точность выдерживать.

Либо оставлять синхронизацию в ПЛК, но тогда нужно, чтобы PRU программа заканчивала генерацию не более чем за 14-15мс, чтобы у ПЛК был шанс обработать и перезапустить.

[Newcomer]

Во-первых, есть гарантия, что цикл ПЛК всегда укладывается в 1мс?

Если на каждом шаге генерируется малое количество импульсов, то все нормально. Проблемы возникают, когда на каждом шаге генерируется большое число импульсов.