roboforum.ru

Если с датчиком - правда, то это пипец, попытался сделать поиск по "error, bug" - ноль.

Angel71 писал(а):зачем нужно кроме скорости вращения знать прям реальный угол, хз.

В блдц это был основной смысл, переключать фазы, а это примерно: 360грд. / (24(полюс)*2(так надо)*10(разрешение в идеале)), пичалька. Хорошо что у меня не хватило времени на эти датчики, хотя я всегда больше доверял хардварным датчикам Холла

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

для того чтобы знать какую фазу синуса подать на pwm драйвер.
работает это так:
АБС угол механический преобразовывается в угол электрический, добавляется сдвиг на pi/2 вычисляются новые токи для трёх фаз.
это нужно чтобы BLDC превратился в полный аналог DC мотора, т.е. в любой момент времени токи точно соответствуют положению ротора так как если бы был механический коллектор.
теоретически можно и так как вы сказали "получить угол и потом переключиться на квадратурный энкодер." но переключение происходит только в первый момент после подачи питания на датчик, т.е. нужно опять сбрасывать датчик по питанию а с этим у меня проблемы.
кроме передёргивания питания больше особо ничего не сделать.
я пока проверяю версию с превышением 600 об/мин.
мне и половины этого должно хватить.

а если раз в секунду данные получать, то вроде и 1200

нее, не так значение абсолютного положения обновляется с частотой 10кГц,
строго говоря мне не нужно реагировать на каждый градус поворота, можно и через 5 градусов считывать, тут главное чтобы данные которые я получаю не сильно отставали от физического поворота, т.к. я всё равно даю токи наперёд относительно текущего положения

я думаю примерно так
алгоритм расчёта абсолютного положения не успевает отработать поворот >2pi т.е для него это как будто поворот в другую сторону относительно предыдущего положения, если так то по идее он должен начать врать что вращение идёт в другую сторону но как только обороты снизятся то он опять должен показывать верные значения, но при этом на выходе по прежнему должны быть значения 0..1023, а этого не происходит, на выходе появляется что то другое.
как это объяснить?

например так: возможно алгоритм впадает в ступор и перегружает себя, при этом т.к. у меня четыре датчика последовательно в режиме "цепного чтения", то в этот момент кто то из других датчиков гонит свои данные по линии PROG от чего тот датчик что перегрузился впадает в непонятный режим, и выйти из него он может только после сброса питания

Если с датчиком - правда, то это пипец, попытался сделать поиск по "error, bug" - ноль.

правда правда
только это может и не баг, а просто особенность включения, в любом случае по ТТХ до 600об./мин он должен выдать, может ли при этом быть несколько таких датчиков в Daisy Chain Mode вопрос, в документации про это ничего, чисто логически - может, остальное проверяется практикой

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

Добавлено спустя 1 минуту 12 секунд:
у микры есть режим "pwm".

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

во первых переключение микры между режимами не мгновенное,
во вторых режим dldc это тупо эмуляция трёх датчиков холла, при этом этот режим работает только для моторов с одной или двумя парами полюсов.
в третьих мы ушли от темы, а именно
1) читаю по SSI режим Daisy Chain Mode , все платы разведены под него
2) этот режим работает нормально, каждые 500мкс я получаю абсолютные положения всех четырёх датчиков, с этим никаких проблем нет
3) суть проблемы в том что после какого то момента один датчик будучи в том же режиме начинает выдавать по SSI в поле data (D9:D0) не то что должен выдавать, и лечится это только сбросом питания у датчика.

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

The AS5040 senses the orientation of the magnetic field and calculates a 10-bit binary code. This code can be accessed via a Synchronous Serial Interface (SSI). In addition, an absolute angular representation is given by a Pulse Width Modulated signal at pin 12 (PWM). Besides the absolute angular position information the device simultaneously provides incremental output signals.

The absolute angular position is sampled at a rate of 10kHz (0.1ms). This allows reading of all 1024 positions per 360 degrees within 0.1 seconds = 9.76Hz (~10Hz) without skipping any position. Multiplying 10Hz by 60, results the corresponding maximum rotational speed of 600 rpm. Readout of every second angular position allows for rotational speeds of up to 1200rpm.

