Пишем свой ПИД-регулатор

[Валенок]

Критикуйте, хуже не будет. В крайнем случае скажу "ВыНеПонимаете - ЭтоДругое, У_МеняВсёРаботает" ))))

да?

///<Description>Эмулятор объекта управления. Эмулируется последовательное соединение трёх апериодических звеньев 1-го порядка.</Description>
///<Author>!!FPA!!</Author>
///<GroupName>Управляющие и регулирующие модули</GroupName>

function_block Emulator_Cont_ST_

    var_input
        ///<Description>Перезапуск работы блока (инициализация всех переменных состояния) по фронту</Description>
        xReset: bool := false;
        ///<Description>Входная переменная. Управляющий сигнал с ПИД</Description>
        rVLV_Pos: real;
        ///<Description>Внешнее возмущающее воздействие (суммируется с rVLV_Pos для вычислений внутри ФБ)</Description>
        rDisturbance: REAL;
        ///<Description>Значение выхода при rVLV_Pos=0</Description>
        rPV_0: REAL:=20.0;
        ///<Description>Коэффициент передачи объекта управления (трёх последовательных апериодических звеньев 1-го порядка)</Description>
        rGain: REAL:=1.5;
        ///<Description>Постоянная времени первого апериодического звена 1-го порядка, [мс]</Description>
        dwTime_T1: udint:=60000;
        ///<Description>Постоянная времени второго апериодического звена 1-го порядка, [мс]</Description>
        dwTime_T2: udint:=10000;
        ///<Description>Постоянная времени третьего апериодического звена 1-го порядка, [мс]</Description>
        dwTime_T3: udint:=0;
    end_var

вот вообще смотрю и не пойму. Даже пиво поставил и очки взял.

//GroupName: Управляющие и регулирующие модули
//Эмулятор объекта управления (ОУ) 
//Последовательное соединение апериодических звеньев (АЗ) 1-го порядка
//Author: !!FPA!!
function_block Emulator_Cont_ST_

    var_input
        xReset: bool := false;      //Перезапуск. Инициализация всех состояний по фронту
        rVLV_Pos: real;             //Управляющий сигнал с ПИД
        rDisturbance: REAL;         //Возмущающее воздействие (суммируется с rVLV_Pos)
        rPV_0: REAL:=20.0;          //Значение выхода при rVLV_Pos=0. 0 - норм сигнал же?
        rGain: REAL:=1.5;           //Коэффициент передачи ОУ для АЗ-1..3
        dwTime_T1: udint:=60000;    //Постоянная времени АЗ-1, [мс]
        dwTime_T2: udint:=10000;    //... АЗ-2, [мс]
        dwTime_T3: udint:=0;        //... АЗ-3, [мс]
    end_var

стал воспринимать)) но не всё понимать

ПИД.выход -> rVLV_Pos
...
rPV_Inner := (rVLV_Pos + rDisturbance) * rGain;
... rPV_Inner := ...
rPV := rPV_0 + rPV_Inner;
rPV -> обр.связь.ПИД

rPV может и эмулятор объекта управления (ОУ), ну вот ни разу не эмулятор ИУ* которое:

ПИД.выход -> хотелка_Pos.ИУ.rVLV_Pos -> воздействие.ОУ.rPV -> обр.связь.ПИД

и которое имеет 3 состояния :
1.Не крутится.
2.Крутится со скоростью const A
3.Крутится со скоростью const B (которое часто просто = -A)

*Достаточо часто встречающихся

Не знаю, видел в справке к ФБ. Иногда, востребовано - при штатном изменении уставки ограничивают скорость.

Если нужное встроено в ПИД на уровне динамической коррекции И-части то не нужно.

В реализации для Koyo DirectLogic встречал ограничение И-части в виде "заморозка И-части при переполнении выхода" - когда выход (П+И+Д) превышал 100%, он ограничивался 100% и пересчёт И не производился.

Допускаю что это описание чуть-чуть неверное, по факту примерно так:
И-часть пересчитывается всегда, чтобы выход ПИДа не выходил за края.
Если же как описано, то для меня это - в корзину.

Нет, исходника ПИД от встроенного в прошивку ПР - нет, только описание.

Жаль. То же справочное описание замечательного КДС/util/PID не совсем соответствует реальности примерно так же.

закрытые библиотеки для ФБ, реализованных в прошивках

Как для меня это странно. Что в ПИД секретного? И что в матформуле может быть привязано к прошивке?
Поэтому тоже всегда сам ПИД делаю - не доверяю и свои хотелки реализую.
И тоже предпочитаю Kp,Ki,Kd ))

...Или выполнять пересчёт строго по таймеру через заданные промежутки времени..

