amaora

От скорости зависит, двигатель без железа (coreless). Сделал компенсацию вектора положения (EX, EY) на выходе наблюдателя. Коэффициенты подбираются поиском Нелдера-Мида по замерам пульсации оценки скорости в стационарном режиме, для настройки нужно 1-2 минуты. Перекос оказался скорее на уровне 20% а не как предполагал ранее. Стало значительно лучше. if (pm->config_SKEW == PM_ENABLED) { float ESX, ESY; DX = pm->skew_KF[0] * EX; DY = pm->skew_KF[1] * EX + pm->skew_KF[2] * EY; ESX = EX * EX - EY * EY; ESY = 2.f * EX * EY; DX += pm->skew_KF[3] * ESX + pm->skew_KF[4] * ESY; DY += pm->skew_KF[5] * ESX + pm->skew_KF[6] * ESY; EX += DX; EY += DY; E = 1.f / m_sqrtf(EX * EX + EY * EY); EX *= E; EY *= E; }

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

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

Есть синхронный двигатель с постоянными магнитами с асимметрией обмоток статора, а именно они сдвинуты между собой не точно на 120° а с ошибкой порядка 5°. При работе в бездатчиковом режиме оценка положения пульсирует на эти 5° чем раскачивает всю систему управления. Вопрос, как оценить эту асимметрию, чтобы учесть во время преобразований систем координат? Нужна разовая процедура при неактивном двигателе и хорошо бы сделать это не приводя ротор в движение.

Второй и третий не отличаются существенно, при простой ожидаемой реализации. Но проблема третьего варианта, если это C++, может оказаться в том, что за вызовом метода может скрываться гора шаблонов, наследований, виртуальных таблиц, переопределенных операторов и надо просмотреть значительный объем кода, чтобы понять что происходит. В случае анализа дампа памяти при исключении, например. Шаблоны и перегрузка операторов даёт много больше выразительности коду, чем одиночный класс с методами вместо функций, а реализация какой-нибудь алгебры на операторах была бы полезным примером, ну или STL.

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

В стационарном режиме вращения заполняю таблицу из 6-ти состояний холлов. В каждом столбце количество попаданий в это состояние и сумма векторов положения. После беру среднее от этой суммы и получается среднее положение для каждого состояния холлов, оно и используется при интерполяции. Ну и отбраковка по количеству попаданий и величине ожидаемой суммы. Если одно из состояний ни разу не зафиксировано то ошибка, если одно состояние фиксируется в сильно разных положениях то ошибка. Можно придумать еще условий. Эталонное положение от бездатчикового наблюдателя. По длине периода этих отклонений? Не надежно, но можно подумать.

Слишком большое искажение фазного тока, в чем то другом дело. У меня есть калибровка датчиков Холла, но это больше для упрощения подключения и диагностики, провода чтобы можно было перепутать. Интерполяция все равно будет работать неидеально когда скорость начнет менятся.

Что значит получается, какой зададите такой и будет ток по оси D. Это вопрос следующего контура управления. Ну и причины задавать D ток могут быть разными, не только использование реактивного (reluctance) момента или ослабление, может быть инжекция сигнала для бездатчикового метода, первоначальный разгон без обратной связи по положению и т.д. Про напряжение наверно стоило уточнить, что напряжением надо считать среднее значение за один период модуляции. На этом уровне нет смысла рассматривать физические пространственные магнитные поля, они зависят от конструкции двигателя. Управление работает с абстрактной двухфазной синхронной машиной, которая достаточно точно описывает поведение реального двигателя, в той части которая требуется для управления. Здесь все величины символические.

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

Клавиши назначены не на все действия. Посмотреть действия можно вызвав контекстное меню на каком-нибудь элементе, они подсвечиваются при наведении. Можно на заголовке сверху, на каждой оси, на легенде фигур. В каждом меню слева подписано если есть клавиша для этого действия. По большому списку меню есть нечёткий поиск (при открытом меню начинаем набирать текст, в меню останутся только совпадения), для тех у кого ~100+ графиков или файлов.

Есть README.md и пример конфигурационного файла с описанием всех настроек. Так же можно запустить GP с единственным параметром именем файла и порта. Или можно выбрать файл нажав "O". Настройки порта программа не умеет, всегда работал с уже настроенным портом. Пример CSV файла, заголовок с названиями параметров, единиц измерений и числовые данные. Такой файл можно открыть без настроек, и выбрать столбцы/оси/цвета уже в программе. Или вот пример моей конфигурации для real-time построения. #!/home/amaora/util/gp # vi: ft=conf chunk 20 load 0 1200 text "/dev/rfcomm0" mkpages -1 group 0 -1 deflabel 0 "Time (s)" defscale 0 0.05 0

У всех разные требования, готовое не подходит и пишут свое. У меня нет текстовых меток и отправки параметров обратно, и не думаю в эту сторону. https://sourceforge.net/projects/graph-plotter/

Меня больше всего удивило когда я однажды изобразил умножение на 10 с помощью сдвигов и сложений, а gcc заменил это на одну инструкцию mul, или даже деление там было. По переупорядочиванию, думаю компилятор все правильно делает. Его задача обеспечить меньший расход тактов на выполнение всей функции, он этого добивается переупорядочиванием независимых инструкций для оптимизации загрузки конвейера. Вам же хочется оптимизировать на скорость (или скорее на чистоту асм-листинга?) выполнения отдельный кусочек этой функции. Если такие детали важны то действительно надо написать этот код вручную а не выжимать из компилятора. Проверьте только, может быть помещение той инструкции между вашими ничего не стоит по времени.

Я не очень требователен к функциям отладчика, и без него обхожусь, но вот этим пользуюсь иногда. https://github.com/blacksphere/blackmagic/wiki