А далее такой опус

Consequently, increasing the rotational speed reduces the number of absolute angular positions per revolution (see Figure 46). Regardless of the rotational speed or the number of positions to be read out, the absolute angular value is always given at the highest resolution of 10 bit.

The incremental outputs are not affected by rotational speed restrictions due to the implemented interpolator. The incremental output signals may be used for high-speed applications with rotational speeds of up to 30,000 rpm without missing pulses.

И далее есть такой раздел

High Speed Operation Sampling Rate The AS5040 samples the angular value at a rate of 10.42k samples per second. Consequently, the incremental, as well as the absolute outputs are updated each 96μs. At a stationary position of the magnet, this sampling rate creates no additional error.

Absolute Mode with Serial Communication
With the given sampling rate of 10.4 kHz, the number of samples (n) per turn for a magnet rotating at high speed can be calculated by:
...
In practice, there is no upper speed limit. The only restriction is that there will be fewer samples per revolution as the speed increases.

In absolute mode with serial communication, 610 rpm is the maximum speed, where 1024 readings per revolution can be obtained.

т.е. теоретически можно считывать все 1024 позиции, без пропусков, вплоть до 10 об/сек (полагаю в режиме SSI 1Mhz)
(если включить режим считывания каждого второго положения? или просто допустимы пропуски? вот это непонятно) то скорость вращения может быть и 20об./сек и более???

ну а главное при чтении по SSI нет никакого другого протокола, на выходе всегда должно быть одно и тоже а именно последнее оцифрованное положение, а у меня , после сбоя, там что то другое появляется, если рукой врещать то на выходе значения 0 .. 104 .. 0 за один оборот,
хз что это, при этом в битах 6-1 никаких ошибок и бит чётности совпадает

Добавлено спустя 24 минуты 3 секунды:
Что интересно, судя по схеме регистр OTP влияет на SSI, но из описания регистра это не видно.
скорее всего имеются ввиду вот эти параметры
CCW:0 = Clockwise operation
Z9 to Z0: 00 = No programmed zero position

всё что связано с разрешением 8-10бит относится к инкрементальному выходу

максимальные и минимальные обороты


Добавлено спустя 22 минуты 57 секунд:
схема


Добавлено спустя 1 час 58 минут 3 секунды:
Разобрался что за режим включается это Alignment Mode

но непонятно как это происходит.
теоретически такого быть не должно, однако я заметил что как только CSn идёт вниз появляется импуль на ноге Prog, судя по всему его генерирует сам датчик, причём этот импульс есть на всех ножках prog
может какая гонка сигналов образовывается, т.к. длина проводов до всех датчиков разная.