Вот это - "строго" и это - "по таймеру" тоже странное в общем случае, хотя сами же подсказали

...время прошедшее от предыдущего вычисления..

Место вычисления только не подсказали))

[FPavel]

Я не очень хорошо описал эмулятор.

На вход rGain поступает значение выхода аналогового ПИД регулятора в [%], т.е. число от 0 до 100.
Т.к. что одно, что три последовательных звена 1-го порядка это всего лишь усилитель с множителем rGain и некоторой задержкой, то выход в установившемся режиме будет равен
rPV := rVLV_Pos * rGain
т.е. от 0 до 100*rGain
Но при закрытой задвижке (при rVLV_Pos=0%) возможно, что выход не должен быть равным 0, например, равен rPV_0.
В итоге, получается в установившемся режиме значение выхода
rPV := rVLV_Pos * rGain + rPV_0
Поэтому и такой комментарий к параметру rPV_0 - значение выхода rPV при нулевом значении входа rVLV_Pos=0.

Всякие ///<Description> - это теги документирования - если поместить ФБ в библиотеку Owen Logic, то описание будет выведено в виде таблицы.

rPV может и эмулятор объекта управления (ОУ), ну вот ни разу не эмулятор ИУ* которое:
Да, так и есть - для проверки работы ПИД регулятора и его автонастройки, полезнее получить значение переменной процесса, чем состояние (скорость и направление перемещения) привода.

Вот это - "строго" и это - "по таймеру" тоже странное в общем случае, хотя сами же подсказали
По таймеру - это обычная практика:
- Это примерный эквивалент задачи с периодическим вызовом в Codesys - именно в такую задачу и рекомендуют помещать ФБ ПИД
- ТРМ12, ТРМ32 работают с периодическим пересчётом значения выхода.

Место вычисления только не подсказали))
С Owen Logic всё непросто - для FBD и ST способы определения длительности прошедшего цикла неравнозначны и для ST даёт точный результат, а для FBD - условно точный.
Поэтому для FBD удобнее выполнять пересчёт периодически по таймеру.
А для ST есть возможность в начале программы добавить строки

    // вычисление длительности предыдущего цикла
    dwCurrent  := time_to_udint(get_time());  //текущее время
    dwCycle    := dwCurrent - dwPrevious;   //длительность прошедшего цикла
    dwPrevious := dwCurrent;

[Валенок]

На вход rGain поступает значение выхода аналогового ПИД регулятора в [%], т.е. число от 0 до 100.

На вход rGain у Вас - константа
выход ПИДа у Вас - на rVLV_pos

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

А толку от такого ПИДа если (например) его выход уже падает, а воздействие (через ИУ) спокойно растет?

По таймеру - это обычная практика:

Так себе практика

С Owen Logic всё непросто - для FBD и ST

FBD/ST - без разницы для определения времени. ПИД, если это ПИД (а я незнаю - закрыто же) сам определяет dt. Вот то, что в ОЛ.FBD нет EN - действительно плохо.

А для ST есть возможность в начале программы добавить строки

Не о этом речь. Место вычисления определяющее необходимость расчета ПИДом - не ПИД)) Особенно актуально для КДС

[FPavel]

На вход rGain у Вас - константа
выход ПИДа у Вас - на rVLV_pos

Да, опечатался. Конечно же rVLV_pos - выход ПИД и вход в эмулятор объекта.

А толку от такого ПИДа если (например) его выход уже падает, а воздействие (через ИУ) спокойно растет?

Паровой котёл: и после резкого снижения расхода газа некоторое время рост давления пара продолжится.
Инерция температуры перегретого пара такова, что после 100% перемещения клапана подачи воды в пароперегреватель ещё минут 15 не будет изменения направления графика температуры.
Разрежение в топке котла изменяется через 5-15 секунд после изменения скорости дымососа.

Так что эмуляция инерции - то, что требуется для проверки регулятора.

Так себе практика

Если назвать - ФБ ПИД вызывается в периодической задаче с периодом 500 мс, то это будет эквивалентом вызова по таймеру в реалиях Owen Logic.

FBD/ST - без разницы для определения времени. ПИД, если это ПИД (а я незнаю - закрыто же) сам определяет dt. Вот то, что в ОЛ.FBD нет EN - действительно плохо.

Мы же говорим об Owen Logic - если пересчёт выхода по таймеру, то время это один из входных параметров и его можно использовать при расчётах.
Встроенный ПИД не имеет такого параметра - значит предположительно вычисляет время между вызовами.

Не о этом речь. Место вычисления определяющее необходимость расчета ПИДом - не ПИД)) Особенно актуально для КДС

OL - не имеет средств планирования вызова задач. А в Codesys - наверное, можно определить время между вызовами.