ПИД регулятор на ARM Опции

[kanzler]

Господа! Прошу подсказать где можно взять программный модуль(на Си) ПИД регулятора под ARM?

[SpyBot]

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

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

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

[Dir]

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

Вообще то это я говорил, что делал регулятор для стабилизации потока и, наверное, должен ответить.
Приведите пример бесконечно отрицательной и бесконечно положительной нагрузки, тогда я вам может и поверю. А так нагрузка либо есть, либо ее нет. Соответственно нельзя приложить бесконечное регулирующее воздействие любого знака, чтобы компенсировать возмущение.
И, в конце концов, пояснит ли кто-нибуть чем конкретно не нравится простая и логичная операция из одной команды, которая не позволяет неограниченно расти интегральному терму, которое я привел в начале темы (топик 12):

Код

...
    fError = fSetPoint - fProcessValue;
...
    fsError = pid->fSumError + fError;
    fIterm = pid->fKi * fsError;
...
    fRet = fPterm + fDterm + fIterm + pid->fMinPID;
//
    if (fRet > pid->fMaxPID)
        return (WORD)(pid->fMaxPID);
    else if (fRet < pid->fMinPID)
        return (WORD)(pid->fMinPID);
    pid->fSumError = fsError;
    return (WORD)fRet;

Т.е. сравнимаем полученное регулирующее воздействие (fRet) с границами регулирования (pid->fMinPID, pid->fMaxPID) и если оно выходит за эти границы, то интегральный терм (pid->fSumError) замораживается, т.к. просто программа не доходит до его обновления. Мы, фактически, выбором этих границ и регулируем наш I-терм. О каком пристальном внимании речь? И просьба пояснить чем плохо именно данное решение, а не приводить примеры, вводящие дополнительные ограничения I-терма.
А насчет того, зачем тут плавучка я уже говорил: сравните текст программы в AVR221 в целочисленном виде и приведенный в топике 12 данной темы ее плавучий аналог и все станет ясно. Программа скукоживается в несколько раз, все внимание разработчика к процессу, а не к особенностям реализации в целых числах. Запасов производительности у ARMа, как правило, хватает.
PS. Для профи это, конечно, не аргумент. Они оперируют понятиями "робастности" и т.п. У них свои критерии и свои объекты регулирования: атомные станции, ракетоносители, авиатехника... А что делать простым программистам и электронщикам у которых такая задача как, например, управление потоком CO2 или его температурой стоит раз в 3 года и занимает 0,01%. Утром поставили задачу и до обеда ждут решения в железе. Отлаживать целочисленку ни времени, ни аргументов не хватает.

[маша]

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

Да куда же еще ему позволять расти интегральному терму, когда выход у вас уже в максимуме??? Это же равносильно ограничивать сам интеграл значениями fMaxPID и fMinPID, разница на П и Д составляющие небольшая и скорее всего не принципиальная. Это базовый вариант любого ПИД.
Нужно решать проблему, когда при неизменной уставке знак ошибки сохраняется длительное время, а интеграл накапливается. Вскоре он дойдет конечно же до максимума или минимума значения выхода. Но что будет с самим объектом, выдержит ли он максимальное управляющее воздействие чтобы отрегулировать параметр, который ни в какую не хочет регулироваться?
А может у вас есть еще методика расчета значений fMaxPID и fMinPID для всех режимов работы объекта? или это просто максимальное значения разрядности, например ШИМ?

[Dir]

А может у вас есть еще методика расчета значений fMaxPID и fMinPID для всех режимов работы объекта? или это просто максимальное значения разрядности, например ШИМ?

Особой методики нет. Просто экспериментальным путем подбираю эти макс. и мин. значения ШИМ, чтобы регулируемая величина достаточно быстро доходила до минимума и максимума и при возврате назад в регулируемую область ощутимой задержки не было. Обычно 2...4 итераций хватает. Занимает времени меньше, чем подбор коэффициентов ПИД. А потом, как правило, пересчитываю параметры регулятора так, чтобы диапазон регулировки ШИМ был от 5 до 95% для всего диапазона выходных величин.
PS. Пересчитывать или нет, переделывать или нет определяется чаще всего причинами, напрямую к регулированию касательства не имеющими.

[alexander55]

Особой методики нет.

Пусть закон регулятора ПИ
U[i]=Kп*X[i] + Ки*Sum(X[i])
Пусть Umax - модуль максимальной величины U[i]
Sum_max=Umax/Ki - модуль максимального значения интегральной суммы, т.е.
ограничения в (+) Sum_max, а в (-) -Sum_max.
Не правда ли очень просто и ясно ?