мотор не тот, ясно. не мгновенное, но только всё необходимое можно вычислить. достаточно определиться - если не сбоит при некоторых условиях, которые устраивают, так и не забивать себе голову вопросами, почему сбоит. хочется разобраться, так вникать, тестировать, переписывать код или переделывать плату.
а рыть можно начиная с флюса, лужения дорожек, длинны проводов или ловли помех от мотора, проседание питания, что с кондёрами, резисторами и диодами. при параллельном включении тем более электрическую часть нужно перепроверять. с некоторыми микрами при последовательном или параллельном подключении при некоторых частотах заставить нормально работать бываете очень проблемно. alignment mode это небольшая софтовая коррекция положения магнита. для параллельного режима там как раз и написано, что фильтр rc нужен, что бы не вошло в alignment mode. и это кроме других приколов, которые могут приключиться.
посмотрел внимательней даташит, оказывается микра с одной стороны чуть попроще, чем ожидал. с другой всё простенько и логично - машина состояний, сдвиги и т.д. частоты и временные интервалы там описаны. 10кгц+- это внутренняя частота оцифровки. данные абсолютного положения обновляются каждые 100мкс+-. ssi может выдавать максимум с частотой 1мгц. т.е. нет никаких ограничений в 600, 1200,... и будет ли достаточная точность при нужной скорости вращения вполне можно прикинуть.
otp для инкрементального блока, данные в который идут от "абсолютного" блока. "CSn идёт вниз появляется импуль на ноге Prog..." а вот и не факт, что не должно быть - параллельное подключение, вполне реально что они так облегчают работу своей машине состояний. это +- обычная логика сдвига, примерно так в куче всяких чипов делают. может быть 2 вариант - cs сам чип генерирует и что наиболее часто бывает + так удобней, это нужно контроллером cs дёргать. во втором варианте если не соблюдать временные ограничения (особенно минимальную задержку), вполне легко начать записывать или считывать мусорные данные. если cs`ом дёргает мк, тогда смотреть даталоггером + т.к. при параллельном подключении очень вероятен выход за электрические допуски, копать и в эту сторону. иногда помогает просто увеличить немного некоторые интервалы.

попробовал увеличить ёмкости с 1nF до 2nF не помогло

что странно,
-снижение частоты SPI Никак не влияет на баг, сейчас 500кГц
- проблема проявляется именно в момент вращения, данные по SPI всё время с одной и той же частотой , не зависимо вращается мотор или нет.
- ни одной ошибки не возникает, каждое чтение проходит успешно
- войти в режим alignment mode может как один датчик так сразу несколько, максимум 3 (все кроме последнего у которого prog на землю закорочен)

питание у меня так Vbat -> dc-dc 5v -> LDO 3.3v моторы понятное дело напрямую в Vbat

с частотой spi эксперементировать нужно. там логика сдвига с защелками. зависит конечно от реализации, но очень часто сдвиговые регистры вполне спокойно до десятков мегагерц тянут. успевают ли блоки за ними данные переваривать? можно на всякий взять даталоггер, даташит и посмотреть временные диапазоны. если не выдержаны интервалы, может гдет там собакен зарыт. хотя скорей всего по интерфейсу главное выдерживать интервалы опроса. ещё проблемы могут возникать на шине при параллельном или последовательном подключениях - всякие наводки, длина проводов, нагрузочная способность и т.д. в даташит вникать нужно и вникать как чипы работают, но похоже что в alignment mode все в один режим входить должны. в последнем чипе к земле, значит у всех отключен. к vss, значит включен. т.е. внимательно смотреть даташит, как какие пины дёргать нужно, что куда подтягивать и т.д., что бы попытаться заставить все микры работать в нужном режиме.
внешний 3.3в ldo нужен для согласования уровней 3.3в мк и то не факт, что для всех обязательно нужно. в части описания analog readback mode есть упоминание, что при программировании opt может слопать до 130ма. но не сильно вникал, что за программирование - там вроде возможна временная запись (хз куда, в буфер какой или ещё как) и постоянная.

The maximum wire length between the VPROG switching transistor and pin Prog (see Figure 35) should not exceed 50mm (2 inches). To suppress eventual voltage spikes, a 10nF ceramic capacitor should be connected close to pins Prog and VSS. This capacitor is only required for programming, it is not required for normal operation.

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

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

дык нужно тестировать именно daisy chain mode это как минимум два чипа.

в общем пока выяснил следующее
- при падении Csn , выход DO у всех датчиков переходит из состояния Z (tristate) в высокий уровень, т.к. DO через резистор соединён с PROG , на PROG появляется высокий уровень.
но по-идее высокий уровень появляется после того как Csn упадёт, т.е. условие PROG=1 Csn->0 не должно быть выполнено

- DO переходит в состояние Z сразу после того как отправлен последний бит, получается что если последний бит был 1 то конденсатор на PROG остаётся заряженным, и как он должен разрядиться непонятно,вероятно через PROG, вопрос успевает ли, может 1nF как советуют в документации это наоборот много? хотя я вчера пробовал параллельно конденсатору резистор на 1к поставить, это не помогло.

очень хочется завести все ножки PROG через транзистор на землю, и принудительно сажать когда требуется

у вас было предположение, что с определённой скорости начинаются глюки. "я использую абсолютное положение а это всего 600 об/мин. и видимо если превысить то у датчика мозги набекрень съезжают ". уже выяснили, есть связь или нет?
какой prog=1? prog это di, т.е. вход. смысл таймингов в том, что бы при спаде или подъеме успевало накапливать или разряжать. смысла в транзисторах не особо. не, если для эксперементов вы всё, включая и питание чипа обвешать хотите и потом софтово дёргать из тестовой прошивки, как вариант. по даташиту есть фильтр нижних частот на 1,59мгц, можно с номиналами поиграться или сразу укоротить проводочки, флюсик почистить дорожки пролудить и прочее. что там после передачи на конденсаторе, по хорошему значения не должно иметь - это машина состояний, которая запускает процессы только при спаде/подъеме на csn и clk. до каждой передачи на do сначала высокий уровень, затем низкий уровень. а потом при сдвиге данных за Tclk/2 оно должно успевать или зарядиться или разрядиться.
дело конечно ваше, но можно переделать платы, допустим stm32f030 на плату к датчику и стмкой и считывать с датчика и управлять транзисторами.

Angel71, спасибо что помогли искать решение.
заменил конденсаторы 1nF на 330pF и всё заработало без глюков, уже 15 минут крутит на максимуме оборотов, SPI 1Mhz ни одной ошибки (тьфу тьфу тьфу), раньше за это время уже бы вылетело.
вот рабочая схема

кстати, мою догадку подтвердил вот этот документ
там вообще 10pF поставили

хз, что у них с микрой или создателями даташита или чего на шине такая бяка. вообще такие вещи лучше маги вуду свчшники понимают. если взять приборчиков и почитать статей на подобии https://geektimes.ru/post/255112/, оно попонятней будет, что происходит и как правельней делать.

похоже дело даже не в длине линий, фронты везде чёткие (если конденсатор убрать)

и кстати , вообще без кондёра тоже работает я не понял для чего задержка нужна
при падении Csn на DO появляется импульс длительностью 500нсек кондер этот импульс немного искажает (смазывает фронты)
По идее этот импульс ни на что не может повлиять т.к. для переключения режима требуется импульс 2мксек

И если честно я до конца не понимаю как работает передача сигнала по цепи DO->PROG->DO->PROG->DO->PROG->DO

я грешу на помехи по питанию, т.к. проблема полностью не исчезла.

судя по осциллограммам работает всё правильно, по документации, однако иногда датчик всё же переключается в режим калибровки, пробовал поставить в параллель кондёру резистор в 2ком не помогает.
поставил триггер на осциллографе на напряжение 4в и увидел что иногда проскакивают импульсы большой амплитуды но длительностью 200ns
попробую запитать контроллер от отдельной АКБ, если поможет буду думать какой фильтр ставить, моторы слаботочные но индуктивность у них большая.
если не поможет то даже не знаю

отдельный АКБ на микроконтроллер не помог, но правда полностью развязать не удалось, помехи от двигателей всё равно пролазили.
пока искал причину помех, коротнул щупом осцила 12в и ножку контроллера, контроллер умер.
под рукой STM32F103RCT6 не оказалось, пришлось ставить STM32F405RGT6, а под него пока всё адаптируешь... как по новой всё делать.

В общем я молодец, спалил и контроллер и силовые транзисторы и датчики as5040 теперь сильно глючат сплошные ошибки в протоколе

Решил всё обновить, вот появились готовые сенсоры/комплекты для gimbal моторв
http://ru.aliexpress.com/item/Magnetic- ... 1744021215

ams не отправляет семплы в РФ у них в списке нет такой страны.

решил заменить AS5040 на AS5045 по цене не сильно отличается
в отличие от AS5040 в них есть программный режим выхода из alignment mode

но они медленнее, даже в fast режиме, но в моём случае это не так критично т.к. опрос 4х датчиков даже на 1Мгц это не менее 100мкс.

а ещё есть датчик AS5132 8.5 разрядов до 6 полюсов и очень быстрый, позиционируется как замена датчикам холла.