Делаю себе контроллер BLDC на Arduino )

[on4ip]

Максимально допустимая частота зависит конечно от контроллера=) но в первую очередь она зависит от частоты ШИМ и как следствие частоты расчета( которая как правило на частоте ШИМ или на 2х от шим)
Контроллер FOC  с 72мГц стм32 cortex m4 справляется с 15кгц расчета легко. что дает около 90000 Eprm для мотора.

[kor]

Есть много способов формировать синус. Я использую чисто табличный, как здесь
ссылка

Тоже применял его (только на проце платы гироскутера stm32f103RBT6 ), работает.
https://electrotransport.ru/index.php?topic=63145.msg2000547#msg2000547  сообщение 15
Есть правда (как мне кажется) недостаток в программе, в ней период "шагания" по таблице синусов рассчитывается непосредственно из текущего измеренного времени между прерываниями от смены кода от холлолв, и если в сигнале от холлов появляется дребезг то "шагание" по таблице синусов сбивается.  Автор борется с этим вводя между холлами и процессором дополнительную схему с триггерами Шмидта с большим гистерезисом.  Но может кто-то из форумчан знает и подскажет, как побороть этот дребезг программно? (может некую программную ФАПЧ сделать, чтобы период "шагания по таблице" не мог резко меняться, или еще каким способом?) 

[Pastor_Frost]

Тоже применял его (только на проце платы гироскутера stm32f103RBT6 ), работает.
https://electrotransport.ru/index.php?topic=63145.msg2000547#msg2000547  сообщение 15
Есть правда (как мне кажется) недостаток в программе, в ней период "шагания" по таблице синусов рассчитывается непосредственно из текущего измеренного времени между прерываниями от смены кода от холлолв, и если в сигнале от холлов появляется дребезг то "шагание" по таблице синусов сбивается.  Автор борется с этим вводя между холлами и процессором дополнительную схему с триггерами Шмидта с большим гистерезисом.  Но может кто-то из форумчан знает и подскажет, как побороть этот дребезг программно? (может некую программную ФАПЧ сделать, чтобы период "шагания по таблице" не мог резко меняться, или еще каким способом?)

Я последовал примеру Avislab и применил триггеры Шмидта. Там в коде обработчика прерываний от датчиков Холла есть и программная защита, но какая-то она не доработанная и без аппаратной фильтрации работает плохо.
Там в Вашей теме я прочитал про ошибки в таблице синуса... У меня тоже была интересная ситуация: было у меня мотор-колесо прямое переднее 48В 600Вт Volta, покупал в 2015 г., я на нем отрабатывал контроллер по началу, так для нормальной работы колеса я ставил опережение на 15 градусов (электрических) и ток холостого хода был меньше 1 Ампера (не помню точно скоко был). Потом  я приобрел в 2021 г. такое же мотор колесо, только заднее. От обычного блочного китайского контроллера оно крутится не захотело ни при каких комбинациях холлов и фаз. Подключил я его к самодельному контроллеру, у avislab есть процедура автоопределения датчиков (хреновенькая правда, я ее дорабатывал), в общем определил все, но колесо крутилось очень хреново. Но когда выставил опережение -45 градусов, то все закрутилось четко и ровно. Когда я посчитал разницу 15-(-45)=60 градусов, то у меня сложилось впечатление, что датчики Холла все 3 штуки стояли обратной стороной. Но я не проверял эту гипотезу, так и езжу. С помощью переменной PMSM_timing все "подкручивается" в нужную сторону и даже таблицу править не надо.
Сейчас пробую управлять двигателем типа FlipSky 6384, там датчики стоят под 60 градусов, так тоже удобно, подправил код немного и все работает и не нужно искать покупать спец контроллер, который работает датчиками под 60 градусов.

[TRO]

Но может кто-то из форумчан знает и подскажет, как побороть этот дребезг программно?

