Сообщение от
1exan
Валенок же предложил вполне умиротворяющий вариант - в паре со стандартным регулятором чем не подошёл?
Сообщение от
melky
з.ы. мне кажется надо измерять скорость расхода воды, и исходя из этого включать необходимое количество насосов. Нет расхода, не полная емкость - оставляем один насос для докачки.
Спасибо
Сейчас, когда уже готова модель для проверки - смогу проверить разные варианты, и от kondor3000 и от Валенок.
Сейчас занят другими заданиями, сегодня вечером займусь - что-то возьму готовым, что-то создам.
Может, доработаю существующую - при росте уровня не добавлять новый насос или что-то в этом духе. Но это выглядит, как костыль, усложняющий понимание принципов работы системы.
Может и вправду, вариант kondor3000 несмотря на кажущуюся простоту - самый оптимальный - ведь точное до миллиметра поддержание на требуется, а разброс в 300 мм при уставке 8000 мм - не сильно критичен.
---------------
Я ничего не игнорировал, просто модель для проверки была готова только вчера и проверять было не на чем.
Теперь начну проверять разные варианты.
-----------------
Для каскада на основе ПИД регулятора и сетки выбора количества насосов, как понимаю пропуски в интервалах выбора case - это реализация гистерезиса для борьбы с частыми переключениями
Код:
case real_to_udint(rPID) of
0..13: need := 0;
18..31: need := 1;
36..49: need := 2;
54..67: need := 3;
72..84: need := 4;
88..100: need := 5;
end_case
------------------
Проверил вариант, предложенный kondor3000 - в части оценки количества требуемых насосов. Получилось довольно хорошо.
Задал сетку уставок. Переключение (+1 или -1) числа требуемых насосов выполняется на следующей уставке, а не на той, которая вызвала крайнее переключение - подобие гистерезиса.
В моей модели повезло с подбором сетки - баланс наступает точно на задании регулятора, но это случайность - в общем случае ожидал где-то внутри сетки 
Гистерезис организовал по следующему алгоритму:
- пусть в диапазоне между двумя уставками переключения возможно два значения требуемых насосов, в зависимости от того, снижается или повышается уровень - (nMin) и (nMin+1)
- для измеренного уровня и заданной сетки определяю минимальное значение возможных насосов (nMin)
- если на предыдущем цикле запрашивалось меньше nMin, то настал час увеличить до этого минимума
- если на предыдущем цикле запрашивалось больше (nMin+1), то снижаем аппетиты до этого (nMin+1)
Код:
// число агрегатов в диапазоне нахождения измеренного значения уровня
// равно nMin или nMin+1 в зависимости от того снижается уровень или растёт
// Поэтому, если уровень снижается и теперь нужно больше агрегатов (nAmount < nMin),
// то повышаем их запрашиваемое количество.
// Если уровень вырос и агрегатов требуется меньше (nAmount > nMin + 1),
// то понижаем их запрашиваемое количество
IF nAmount < nMin THEN
// если реально включено меньше, то требуем не меньше минимального
nAmount := nMin;
ELSIF nAmount > nMin + 1 THEN
// если уровень поднялся и стало требоваться меньше агрегатов, то на один снижаем
nAmount := nMin + 1;
END_IF
Наверное, можно получить гибрид таких подходов к гистерезису при использованию ПИД - при изменении диапазона переключать или не переключать количество в зависимости от направления изменения выхода ПИД.
А может и не стОит...
Склоняюсь остановить выбор на "сетке уставок", как на близком к ПИД (вернее, П без ИД - отсюда и статическая ошибка регулирования), но простом в пояснении для эксплуатации.
Спасибо большое за помощь в выборе алгоритма!
Ваши права
Ответить с цитированием