Приветствую.
Не могу вспомнить где видел про несколько однотипных процессов в СПК.
Допустим управление котлами. Где процессы контроля в плк идут параллельно друг другу.
Описал логику для одного котла, а затем ее расширить на 4 котла.
Спасибо.
Вид для печати
Приветствую.
Не могу вспомнить где видел про несколько однотипных процессов в СПК.
Допустим управление котлами. Где процессы контроля в плк идут параллельно друг другу.
Описал логику для одного котла, а затем ее расширить на 4 котла.
Спасибо.
Это называется FB.
И потом вызываете из PLC_PRG с необходимыми параметрами.
Либо через конфигуратор задач.
У меня работает проект на СПК110 с "параллельными" процессами, а именно контроллер нагрева многозонной (16 зон) печи. Общая концепция - считываем показания датчиков, обрабатываем, пишем результат в виде процента мощности в выходные блоки (ШИМ). Был написан один канал потом просто скопирован нужное число раз, естественно, с изменением нужных переменных. Полный цикл с учетом опроса "медленных" входных модулей занимает менее 3 сек. Точность поддержания температуры - 0.2*С, Проблем не наблюдается. Думаю, котлы буду малость помедленнее.Цитата:
Сообщение от Korhan
Данный вариант (без использования массива FB) возможно будет работать только с простейшей логикой. Если в FB будет, например, таймер, то однозначно не подойдет, т.к. экземпляр FB один на все 4 котла.Цитата:
Сообщение от приборист
Я использую в этом случае массивы FB:
Создается один функциональный блок FB_KOTEL, а в программе объявляется массив функциональных блоков KOTEL[i]:
VAR
...
KOTEL: ARRAY[1..i_max] OF FB_KOTEL;
...
END_VAR
Вызов экземпляров функциональных блоков из PLC_PRG:
FOR i:=1 TO i_max DO
...
KOTEL[i](i:=i, ...);
...
END_FOR
Входные, выходные и другие индивидуальные переменные экземпляров функциональных блоков удобнее задавать массивом структуры, хотя двухмерный массив думаю тоже подойдет.
Интересный метод.Цитата:
Сообщение от vniko
А что понимается под не простейшей логикой?
Не надо никаких циклов. Эти функциональные блоки всё равно где-то потребуется привязать к реальному миру — там их можно заодно и вызвать. Вот один из старых проектов:
Вложение 21127
ФБ «UNIT» мог бы быть сколь угодно сложным.
Кстати действия типа Unit.Close, Unit.Abort я таким образом не использую больше.
To vniko:
Хороший класс. Плюс сразу видно спеца, пришедшего с программирования на ПК.
Такая штука - в ПЛК программа априори выполняется циклически сверху вниз. По этому дополнительный цикл или условие нужно использовать только чтобы "не вызывать" какой то из блоков.
А так их можно просто один за другим вставить в поле проекта. Без for и while...
To korhan:
Если у Вас стоит CODESYS 2:
http://www.owen.ru/forum/showthread.php?t=13588
10 и 11 пример для Вас.
Спасибо за ответы.
To Николаев Андрей:
Нет, CODESYS 3.5 для СПК207.
Но за примеры, спасибо. Скачал, посмотрю (CODESYS 2 тоже есть).
Добрый день, Vniko. С написанием ФБ и последующем размножением через массив понятно. Цикл FOR для "оживления" также ясен. А вот что имеется ввиду в последней строке сообщения: "Входные, выходные и другие индивидуальные переменные экземпляров..." Я обычно использую область VAR_INPUT и VAR_OUTPUT сответсвенно. Могли бы Вы написать коротенький пример с применением структуры. Заранее спасибо..Цитата:
Сообщение от vniko
Сложно сказать, что именно предлагал Vniko, опишу варианты.Цитата:
Сообщение от sa_mut
Предположим есть у нас ФБ, отвечающий за зону нагрева:
А зон таких у нас может быть до 20ти.Код:FUNCTION_BLOCK Zone
VAR_INPUT
// Температура в зоне
rTemperature : REAL;
// Давление в зоне
rPressure : REAL;
END_VAR
VAR_OUTPUT
// Какое положение задвижки необходимо задать
rValvePosition : REAL;
END_VAR
1) Делаем так:
1.1) Объявляем структуру, содержащую значения для входов
1.2) Объявляем структуру, содержащую значения для выходовКод:TYPE ZoneInputs :
STRUCT
// Температура в зоне
rTemperature : REAL;
// Давление в зоне
rPressure : REAL;
END_STRUCT
END_TYPE
1.3) Объявляем массивы структур, содержащие данные для входов и выходовКод:TYPE ZoneOutputs :
STRUCT
// Температура в зоне
rTemperature : REAL;
// Давление в зоне
rPressure : REAL;
END_STRUCT
END_TYPE
1.4) Объявляем массив ФБ наших зон:Код:PROGRAM PLC_PRG
VAR CONSTANT
m_c_usiMaxZones : USINT := 20;
END_VAR
VAR
m_astInputs : ARRAY [1..m_c_usiMaxZones] OF ZoneInputs;
m_astOutputs : ARRAY [1..m_c_usiMaxZones] OF ZoneOutputs;
END_VAR
1.5) Наполнение PLC_PRG делаем примерно таким:Код:PROGRAM PLC_PRG
VAR CONSTANT
m_c_usiMaxZones : USINT := 20;
END_VAR
VAR
m_astInputs : ARRAY [1..m_c_usiMaxZones] OF ZoneInputs;
m_astOutputs : ARRAY [1..m_c_usiMaxZones] OF ZoneOutputs;
m_afbZones : ARRAY [1..m_c_usiMaxZones] OF Zone;
END_VAR
2) Честно говоря особых преимуществ перед следующим подходом не вижу:Код:m_astInputs[1].rTemperature := 10.0; // Тут скорее будут данные с датчиков
m_astInputs[1].rPressure := 12.2;
// ... и т.д.
FOR i := 1 TO m_c_usiMaxZones DO
m_afbZones[i].rPressure := m_astInputs[i].rPressure;
m_afbZones[i].rTemperature := m_astInputs[i].rTemperature;
m_afbZones[i]();
m_astOutputs[i].rValvePosition := m_afbZones[i].rValvePosition;
END_FOR
// Устанавливаем положения задвижек получив значения из m_astOutputs[i].rValvePosition
2.1) В том месте, где нужны наши зоны объявляем массив ФБ
2.2) Тело программы делаем примерно таким:Код:PROGRAM PLC_PRG
VAR CONSTANT
m_c_usiMaxZones : USINT := 20;
END_VAR
VAR
m_afbZones : ARRAY [1..m_c_usiMaxZones] OF Zone;
i : USINT;
END_VAR
Код:m_afbZones[1].rTemperature := 10.0; // Тут скорее будут данные с датчиков
m_afbZones[1].rPressure := 12.2;
// ... и т.д.
FOR i := 1 TO m_c_usiMaxZones DO
m_afbZones[i]();
END_FOR
// Устанавливаем положения задвижек получив значения из m_afbZones[i].rValvePosition
Спасибо, Алексей
согласен с Вами:Я также делаю по версии 2. Вот и хотел понять, что подразумевает Vniko и для используется массив структур. Ведь если алгоритм все равно обрабатывается в ФБ, то INPUT/OUTPUT переменные ФБ-ков получается просто будут дублировать данные массива структур. Что собственно и видно из приведенного Вами примера. Будем надеется Vniko объявится и подскажет какую пользу несут эти дополнительные массивы.Цитата:
2) Честно говоря особых преимуществ перед следующим подходом не вижу:
Попробую ответить за некропосты от vniko (если что - он поправит).Цитата:
что подразумевает Vniko
Вначале сам vniko не понял что приборист (п#2) сказал тоже самое что и он.
Как уже отметили, Вар.1 и 2 - одно и тоже по конечному результату, но "особенности" есть.
Никто и не говорит что вар.1 лучше всегда. Вообще не бывает одного "наилучшего варианта навсегда" для чего-то ни было. Лучший вариант может быть только для конкретного объекта и конкретных условий. Условия включают в себя и возможности реализатора решения))Цитата:
Сообщение от Осинский Алексей
Для вар.1 - например необходимость отделения структурированных данных от "тела" ФБ для сетевого обмена. Не всегда сами ФБ можно расположить непосредственно в сети, а именно для КДС3 еще и категорически опасно. Индусятина с ручной правкой допустима (по мне и ввиду отсутствия удобной альтернативы) только в привязке к физическому миру (показана и в вар.1 и вар 2. и от Yegor п#6). Но от физ.входов до физ.выходов может быть большое кол-во дополнительных и необходимых для наблюдения данных.
То что хотел сказать приборист (п#2), думаю может уточнить только он. Если буквально воспринимать его пост, то получается такой алгоритм: создаётся FB и из программы вызывается один его экземпляр, каждый раз для разных объектов (с разными входными и выходными переменными). Поэтому я и уточнил, что лучше использовать несколько экземпляров FB (массив FB), для каждого однотипного объекта свой. Входные и выходные переменные FB удобно определить как структуры, а для массива FB, следовательно, надо определить массивы структур.Цитата:
Сообщение от Валенок
Вариант с одним экземпляром FB для нескольких объектов, полагаю, тоже имеет право на существование, но с ограничениями.
sa_mut, пример с определением и применением структуры привел Осинский Алексей. Только, как правильно заметил уважаемый Валенок, варианты 1 и 2 это одно и тоже. А "особенность" состоит в том, что в варианте 1 указано откуда берутся массивы входных переменных и куда отправляются массивы выходных переменных массива FB. В варианте 2 эта "особенность" просто пропущена.
sa_mut, если Вы определили массивы структур для массива FB, то Вам нет необходимости дублировать переменные в VAR_INPUT и в VAR_OUTPUT при определении самого FB. Да, забыл добавить важное замечание - массивы структур для FB я определяю в глобальных переменных.
У меня в VAR_INPUT для FB только:
i: USINT; //номер экземпляра FB.
В VAR_OUTPUT для FB ничего не определяю.
Обращение к переменным массивов структур в FB:
ИмяМассиваСтруктуры[i].ИмяЭлементаСтруктуры
Массив FB определяю в программе, из которой будут вызываться экземпляры FB.
Вызываю экземпляры FB в этой программе в теле цикла FOR i:=1 TO i_max DO так:
ИмяМассиваFB[i](i:=i);
Согласно моей реализации однотипных процессов, поправлю вариант 1 из поста #10 Осинского Алексея:
Пускай это будет вариант 3, а сам вариант 1 из #10 я бы никому не посоветовал. Зачем дублировать входные и выходные переменные FB? Ведь их и без того много.
3) Делаем так:
3.0) Предположим есть у нас ФБ, отвечающий за зону нагрева:
А зон таких у нас может быть сколько угодно, задано 20.Код:FUNCTION_BLOCK Zone
VAR_INPUT
i : USINT; //номер экземпляра FB.
END_VAR
VAR_OUTPUT
END_VAR
3.1) Объявляем структуру, содержащую значения для входов
3.2) Объявляем структуру, содержащую значения для выходовКод:TYPE ZoneInputs :
STRUCT
// Температура в зоне
rTemperature : REAL;
// Давление в зоне
rPressure : REAL;
END_STRUCT
END_TYPE
3.3) Объявляем массивы структур, содержащие данные для входов и выходов в GVLКод:TYPE ZoneOutputs :
STRUCT
// Какое положение задвижки необходимо задать
rValvePosition : REAL;
END_STRUCT
END_TYPE
3.4) Объявляем массив ФБ наших зон:Код:VAR_GLOBAL CONSTANT
m_c_usiMaxZones : USINT := 20;
END_VAR
VAR_GLOBAL
m_astInputs : ARRAY [1..m_c_usiMaxZones] OF ZoneInputs;
m_astOutputs : ARRAY [1..m_c_usiMaxZones] OF ZoneOutputs;
END_VAR
3.5) Наполнение PLC_PRG делаем примерно таким:Код:PROGRAM PLC_PRG
VAR
m_afbZones : ARRAY [1..m_c_usiMaxZones] OF Zone;
i : USINT; //номер экземпляра FB.
END_VAR
То есть, основное отличие варианта 2 от варианта 3:Код:m_astInputs[1].rTemperature := 10.0; // Тут скорее будут данные с датчиков
m_astInputs[1].rPressure := 12.2;
// ... и т.д.
FOR i := 1 TO m_c_usiMaxZones DO
m_afbZones[i](i:=i);
END_FOR
// Устанавливаем положения задвижек получив значения из m_astOutputs[i].rValvePosition
Вариант 2 - переменные FB определяются во входных/выходных переменных FB.
Вариант 3 - переменные FB определяются в глобальных массивах структур.