Расчёт электропривода, измерение скорости, матлаб Опции

[RHnd]

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

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

Неправда, кстати.

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

[evg123]

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

Колебания, конечно будут от них никуда не уйдешь. Я использую модель двигателя - блочок: Simulink->SymPowerSystems->Machines->Permanent Magnet Synchronous Machine, в который я заложил параметры реального двигателя, который должны привезти. Блочок выдаёт всю информацию о состоянии двигателя, в том числе скорость. Если в качестве обратной связи я беру эту скорость непосредственно от этого блочка, то вижу незначительные колебания. Если же я беру с блочка данные о положении, пропускаю их через квантователь по уровням, дальше из этого ступенчатого сигнала выделяю скорость, то в результате имею колебания раз в десть больше по амплитуде => есть узкое место в алгоритме определения скорости.

[RHnd]

Колебания, конечно будут от них никуда не уйдешь. Я использую модель двигателя - блочок: Simulink->SymPowerSystems->Machines->Permanent Magnet Synchronous Machine, в который я заложил параметры реального двигателя, который должны привезти. Блочок выдаёт всю информацию о состоянии двигателя, в том числе скорость. Если в качестве обратной связи я беру эту скорость непосредственно от этого блочка, то вижу незначительные колебания. Если же я беру с блочка данные о положении, пропускаю их через квантователь по уровням, дальше из этого ступенчатого сигнала выделяю скорость, то в результате имею колебания раз в десть больше по амплитуде => есть узкое место в алгоритме определения скорости.

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

Модель у вас с трением? Сколько дискрет датчика в амплитуде колебаний?

[evg123]

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

Идея оказалась плодотворной. Как мы (я и ещё один мужичок) до неё сами недопетрили? Зациклились. Чего только не нагородили: дифференцирование по многим точкам, пробовали метод наименьших квадратов, линейный экстраполятор положения... По сути же решение проблемы было следующим: на входе за период Ts=50 мкс. может быть всегда приращение только на одну дискрету (чтобы было две дискреты - он должен вращаться со скоростью > 2.45 об/сек, а у него по тех.заданию максимум 2 об/сек). поэтому вычисление скорости - это подсчёт периодов самплирования на интервале времени между двумя приращениями, и скорость = 1.0 (или -1.0)/(<количество периодов> * 50 мкс) ; при этом как только пришло новое приращение - я сразу выдаю результат, полученный из подсчётов по предыдущему интервалу. далее: поскольку после прихода очередного приращения и выдачи очередного значения скорости, ротор может остановиться и новое приращение - никогда не наступить, то неправильно было бы оставлять выход в старом значении скорости, а через время его надо сбросить в ноль. поэтому вводится поправка, что значение скорости, посчитанное по предыдущему интервалу удерживается на выходе не дольше чем количество периодов, посчитанное на предыдущем интервале. Метод дал хороший результат.

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

Модель у вас с трением? Сколько дискрет датчика в амплитуде колебаний?

Можно задать вязкое трение. Но производитель двигателя дал почти все параметры, кроме этого. То что недодал - посчиатли сами.

После применения алгоритма по описанному методу (ещё раз спасибо @Arc) - амплитуда колебаний - где-то 3 дискреты дачтка (это модель; реалии, конечно, будут другие)
до того (наши тупые алгоритмы) было 10 дискрет, а идеальное измерение скорости давало одну дискрету, а если ещё идеально измерять и положение (тогда модель становится линейной) - то вообще ноль дискрет (но это и понятно - безконечная точность).

По поводу удаления контура скорости вообще - тут так не получится. Я в процессе нарыл методичку как раз по расчёту подобного привода - там всё описано, (но, к сожалению, много опечаток). Там на 19 стр. написано что, T контура положения = 4 * T контура скорости. Но это в области малых сигналов.

Прикрепленные файлы

 elprivod_panasonic_description_sometimes_with_errors.pdf ( 1.76 мегабайт ) Кол-во скачиваний: 154

 

[RHnd]

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

По поводу удаления контура скорости вообще - тут так не получится. Я в процессе нарыл методичку как раз по расчёту подобного привода - там всё описано, (но, к сожалению, много опечаток). Там на 19 стр. написано что, T контура положения = 4 * T контура скорости. Но это в области малых сигналов.

Грустно. Скажите мне, где сказано, что без контура скорости не получится? Сами подумайте, если вам софт-сенсор гадит, то может без него лучше будет?
Вот так нароют какую-то методичку и все, на этом теория управления кончилась.

[evg123]

Для электропривода который Вы применяете, как датчик угла чаще применяется "Resolver".
[attachment=60508:servo_mo..._devices.pdf]

Будем использовать ЛИР-ДА119А (13 разрядов)

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

Потрясём механиков, надеюсь они скажут это всё. Сейчас знаю, что будет редуктор (1:10) и некая инерционная болванка, на которую будут случайным образом действовать расшатывающие моменты и вверх и вниз, то есть задача привода - сохранить её положение.
По предварительным расчётом ( с учётом редуктора ) момент инерции этой болванки где-то в 10-15 раз меньше чем момент инерции ротора. (редуктор съедает всё).
Одна из задач чтобы сухое трение убарть. т.е. и редуктор и болванка будут смазаны солидолом, и сухого трения должно быть сведено к минимуму.

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

Грустно. Скажите мне, где сказано, что без контура скорости не получится? Сами подумайте, если вам софт-сенсор гадит, то может без него лучше будет?
Вот так нароют какую-то методичку и все, на этом теория управления кончилась.

