К1921ВК01Т (арм Cortex-M4F)

[petrovitch]

В целом технология понятна.
Вопросы в деталях.

Помогите разобраться в ряде фрагментов кода.
1.

Код: Выделить всё

//Сначала легкий фильтр на сам угол
		//0.5 и маски - это магия нечувствительности фильтра к разнице углов больше 360
		//Чтобы при обнулении угла при переходе через 360 градусов при
		//вычитании из 5 градусов 355 получилось 10 (в IQ формате)
		p->theta_finish=p->theta_finish+_IQmpy(_IQ(0.5),((p->theta_elec-p->theta_finish+_IQ(0.5))&0x00FFFFFF)-_IQ(0.5));
		p->theta_finish&=0x00FFFFFF;

Как это работает?

2.

Код: Выделить всё

temp = (p->theta_finish << 8) - (p->theta_start << 8);
		p->d_fi = (temp >> 8);

Зачем эти манипуляции со сдвигом?

3.

Код: Выделить всё

//скорость нефильтрованная, рассчитанная из производной угла за один период
		p->speed_elec_temp=_IQmpy(p->d_fi,p->KThetaToSpeed)<<3;

При инициализации значение p->KThetaToSpeed равно 0. И в отладчике ничего не поменялось.
Или я что-то пропустил? Получается произведение всегда 0?

[Лашкевич]

1. Честно говоря, я не знаю, как ещё описать, кроме уже описанного в комментах. Можно обратиться к небезызвестному GPT-3.5:

2023-10-26_17-21-32.png (39.4 КБ) 12029 просмотров

2.

Код: Выделить всё

temp = (p->theta_finish << 8) - (p->theta_start << 8); p->d_fi = (temp >> 8);

это расчёт производной угла с учётом перехода угла через 1.0. Сдвигом на 8 мы делаем из 8.24 формат 32 разряда на дробную часть, без целого. При вычитании угла 1 градус минус 359 градусов получается результат +2 градуса приращения, так как отрицательное число превращается в положительное из-за дополнительно кода. И при смене угла через 360 нету никакого броска производной.

3. KThetaToSpeed рассчитывается ниже в TposspeedEqep_SlowCalc, чтобы экономить такты в быстром прерывании.

[petrovitch]

Мне удалось дописать код расчёта скорости.
Работает вроде правильно.
Но осталась проблема. Даже в режиме 4 возникает авария (в основном превышение Uпитания).
На низких скоростях (1000-2000 об/мин) более-менее работает длительно. Чуть выше скорость -
и появляются колебания скорости, а затем и указанная авария.
В режиме 5 авария по превышению фазного тока (на картинке). При этом токовые контура отлажены.
Как подловить причину превышения тока?

[Лашкевич]

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

По векторной СУ (режим 5). Чтобы исследовать проблему, вам надо снять ещё как минимум 3-5 осциллограмм. Только по форме разлетающихся токов, конечно же, не понять причину. Выводите (в любом порядке, как удобно) на ряд осц:
1.Угловое положение, поступающее с датчика положения в векторную систему. Может угол прыгает?
2. токи d,q и напряжения d,q с регуляторов
3. Измеренное напряжение Udc - может его измерение барахлит?
4. Заданные напряжения в модуле ШИМ Ualpha, beta и скважности на ключах. Может быть, достигаются предельные скважности (не хватает напряжения?)
5. Токи d,q и задания на токи d,q - может быть прыгает задание тока по какой-то причине?

[petrovitch]

Добрый день.

Постарался проанализировать источник аварий. Не приводя картинок (позже), выяснилось, что
причиной является сбой информации с датчика положения. Это проявляется как резкий скачёк
положения на одном из тактов на случайную величину и возврат с учётом перемещения.
Как следствие, дёргается скорость, задания и т.д.
Надо отметить, информация с датчика поступает по SPI.
Как можно исправить сбои информации (или ложные показания) с датчика положения?

[Лашкевич]

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

[petrovitch]

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

[petrovitch]

Максим, режим 10 в MotorControl для контура скорости использует инкрементальный энкодер?
(это заметно по использованию

Код: Выделить всё

posspeedEqep.speed_elec

)
Мне же необходимо использовать и в контуре скорости, и в контуре положения абсолютный энкодер, работающий по SPI.
Как я понимаю, следует использовать значения датчика скорости от SSI энкодера, подчистив код в реализации режима 10
Можно ли задавать перемещение для контура положения в UniCON и через какую переменную?

[Лашкевич]

Думаю, не стоит вдаваться в этой теме форума в детали, какие строчки в ПО MotorControlDemo менять. Кстати, есть топик про MotorControlDemo . В целом да, надо заменить posspeedEqep на модуль абсолютного энкодера. Задавать угол можно через refs.theta_elec, это Задания.theta_elec в юниконе.

[Arsenii]

Понять не могу: SPI в данном контроллере настолько кривой, что разработчики не удосужились сделать пример с прерываниями? И "Вектор" тоже? Я хочу передавать, допустим пакеты по 8 слов. И принимать, соответственно тоже, по 8 слов. Делаем polling... Все работает все корректно... Включаем режим прерывания. Выставляем прерывания по ROR, и на осциллографе я вижу 8 переданных слов.... В прерывание мы не заходим... Ну да,буфер ведь заполнен, но не переполнен. Да и ладно. Ведь есть прерывания по заполнению буфера приемника наполовину... И тоже не работает, есть пропуски слов! Прерывания по опустошению буфера передатчика не существуют! И как с этим работать? По таймеру, закладываясь на время передачи пакета?

Добрый день.
Подскажите, получилось что-то сделать в итоге?
Если получилось, то не могли бы скинуть рабочий пример?
В обсуждении не нашел.
Спасибо.