Цифровой фильтр для коррекции неравномерности импульсов Step

[michael-yurov]

Когда убрал библиотечные функции при чтении состояния пина «Dir», получилось, что при 5-кратном умножении максимальная входная частота уже не 25 а 45 кГц!!!
а выходные частоты, соответственно - в 5 раз выше, т.е. в сумме - 225 кГц.
Вот вам и стандартные библиотеки STM32!

C такими частотами уже можно жить.

Или, например, при умножении в 10 раз, получаем максимальную входную частоту 27 кГц (еще запас более 10% остается), т.е. не менее 9 кГц на канал (в случае с тремя каналами),
и, получается - 90 кГц на выходе (это даже больше, чем у контроллеров от Purelogic PLCM, хоть они и пишут, что у них 100 кГц).
Но у меня интервал импульсов очень точно рассчитан, а у них выбрасываются "лишние" импульсы из несущей частоты.
Так что я бы предпочел свой фильтр
При чем при частоте 9 кГц на каждую ось и максимальной скорости станка 6000 мм/мин получается точность позиционирования 0,01 мм, чего более чем достаточно для "бытовых" нужд.

Переход на более мощный процессор позволит поднять частоты еще раз в 5.

[aftaev]

уже загорается лампочка перегрузки (90% загрузки процессора или более),

а как СТМ32 узнает об этом?

[michael-yurov]

уже загорается лампочка перегрузки (90% загрузки процессора или более),

а как СТМ32 узнает об этом?

У меня все события в программе происходят при возникновении прерываний,
а тело основного цикла - пустое.
Я туда засунул счетчик, который постоянно увеличивает переменную,
А в процедуре сервоцикла, которая возникает ровно через 0,25 мс я проверяю, сколько там этот счетчик основного цикла насчитал.
Если менее 10% от обычной величины для не загруженного состояния - значит все процессорное время занято обработкой прерываний, и счетчику некогда было считать.
Значит процессор сильно загружен и можно включить лампочку.

Только вот боюсь, что из за этого может пострадать быстродействие, т.к. потребуется больше времени, чтобы сохранить состояние процессора для перехода в процедуру прерывания.
Но и лампочка нужна, чтобы быть уверенным в корректной работе фильтра.

[aftaev]

думал мож у СТМ32 есть така готовая фишка

[Serg]

Вот вам и стандартные библиотеки STM32!

А ещё можно всё на ассемблере переписать. Но, как я уже говорил, лично моё время дороже более мощного камня.

[Impartial]

Насколько я понял принцип работы это проще сделать аппаратно на таймерах.
Я бы сделал так:
Берем три таймера, допустим 1,2,3.
Третьим измеряем период степ, усредняем.
Второй настраиваем в режим компаре и генерируем усредненный период.
А первым генерируем длительность выходного степ.
Таким образом сбрасывает нагрузку с процессора.

[michael-yurov]

Насколько я понял принцип работы это проще сделать аппаратно на таймерах.
Я бы сделал так:
Берем три таймера, допустим 1,2,3.
Третьим измеряем период степ, усредняем.
Второй настраиваем в режим компаре и генерируем усредненный период.
А первым генерируем длительность выходного степ.
Таким образом сбрасывает нагрузку с процессора.

Далеко не все понял, но, чувствую, что схема сложная получается, и таймеров много очень нужно.
А еще учти, что нужно учитывать сигнал Dir - а это очень большая часть нагрузки, т.к. его нужно проверять и для поступающего сигнала, и учитывать для исходящего (Если импульсы генерируются таймером, то нужно не проворонить лишнего).

Повесить изменение состояния Dir на прерывание не получилось, т.к. они были заняты сигналами Step, а использовать общие прерывания получалось не выгодно.

Если генерируемые таймером импульсы считать другим таймером, то нагрузка, конечно, уменьшится, но я побоялся запутаться с моментом смены направления. Побоялся шагнуть не с тем состоянием выхода Dir.
Переключать Dir можно только между импульсами и всегда при одинаковом уровне (высоком или низком), иначе потеряем шаги.
А это значит, что необходимо вызывать прерывание при обновлении таймера, а значит, что экономии уже не получается.
А еще Частоту таймеров, предделитель и скважность можно менять только между импульсами, иначе будут сбои из за неправильного предделителя, счетчика и т.п.