Дребезг одного из холлов обычно происходит рядом с моментом переключения одного из холлов (т.е. одномоментно дребезжит только один холл), потому что в это время магнитное поле от постоянного магнита слабое, и холл ловит поле от мощных катушек. Выглядит это как реверс на один такт коммутации с возвратом вперед, и так многократно на частоте ШИМ. Для фильтрации этого достаточно не реагировать на этот реверс в пределах одного шага, особенно если частота (обороты) такая, что никакого реверса там быть не может. Реализуется довольно просто программно. Но засада в том, что происходит это на частоте ШИМ (на большой частоте), что скорее всего предельно нагрузит прерывания (если обработка холлов идет по прерываниям), т.е. у процессора в это время может ни на что не оставаться времени. Несмотря на то, что расчет по фильтрации дребезга в прерывании занимает не много времени, очень много времени занимает вход и выход из прерываний (сохранение и доставание регистров из стека и прочее, особенно если это отдать на откуп компилятору). У меня на меге328 получалось это делать на частоте до 50кГц (при этом на остальной код времени уже почти не оставалось, т.е. эпик фейл наступает еще раньше, когда с повышением ERPM  процу уже не хватает оставшегося от прерываний времени читать и считать синусы из таблицы). Всё это требует отладки с замеров времен работы прерываний (от прихода до завершения выхода), и замера времени нужного на расчет одного шага, их сумма и будет критический период частоты (одной шестой ERPM).

В принципе, если частота коммутации по холлам гораздо ниже чем ШИМ, то правильноподобранных RC цепочек может быть достаточно, что бы полезный сигнал с холлов проходил (был амплитудно выше входного гистерезиса контроллера), а дребез с частотой ШИМ ослаблялся RC цепочкой до амплитуды меньшей входного гистерезиса контроллера. Это работает, но не сильно надежно (лучше комбинировать с програмным методом).

[Pastor_Frost]

Соглашусь с TRO, комбинирование программных и аппаратных защит решает проблему в большинстве случаев...
...но не во всех случаях. Один мой товарищ купил себе двигатель типа Denzel 4500 (или какую-то копию его) и контроллер Kelly KLS7213 (синусный). Как тут описано в соответствующей теме по этому двигателю эта парочка вместе не работает как раз по причине этих самых ложных срабатываний датчиков при смене полярности пролетающих мимо них мощных магнитов. Я по наивности своей выпросил этот двигатель для испытаний со своим контроллером, думаю ну у меня то уж точно заработает хоть на холостом ходу. Ничего не заработало)) как я не крутил эти защиты и фильтра, как не настраивал тайминги, все равно идут сбои синхронизации. В режиме блочной коммутации все работало ровно, но там все намного проще. В общем до серьезной разработки мне еще очень далеко))

[edw123]

Вы смотрели осциллограмму эдс фаза-фаза этого мотора при вращении вала чем нибудь извне (дрелью например)? У него вроде-как эта эдс несинусоидальная, а значит синус ему противопоказан. Есть осциллограф?

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

[Pastor_Frost]

Вы смотрели осциллограмму эдс фаза-фаза этого мотора при вращении вала чем нибудь извне (дрелью например)? У него вроде-как эта эдс несинусоидальная, а значит синус ему противопоказан. Есть осциллограф?

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

[Sonar]

Хорошую тему затронули, однако, на счет ложных срабатываний холлов. Я пока тоже ищу легковесное решение для своего контроллера мотор-колеса на базе ATmega328p. У китайцев, в синусных контроллерах, заметил интересную вещь: они не жестко (резко) синхронизируют фазу сигнала на выходе по сигналам от датчиков холла, а плавно подстраивают расчетное значение (ориентируется на скорость) под реальное, как я понял. Это помогает избавиться от кратковременных сбоев синхронизации и стабилизирует скорость вращения двигателя. А то уже давно обратил внимание, что двигатели собраны не идеально ровно и от того присутствует девиация скорости вращения четко на каждый механический оборот. Китайские контроллеры эту девиацию сглаживают почти до нуля.

[kor]

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

Может такой вариант:  после прихода прерывания от Холла, в обработчике прерывания добавить команду Запрета прерываний от Холлов и установить флаг про этот запрет.
  Обратно Разрешение прерываний от холлов делать после расчетной задержки, зависящей (прямопропорционально) от текущего периода шага (шаг=время между сменой кода холлов).