Здесь измерение скорости имеет ключевое значение для определения угловой электрической скорости. там 19 пар полюсов, соотв. электрическая угловая скорость - в 19 раз быстрее обычной. И её надо измерить точно, чтобы потом задать соответствующую компенсацию в контура регулирования токов и управлять крутящим моментом мотора.
То есть получается, что (когда я измеряю электрическую угловую скорость) - я знаю, что задал я такие-то напряжения на фазы двигателя -> я получил через очень короткое время нужный крутящий момент. Если же скорость (обычную и соответственно электрическую) не измемерять, то у меня нет прямой связи (т.е. простое инерционное звено) между поданным напряжением и результирующим вращающим моментом, а этот вращающий момент ещё зависит и от скорости вращения ротора, и ( о самое ужасное !! ) при какой-то скорости вращения ротора поданное напряжение вообще никак не влияет на ток в обмотках статора. То есть в контур регулирования токов статора (напряжение статора -> ток статора) вводятся дополнительные компенсирующие связи, которые вводят в петлю некие поправки, позволяют развязать управление токами от скорости вращения двигателя. Внешний контур скорости, при этом выполняет ещё и ту функцию про которую Вы спрашивали - ограничивает максимальную скорость вращения электромотора.

[RHnd]

Конечно, если на софт-сенсоре скорости висят дополнительные обязанности, то без него некуда. Но, возможно, допустим такой расклад - для управления моментом данные скорости используются, а для управления углом - нет? Остается, конечно, вопрос с ограничением максимальной скорости, который надо обдумывать.

У вас уже на уровне модели колебания 3 дискреты при стоянии в точке. Что же может получится на практике? Когда у вас все шумы и возмущения будут дифференцироваться? Вас устраивает, как у вас модель отрабатывает наброс момента и стохастические возмущения?
Конечно, с большой вероятностью, работать оно будет сносно, особенно если там редуктор. Но ежели колебания будут большие, прежде, чем менять датчик, подумайте над регулированием.

PS: У меня есть неплохой опыт разработки систем управления прецизионными приводами, где надо выдерживать точности лучше одной угловой секунды. Есть разработанные, реализованные и пущенные в эксплуатацию изделия, с массами подвижных частей от десятка килограмм до нескольких тон. И ветер на них дует, и трение неравномерное, и проче и прочее. И ничего, работают системы. И за траекторией следят, и в точке стоят, и нужные точности выдерживают.
И не обязательно тут делать все по крутому, накручивать фильтр Калмана, строить адптивные схемы. Можно обойтись линейными ргуляторами.

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

[evg123]

Да, согласен. задача, вроде как, классическая, привод не прецезионный. Но есть желание выжать максимум (по известному афоризму - делайте хорошо, плохо само получится). Опять же сроки. сейчас выяснил, что вроде как есть 15 битовые датчики.
http://www.skbis.ru/index.php?p=3&c=5&d=41

[Guest_@Ark_*]

...вычисление скорости - это подсчёт периодов самплирования на интервале времени между двумя приращениями, и скорость = 1.0 (или -1.0)/(<количество периодов> * 50 мкс).

Когда от моделирования перейдете к реализации вашей системы (аппаратной и программной), то метод измерения временных интервалов можно (даже нужно) изменить. Современные МК способны измерять времена с точностью порядка 1мкс и менее. Поэтому, точность измерения интервала между дискретами вполне реально поднять где-то порядка на два. Конечно, все еще от сигнала с датчика будет зависеть и методов программирования. Не смотрел какой у вас датчик, но обычно энкодеры выдают на два канала импульсы сдвинутые на полпериода относительно друг друга. Итого - на один дискрет имеем 4 фронта сигналов - диапазон измерения в области малых скоростей и точность установки можно расширить в сторону нуля... В вашем случае, получить точность установки и удержания положения порядка одной дискреты - я думаю вполне реально...
... Посмотрел на ваш датчик. Не знаю, чем обоснован его выбор. Он выдает результат в цифровом виде по RS422. Время между последним измерением и передачай данных неизвестно. Не факт, что оно постоянно. Плюс временная задержка на передачу, прием и обработку данных. А для вас это критично в области малых скоростей. Я бы подобрал обычный инкрементальный энкодер и поставил его дополнительно.
В заключении, по собственному опыту могу сказать, что конечный результат решения таких задач, зависит не только (и даже не столько) от используемых алгоритмов, сколько от искуccтва их реализации на практике.
Желаю удачи.

[evg123]

... Посмотрел на ваш датчик. Не знаю, чем обоснован его выбор. Он выдает результат в цифровом виде по RS422.

Там два варианта - первый вариант - по 1 МБит/с (максимум) по SPI (это SSI, который есть усечённый вариант SPI-я), второй вариант - по УАРТУ (RS422)
Предполагается, что на сам датчик будет раз в 50 мкс опрашиваться со стороны PIC24, который, после элементарной обработки будет отправлять результат в TMS320F28335 (данные и скорость). всё остальное будет делать TMS.
Принцип работы датчика описан в прилагаемом документе. Если производитель не врёт, то должен работать.

Прикрепленные файлы

 LIR_encodedrs_datasheet.pdf ( 366.15 килобайт ) Кол-во скачиваний: 254

 

[Guest_@Ark_*]

Предполагается, что на сам датчик будет раз в 50 мкс опрашиваться со стороны PIC24

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


Сообщение отредактировал @Ark - Sep 15 2011, 14:06