[Impartial]

Дир обрабатывать прерываниями EXTI. Должно получиться просто.
А переключения всегда будут там где нужно если включена буферизация в таймере. В этом случае новое значение запишется не в момент обращения проца,
а по окончанию текущего интервала. А момент смены выходного дир точно можно задать таймером(1) генерации длительности сигнала степ.

[michael-yurov]

Дир обрабатывать прерываниями EXTI. Должно получиться просто.

Если бы у меня остались свободные ноги и прерывания - я бы так и сделал бы, но экономия незначительна. Разве что если подсчитывать входящие импульсы таймером (которых и так мало, особенно тех, которые умеют считать в 2 стороны). Получается сложно.
Сама по себе задача очень простая, но когда есть много ограничений по использованию ног, таймеров и прерываний - становится проще повесить входящий Step на прерывания, там считать импульсы и там же проверять направление Dir.

А переключения всегда будут там где нужно если включена буферизация в таймере. В этом случае новое значение запишется не в момент обращения проца,
а по окончанию текущего интервала.

А вот я не смог с этим справиться (мне нужно было и предделитель обновлять, и предел счетчика и заполнение ШИМ). А еще, если частота была околонулевой и стала резко увеличиваться, то нельзя ждать, пока закончится текущий импульс.

А момент смены выходного дир точно можно задать таймером(1) генерации длительности сигнала степ.

Это не понял. Т.е. еще один таймер использовать? Или все же использовать прерывание таймера генерирующего Step? В чем же тогда хитрость?

[Impartial]

Если бы у меня остались свободные ноги и прерывания - я бы так и сделал бы,

Но ведь дир заведены на какие то ноги. От каждой ноги можно получить прерывание.

Разве что если подсчитывать входящие импульсы таймером (которых и так мало, особенно тех, которые умеют считать в 2 стороны).

Не совсем понятно зачем подсчитывать входящие импульсы, нужно измерять их период, на мой взгляд.

Или все же использовать прерывание таймера генерирующего Step?

Нет, не период степ, а длительность степ. Последний в цепочке таймер.

[michael-yurov]

Убрал все библиотечные функции в ресурсоемких местах.
Получилось, что при 10 кратном умножении частоты успевает отрабатывать 43,5 кГц (3 x 14,5 кГц в случае одновременного движения 3х осей) входного сигнала и, соответственно - 3 x 145 кГц на выходе.
Это уже очень даже хорошо! На большее способны далеко не все драйверы.

[michael-yurov]

Но ведь дир заведены на какие то ноги. От каждой ноги можно получить прерывание.

Можно, но тогда не получится все прерывания удачно распределить. Придется в процедуре обработчика проверять - какая именно нога вызвала прерывание. А я этого не делаю в обработчиков входящего сигнала Step ради экономии ресурсов.

Не совсем понятно зачем подсчитывать входящие импульсы, нужно измерять их период, на мой взгляд.

Ну, как же... конечно нужно, чтобы отслеживать текущую позицию (пусть и относительную). Если не считать каждый импульс - я собьюсь с координат.
Т.е. самое важное это не допустить расхождения входящих и исходящих координат.
А период у них может скакать, как обкуренный кенгуру, так что эта информация несет мало пользы.

Нет, не период степ, а длительность степ. Последний в цепочке таймер.

Тут я уже не понимаю. Совсем запутался.


Давай я задам небольшой, вполне конкретный вопрос, и если на него есть ответ, то стоит рассуждать дальше.
Домустим, мы для таймера, генерирующего сигнал Step задали новую частоту и новый предделитель (как-то там хитро расчитали, и сделали почти 32-битный таймер), и при следующем обновлении счетчика таймер установит новые значения.
Так вот вопрос - как оставить неизменной скважность генерируемого сигнала после обновления счетчика, не используя прерывание обновления?