Таким образом "время нереагирования" на "дребезг" будет "подстраиваться" под текущий период шага (например 15...30% от периода шага).
  Поскольку быстро измерять период шага проблематично (из-за того-же дребезга Холлов) то, приняв допущение, что обороты мотора
прямопропорциональны текущей Кv мотора (константа), текущему Напряжению батареи(тоже можно принять константой) и текущему заполнению ШИМ,  можно считать что период шага = 1/текущее заполнение ШИМ.
Тогда расчетное время задержки(считаем без плавучки) = коэфф пропорциональности(константа,расчитать один раз) / текущее заполнение шим. Его (расчетное время задержки) можно расчитывать в главной программе при обнаружении флага запрета. Например значение расчетного времени задержки будет получаться в районе 3(макс зап шим 100%)...60(мин зап шим 10%),
отсчитываем такое количество периодов ШИМ и снова разрешаем прерывания от холлов.

[edw123]

  Может такой вариант:  после прихода прерывания от Холла

А если это первое - ложное?

[kor]

А если это первое - ложное?,

Как пишет TRO: Дребезг одного из холлов обычно происходит рядом с моментом переключения одного из холлов (т.е. одномоментно дребезжит только один холл).
Тоесть звенеть начинает тот холл который и так должен был уже переключиться, просто  ему бы после этого "замереть", а он делает после себя "хвост из дребезга". Вот и отсекаем этот Хвост.

[edw123]

Как пишет TRO: Дребезг одного из холлов обычно происходит рядом с моментом переключения одного из холлов (т.е. одномоментно дребезжит только один холл).
Тоесть звенеть начинает тот холл который и так должен был уже переключиться, просто  ему бы после этого "замереть", а он делает после себя "хвост из дребезга". Вот и отсекаем этот Хвост.

Классический дребезг - это нос и хвост. Оба надо отсекать, как ни жалко зверушку.

[kor]

Классический дребезг - это нос и хвост. Оба надо отсекать, как ни жалко зверушку.

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

[edw123]

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

Хвостов нет если есть софтовый гаситель, это не сложно, а вот поймать без носа - сложнее.

[on4ip]

Можно вообще не использовать прерывание по холлам.

[kor]

Можно вообще не использовать прерывание по холлам.

Вероятно это вариант, когда Холлы просто опрашиваются регулярно один раз за период шим (обычно 64мкс),? Но тогда возникает "дрожание" определения момента смены кода холлов которое может достигать +- 64мкс. При оборотах с частотой перемагничивания 200Гц длительность между сменой кода холлов получается 830мкс, для 300Гц 550мкс. То-есть точность 7...11%,  не слишком ли грубо? На сколько это ухудшит кпд мотора по сравнению с "точным" переключением по прерыванию.?
  И в этом случае, гораздо реже, но так-же возможно словить "дребезг".
 

[Frolikum]

[user]kor[/user], Если уже используется программный опрос то ничего не мешает самим определить период опроса. Если камень stm32  и шим центральносимметрированый(другой как бы и не сильно подходит) то включаете прерывания на вершине счета и на переходе через ноль и вот вам удвоенная частота опроса. Если мало то есть у первого таймера или ему подобных 4ый канал который тоже можно использовать для этого записав в него половину от вершины счета и тогда можно получить ещё две точки опроса. В общем если есть желание опрашивать их программно то можно придумать 100500 способов это делать с желаемой периодичностью. Можно и просто отдельный таймер завести и генерировать прерывания для опроса.

А если честно то кажется что большую проблему в дрожании определяет сам мотор) ибо я ещё не видел ни одного мотора в котором бы холлы физически были расположены так точно что при равномерном вращении их они давали бы строго правильную картинку. Зачастую холлы в моторе уже изначально стоят не сильно точно и применяются системы которые помимо холлов используют энкодер имеющий большее разрешение и служит некоей корректирующей основой для первых.

[edw123]

  И в этом случае, гораздо реже, но так-же возможно словить "дребезг".

Почему реже? При попадании на середину импульса? Вообще дребезг надо бы аппаратно устранять, без затрат счёта.