[Impartial]

Не совсем понял. Это для сохранения длительности степ? Если да, то пересчитать нужно, если один таймер.
Я предлагаю использовать для этого еще один таймер который по окончанию периода степ генерирует сам импульс степ.

[michael-yurov]

Я предлагаю использовать для этого еще один таймер который по окончанию периода степ генерирует сам степ.

ааа... тогда - да, тогда есть теоретическая возможность.
У меня проблема была в том, что 16 битного счетчика явно мало, поэтому приходилось менять и "емкость" счетчика таймера, и предделитель таймера одновременно, предварительно рассчитав их,
но т.к. регистр сравнения привязан "емкости" (ARR) таймера, получалось так, что я вынужден менять скважность одновременно с предделителем и "емкостью".

Я думал о том, чтобы после первого таймера повесить второй, генерирующий сами импульсы... но таймеров маловато оказалось (изначально я хотел сделать 6 осей, но разводку односторонней платы здесь закритиковали, и я сделал 4 оси).

Получается, что нужно на каждую ось как минимум 3 таймера на выход (таймер, генерирующий необходимую частоту Step, таймер генерирующий сам импульс, и таймер подсчитывающий исходящие импульсы), и хотя бы один таймер на вход (считать входящие импульсы).
А еще как-то нужно будет считать входящие и исходящие импульсы так, чтобы не произошло переполнения таймера... Я не знаю, можно ли такое сделать.

Короче... проще чип купить не за 50 руб, а за 150.
Все равно всякие разъемы, переключатели и т.п. стоят намного намного дороже.

[Impartial]

Получается, что нужно на каждую ось как минимум 3 таймера на выход (таймер, генерирующий необходимую частоту Step, таймер генерирующий сам импульс, и таймер подсчитывающий исходящие импульсы), и хотя бы один таймер на вход (считать входящие импульсы).

На четыре оси. В каждом таймере по четыре компаре регистра.
А насчет разрядности, то по моему хватает с головой. Нужно просто учесть, что любая управляющая система (мач или емс) работает по сервоциклам.
Просто нужно вычислить период его.

[michael-yurov]

На четыре оси. В каждом таймере по четыре компаре регистра.

Ну, во первых -далеко не во всех,
во вторых - четыре счетных регистра, но это не значит, что и предделителя четыре, и направления счета четыре.

А насчет разрядности, то по моему хватает с головой.

Ну, как же хватит с головой? Если взять максимальную частоту таймера, например, 500 кГц,.. то ближайшая меньшая возможная частота будет уже 250 кГц, а следующая - 125 кГц, и т.п.
Хреновая получится стабильность работы фильтра.
Значит нужно брать максимальную частоту таймера не менее пары десятков мегагерц, тогда минимальная частота при 16-битном делителе получается 366 Гц - многовато, я бы сказал.
Меня эта цифра не устроила. Хотя, наверное, напрасно. Можно было бы сделать прошивку намного проще (но не более быстродействующую).

Я учел, что у Mach3 сервоцикл 2 мс, а у LinuxCNC - 1 мс.
У меня сервоцикл 0,25 мс, так что фильтр точно ничего не напортит.

[michael-yurov]

aftaev тут очень просил снять видео, того, как я фрезерую. Не верит, наверное...
Вот, снял... очень длинное видео.
https://www.youtube.com/watch?v=nAbJh2mEFDM
И пара фотографий еще:

Читал много советов, что отверстия нужно делать в начале, гравером по контуру лучше в конце... и всякое такое.
Блин, в какой последовательности ни резал - никакой разницы не вижу!

[vovafed]

Вот, снял... очень длинное видео

не открывается чтото

[nik1]

Высший пЕлотаж
Михаил, а рисунок на платке чисто для визуализации процесса или для другого?

[michael-yurov]

Это я V образным гравером уже прошелся по контуру и в узких местах. Не снимал, т.к. гравер еще медленнее ползает - там еще на пол часа такой же картинки.