212

Приклади реалізації алгоритмів управління в

середовищі UNITY PRO

Викладений нижче матеріал являється частиною навчального посібника

"Програмування промислових контролерів у середовищі Unity Pro." Навч.

посібник., — К.: Видавництво Ліра-К. — 2013. — с. Тв.

Розділ поданий в авторській редакції та без кінцевих правок і може

розповсюджуватися безкоштовно без будь яких обмежень. Електронна версія

розділу створена для популяризації посібника (в рекламних цілях) з метою

інтенсифікації реалізації паперового варіанту. Деталі та обговорення за

посиланням.

http://asu.in.ua/viewtopic.php?f=147&t=208

Додаткові посилання:

UNITY PRO Швидкий старт

Матеріали по UNITY PRO

Олександр Пупена

213

5. ПРИКЛАДИ РЕАЛІЗАЦІЇ АЛГОРИТМІВ УПРАВЛІННЯ

5.1. Приклади задач на формування, використання та підрахунок

імпульсів

5.1.1. Генерація імпульсів тривалістю 1 цикл із заданою періодичністю

Завдання.

Розробити програму для генерації імпульсів з

заданою періодичністю та тривалістю 1 цикл

(рис.5.1.).

Рішення 1. З використанням таймера.

Один з простих способів реалізації даної задачі –

використати таймер TON, який перезапускає сам

себе. У мові FBD це має вигляд, як на рис.5.2.

При першому циклі контролера таймер

TON_Impuls не запущений, і вихід його

TON_Impuls.Q=FALSE. Оскільки вихід таймера приходить як інвертований сигнал

на його вхід, то на тому ж циклі таймер запуститься і буде в цьому стані до тих

пір, поки вихід таймера не стане TON_Impuls.Q=TRUE. Вихід спрацює тоді, коли

плинне значення таймера досягне уставки,

тобто TON_Impuls.ET>=TON_Impuls.PT.

Спрацювавши, вихід таймера на наступному

циклі скине його, так як його інвертований

сигнал подається на вхід IN. Скидання

таймера приведе до скидання виходу Q, що

знову приведе до запуску таймера на

наступний цикл після скидання. Таким

чином вихід Q протримається один цикл і

буде з’являтися кожні Тімп = 1s100ms +

Tциклу, тому час циклу треба враховувати при формуванні PT.

Рішення 2. З використанням системних

бітових меандрів.

Якщо задана періодичність імпульсів

попадає в набір системних – 10 мс, 100 мс, 1 с або

1 хв, можна скористатися системними бітовими

меандрами. Бітовий меандр – це почергове

слідування значень "0"(FALSE) та "1"(TRUE) з

однаковою тривалістю кожного рівня. У

операційній системі ПЛК (OS UNITY) вбудовані

чотири бітових меандри, доступних через

системні біти %S:

%S4 – 10 мс (5 мс - TRUE, 5 мс - FALSE);

%S5 – 100 мс;

%S6 – 1 с;

%S7 – 1 хв.

Рис.5.1. Вигляд

імпульсного сигналу.

Рис.5.2. Генератор імпульсного

сигналу на основі таймеру.

Рис.5.3. Генератор імпульсного

сигналу на основі системного

меандрового біту: вгорі в LD,

внизу в ST.

214

Імпульс, тривалістю один цикл, з періодичністю у 1 секунду, можна

сформувати по передньому чи задньому фронту системного біта %S6. На мові LD

це може мати вигляд, як на рис.5.3 (вгорі).

У мові ST (рис.5.3 (внизу)) можна використовувати функції RE та FE, однак

перед ними треба робити переприсвоювання у проміжну змінну типу EBOOL, так

як змінні в комірках %S мають тип BOOL, з яким дані функції не працюють.

Системні бітові меандри можна використовувати і для генерації імпульсів з

іншою періодичністю, яка кратна їх періодичності. Наприклад, якщо потрібно

згенерувати імпульс з періодичністю 1 с 100 мс, можна використати програму яка

зображена на рис.5.4.

Для цієї програми використовується змінна Timp типу INT, яка зберігає

плинне значення імпульсу в 100 мілісекундній базі. Кожні 100 мс ця змінна

збільшується на 1 (для цього використовується процедура INC). Коли Timp буде

рівною 11, тобто через 1 с 100 мс, змінна Impuls=TRUE а змінна Timp=0. На

наступний цикл Impuls=FALSE.

Ще одним із варіантів генерування імпульсів є використання блоку

SAMPLETM, який описаний в параграфі 6.2.2.

5.1.2. Генерація імпульсів з заданими періодичністю і тривалістю

Завдання.

Розробити програму для генерації імпульсів з періодичністю 1 с 500 мс і

тривалістю 1 с.

Рішення .

Генератор імпульсів може бути

реалізований двома таймерами: TimerON

– генерує імпульс на включення, а

TimerOFF – на виключення (рис.5.5). При

певних корекціях програми можна

обійтись одним таймером, однак для

навчального прикладу ми навмисно

використали два.

Обидва таймери мають тип ТР,

тобто при запуску (IN=TRUE) вони

витримують імпульс заданої на вході PT

Рис.5.4. Генератор імпульсного сигналу на основі системного меандрового

біту з періодичністю 1 с 100 мс.

Рис.5.5. Генератор імпульсів з

заданими періодичністю і тривалістю

215

тривалості. На першому циклі роботи ПЛК, до виконання цієї частини програми

обидва таймери будуть вимкнені, і на виході видавати Q=FALSE. При обробці

першого таймеру TimerON, він запуститься інвертованим сигналом TimerOFF.Q,

так як він дорівнює FALSE. Відразу, згідно діаграмі таймеру ТР спрацює вихід

TimerON.Q, запираючи в свою чергу таймер TimerOFF через інвертований сигнал.

Після витриманого часу PT=t#1s, імпульс закінчується, тобто вихід

TimerON.Q=FALSE, що в свою чергу приводить до старту TimerOFF, який своїм

виходом скидає TimerON. По закінченню часу TP=t#500ms, скинеться вихід 2-го

таймеру (TimerOFF.Q=FALSE), що приведе до запуску 1-го таймеру.

Таким чином два таймери будуть один одного перезапускати. Вихід одного

з таймерів використовується як імпульсний сигнал Imp_1_05, тобто періодичність

його спрацювання буде 1 с 100 мс, а тривалість – 1 с.

5.1.3. Лічильник мотогодин

Завдання.

Розробити програму для підрахунку кількості відпрацьованого двигуном

годин (мотогодин). У якості змінної, яка відповідає за стан роботи двигуна

використовується M1_RUN (типи BOOL/EBOOL). Змінна M1_MTHR_RST (типи

BOOL/EBOOL) являється командою на обнулення лічильника мотогодин.

Рішення 1. Вихідне значення - мотогодини.

Перед тим, як вирішити задачу, визначимося з типом змінної, яка зберігає

кількість напрацьованих мотогодин. Якщо це буде INT, максимальна кількість

мотогодин буде 32767 годин (біля 3-х років неперервної роботи), UINT – 65535

годин (біля 7-ми років неперервної роботи), DINT – 2147483648 годин (245 тис.

років) а UDINT – 4294967295 (500 тис. років). Можливо INT буде достатньо,

однак для лічильників такого типу є сенс використовувати беззнакові типи, так як

вони не можуть бути від’ємними. Тому є два варіанти – UINT або UDINT.

Для підрахунку мотогодин будемо використовувати лічильник. Однак

рахувати будемо не години, а хвилини, так як при підрахунку годин, в момент

перекодування годинного меандру двигун може не працювати і вмикатися на 20

хвилин в момент відключеного імпульсу. Це все приведе до великих

розбіжностей. Проблему можна вирішити і іншим способом, але в даній задачі ми

використаємо хвилинний системний меандр, який доступний в комірці %S7 (30 с

= TRUE, 30 с = FALSE) і лічильник CTU_UDINT. Тип лічильника вибираємо

UDINT, так як лічильник UINT з максимальним значенням 65535 хвилин (45 діб)

явно замалий для підрахунку.

Враховуючи, що вихід лічильника має тип UDINT, змінну яка вміщує

значення мотогодин M1_MTHR є сенс теж визначити як UDINT. Таким чином

програма має вигляд як на рис.5.6.

216

Уставка PV лічильнику M1_CTU ("лічильнику мотохвилин") виставляється

максимально можливою. Розрахунок мотогодин проводиться звичайним діленням

плинного значення лічильника (хвилини) на 60. Підрахунок імпульсів %S7

проводиться тільки при працюючому двигуні, так як M1_RUN визначає стан

виконання блоків через вхід EN.

При команді M1_MTHR_RST плинне значення лічильника обнуляється.

Однак в даній програмі скидання можливе тільки при працюючому двигуні. Для

можливості скидання лічильника в будь який момент, можна на вхід EN блоку

M1_CTU подати значення результату логічної операції: M1_RUN OR

M1_MTHR_RST.

Рішення 2. Вихідне значення – хвилини, години, доби .

Це рішення можливо не має такої практичної цінності, як попереднє, однак може

допомогти в кращому розумінні роботи програмних лічильників. У даному

варіанті необхідно отримувати час напрацювання двигуна в 3-х окремих

значеннях: доби, години та хвилини. Для збереження цих значень достатньо

розміру типу UINT. Хоч для хвилин і годин згодився б і BYTE, лічильників з

виходом такого типу в UNITY немає, але в ньому і немає необхідності. Таким

чином, для підрахунку "мотохвилин", "мотогодин" та "мотодіб" використаємо три

лічильника типу CTU_UINT. Програма має вигляд як на рис.5.7.

Як і в першому варіанті рішення, лічильник CTU_M1_MIN в момент роботи

двигуна (M1_RUN=TRUE) підраховує імпульси хвилинного меандру %S7. Плинне

значення виводиться в змінну M1_MTMNs (тип UINT). Уставка для лічильника

CTU_M1_MIN дорівнює 60. Це значить, що при досягненні 60 хвилин, на виході Q

цього лічильника сформується логічна "1" (CTU_M1_MIN.Q=TRUE), яка

збільшить на 1 значення лічильника CTU_M1_HOUR, тобто прибавить 1 годину

до M1_MTHRs (тип UINT). Вихід CTU_M1_MIN.Q протримається один цикл

Рис.5.6. Програма для підрахунку мотогодин: рішення 1.

Рис.5.7. Програма для підрахунку мотогодин: рішення 2.

217

Задачі, так як на наступному циклі він же обнулить лічильник через вхід R,

"проскочивши" через функцію OR.

Робота лічильників CTU_M1_HOUR та CTU_M1_DAYS проходить по тому ж

принципу. Тобто через 24 години спрацює вихід CTU_M1_HOUR.Q, збільшуючи

тим самим лічильник діб і скидуючи свій лічильник на наступному циклі.

При команді M1_MTHR_RST плинні значення всіх лічильників обнуляються.

Однак як і в попередньому прикладі, в даній програмі скидання можливе тільки

під час роботи двигуна. Для можливості скидання лічильників в будь який

момент, можна на вхід EN лічильників подати значення результату логічної

операції: M1_RUN OR M1_MTHR_RST.

5.1.4. Аварійна сигналізація.

Завдання.

Розробити програму для аварійної світлової та звукової сигналізації, при

наступних умовах. Стан Тривоги (Аварійного попередження) описується

діаграмою, зображеною на рис.5.8, де стани означають:

1) Alarm OFF – немає активної та непідтвердженої тривоги (Alarm);

2) Alarm ON Not Ack – є активна

непідтверджена тривога;

3) Alarm ON Ack – є активна

тривога, але оператор її не

підтвердив (не квітував,

NOT Acknowledge)

4) Alarm OFF Not Ack –

активних тривог немає, але

оператор не зробив

підтвердження останньої

тривоги.

Тривога переходить зі стану в

стан по 2-м типам подій:

- виникнення або пропадання

аварійного сигналу;

- команда підтвердження

тривоги оператором (квітування тривоги, Acknowledge)

Світловий індикатор може знаходитись у 3-х станах (рис.5.9):

- не горить, при Alarm OFF, тобто немає активних тривог;

- мигає, Alarm ON Not ACK або Alarm OFF Not Ack, тобто коли є

непідтвердженні тривоги;

- горить, при Alarm ON Ack, тобто коли є активні тривоги але вони

підтвердженні оператором;

Звуковий сигнал може бути у 2-х станах:

- включений, при наявності непідтверджених тривог;

- виключений, коли немає непідтверджених тривог;

Рис.5.8. Діаграма станів тривоги.

218

Рішення 1. LD.

У якості аварійного сигналу будемо використовувати змінну Alarm, кнопки

підтвердження - cmdAck, вихід на звукову сигналізацію – AlarmSong, на світловий

індикатор – AlarmLamp. Один із варіантів програми на мові LD приведений на

рис.5.10.

У програмі використана змінна Imp_1_05, яка включається на 1 секунду з

періодичністю 1.5 с. Програма для генерації такого імпульсу наведена в прикладі

з параграфу 5.1.2. Замість змінної Imp_1_05 можна використати системний

меандр %S6. Враховуючи, що кнопка квітування аварії cmdAck є без фіксації, у

програмі використана проміжна змінна alarmAck.

При активації аварійного сигналу включається AlarmSong. Котушка з

фіксацією -(S)- не дасть відключитися звуковій сигналізації, навіть якщо

аварійний сигнал пропаде. Але якщо квітування відбулося (alarmAck=TRUE) –

вмикати звукову сигналізацію повторно не потрібно, цим пояснюється нормально

замкнутий контакт в розриві.

Працюючий AlarmSong говорить про стан "Alarm ON NOT Ack" або "Alarm

OFF Not ACK". У цьому стані світловий індикатор AlarmLamp повинен мигати. Це

реалізується послідовно з’єднаними контактами AlarmSong та Imp_1_05. У стані

Рис.5.9. Діаграма роботи світлової та звукової сигналізації.

Рис.5.10. Реалізація сигналізації на LD.

219

"Alarm ON Ack" індикатор повинен горіти, що забезпечується паралельно

підключеним ланцюгом з послідовними контактами Alarm та alarmAck.

При натисненні кнопки cmdAck, стан квітування зберігається в alarmAck

одночасно зі зкидуванням звукового сигналу. Обнуляється стан квітування тільки

при переході в стан "Alarm OFF".

Рішення 2. ST.

У якості аварійного сигналу будемо використовувати змінну Alarm, кнопки

підтвердження - cmdAck, вихід на звукову сигналізацію – AlarmSong, на світловий

індикатор – AlarmLamp. Один із варіантів програми на ST приведений на рис.5.11.

Це рішення базується на використанні автоматного підходу. Для визначення

кожного стану тривоги, зображеного на рис.5.8, виділена змінна AlarmState, яка

приймає наступні значення:

0 - Alarm OFF

1 - Alarm ON Not Ack

2 - Alarm ON Ack

3 - Alarm OFF Not Ack

інші значення – невизначений стан

Для визначення стану тривоги використовується програмна структура

CASE. На кожному із станів визначення значення AlarmSong та AlarmAlamp, а

також умови переходу в інший стан.

5.2. Приклади задач на роботу з витратомірами та лічильниками

речовини

Перед тим як приступити до вирішення задач з даної глави, слід згадати

деякі визначення.

Об’ємна витрата – це об’єм речовини, пройденої через задану площу

перерізу потоку за одиницю часу (наприклад л/хв. або м3/годину). Масова

Рис.5.11. Реалізація сигналізації на ST.

220

витрата – маса речовини, пройденої через задану площу перерізу потоку за

одиницю часу (наприклад кг/с, кг/год). Для вимірювання витрати

використовуються витратоміри. Сумарний об’єм (або масу) речовини, що

пройшла за певний час через задану площу перерізу потоку, вимірюють

лічильниками.

Таким чином витратоміри вимірюють миттєве значення витрати за одиницю

часу з метою оцінки швидкості потоку, а лічильники – сумарну, для визначення

кількості пройденої речовини.

Сучасні витратоміри оснащені функціями інтегрування, а лічильники –

функціями визначення витрати. Однак інколи обходяться одним або іншим без

вбудованих функцій. Розглянемо дві задачі – отримання сумарної кількості

речовини по показам витратоміра, і навпаки – отримання миттєвої витрати по

лічильнику.

5.2.1. Інтегрування загального об’єму по показам витратоміра

Завдання.

Розробити програму для інтегрування загального об’єму пройденої

речовини по значенню витратоміра.

Рішення1. Метод прямокутників.

Якщо витрата F вимірюється в л/хв, то це відповідає проходженню F/60

літрів за кожну секунду. У загальному випадку, якщо показання витратоміра

зчитуються через кожні delta_t секунд, то за час delta_t через дану ділянку пройде

delta_t*F/60 літрів. Це типова задача інтегрування по часу методом

прямокутників. Графічна інтерпретація методу показана на рис.5.12.

Тобто на кожному перерахунку, через певні інтервали часу, до загальної

суми (сумарний об’єм) добавляється delta_t*F/60 при вимірюванні витратоміром

в л/хв., або delta_t*F/3600 при вимірюванні витратоміром л/год:

Total_vol:=Total_vol+delta_t*F/3600 (5.1)

Рис.5.12. Інтегрування методом прямокутників.

221

При фіксованій delta_t=1с, вимірюванні витрати F в літрах/годину,

програма на FBD для розрахунку загального об’єму буде мати вигляд як на

рис.5.13.

Сумарний об’єм перераховується один раз в секунду, для чого

використовується бітовий 1-секундний меандр %S6 та функціональний блок

F_TRIG для відлову заднього фронту. Таким чином, через кожну секунду буде

викликатися блок ADD, і до TotalVol буде добавлятися F/3600 (ділення

використовується по тій причині, що F вимірюється в літрах/годину).

Якщо використовується швидкий АЦП, і потрібний точний перерахунок,

виклик можна проводити частіше. Крім того, можна використовувати метод

трапецій, який являється більш точним.

Рішення2. Метод трапецій.

Графічна інтерпретація інтегрування методом трапецій показана на

рис.5.15.

У даному випадку використовується середнє значення між плинним (F) і

попереднім значенням миттєвої витрати (Fprev):

Total_vol:=Total_vol+delta_t*((F+Fprev)/2)/3600 (5.2)

Даний варіант реалізуємо на ST (рис.5.14).

Слід зазначити, що при розрахунку кількості речовини по показам

витратоміру потрібно враховувати, що із-за похибки витратоміра і всього каналу

вимірювання може виявитися, що сумарний об’єм за певний час (наприклад добу)

значно відрізняється від істинного. Тому для точних підрахунків кількості

речовини потрібно використовувати лічильники, а не витратоміри.

Рис.5.14. Програма інтегрування методом трапецій.

Рис.5.13. Програма інтегрування методом прямокутників.

222

5.2.2. Інтегрування за сигналом з лічильника

Завдання.

Розробити програму для інтегрування загального об’єму пройденої речовини по

імпульсам лічильника: 1 імпульс = 1 літр.

Рішення. Для збереження сумарного об’єму

речовини краще всього використовувати

змінну UDINT (0-4294967295). При видачі

об’ємним лічильником імпульсу з кожним

пройденим літром, програмний лічильник

зможе накопичити 4294967295 літрів. Для

підрахунку простіше всього використати

блок типу CTU_UDINT. Програма на LD в

цьому випадку буде мати вигляд як на

рис.5.16.

Слід нагадати, що максимальна

тривалість циклу Задачі, в якій необхідно

підраховувати такі імпульси повинна бути

по крайній мірі в 2 рази менше, ніж

мінімальна тривалість імпульсу, інакше ПЛК просто не буде встигати

відловлювати імпульси. Якщо ж частота імпульсів дуже велика – прийдеться

використовувати апаратні лічильні модулі.

5.2.3. Розрахунок витрати за показами лічильника

Завдання.

Розробити програму розрахунку середньої витрати за показами лічильника з

імпульсним виходом.

Рис.5.15. Інтегрування методом трапецій.

Рис.5.16. Програма підрахунку

сумарного об’єму речовини по

лічильнику.

223

Рішення. Якщо використовується лічильник з імпульсним виходом, а потрібно

порахувати середнє значення витрати за певний період, можна сумарний об’єм за

цей період поділити на тривалість періоду:

F=(Total_vol-Total_vol_prev)/delta_t (5.3)

Слід врахувати, що при дуже малих delta_t точність розрахунку буде дуже

низькою, а при великих – інерційність буде дуже високою. Так, наприклад, якщо

витрата змінюється 0-10 л/с, то лічильник може видавати імпульс через кожні 0.1

секунди (якщо налаштований на 1 імпульс/1л). Якщо при цьому delta_t=1 с, то

дискретність значення буде 1/11 літра (0,1,2…10л). Якщо delta_t збільшити хоча б

до 1-ї хвилини, то дискретність вже буде 1/60 літра, однак періодичність виклику

не дасть можливості використовувати його в процесі регулювання. Таким чином

розраховану витрату можна використовувати тільки для контролю.

При delta_t= 60 с, Total_vol в літрах а витрату F потрібно рахувати в л/год,

то

F=(Total_vol-Total_vol_prev)/60 (5.4)

На мові LD програма може мати вигляд, як на рис.5.17.

5.3. Приклади роботи з годинником реального часу та зі змінними

часових типів

Завдання. Розрахунок тривалості часу неперервної роботи механізму

Розробити програму розрахунку тривалості часу неперервної роботи

механізму до його останнього вимикання.

Змінна M1_RUN (BOOL) відповідає за роботу двигуна M1 (стан контактів з

пускача). Необхідно в момент зупинки двигуна отримати значення часу його

роботи.

Рішення1. На основі функцій реального часу. У цьому прикладі використаємо функції:

- RRTC_DT, яка повертає з ПЛК значення реального часу в форматі типу

DT (Date and Time);

- SUB_DT_DT, яка розраховує різницю змінних типу DT і повертає

значення часу в форматі TIME.

Рис.5.17. Програма розрахунку витрати по об’ємному/масовому

лічильнику.

224

Варіант рішення показаний на рис.5.18. У момент пуску запам’ятовується

значення реального часу у змінній M1_StartTime (тип DT). У момент зупинки

запам’ятовується значення реального часу у змінній M1_StopTime (тип DT) а

також розраховується різниця між часом пуску та зупинки за допомогою функції

SUB_DT_DT. Результат різниці отримуємо в змінній M1_RuningTime типу TIME.

Для відлову фронтів використовується функціональний блок TRIGGER: вихід

RISE спрацьовує на один цикл по переході FALSE->TRUE, а вихід FALL – на один

цикл, по переході TRUE->FALSE. При використанні M1_RUN типу EBOOL

замість BOOL, для відлову фронтів можна користуватися функціями RE та FE.

Слід нагадати, що вхід EN активує/деактивує виконання функцій та

функціональних блоків. Крім того слід відмітити, що максимальне значення у

змінних типу TIME - T#49D_17H_2M_47S_295MS (49 діб 17 годин). Якщо двигун

може робити більше, SUB_DT_DT буде оброблений з помилкою, а системний біт

%S18 (OVERFLOW) стане рівним TRUE.

Даний варіант рішення може бути використаний, коли крім тривалості

роботи механізму, треба ще визначати час його останньої зупинки і запуску. У

іншому випадку є сенс використовувати друге рішення на основі таймеру.

Рішення2. На основі таймеру. Це рішення менш ресурсоємне і більш просте. Воно базується на таймері,

який стартує при включенні M1_RUN і працює, поки M1_RUN=TRUE (рис.5.19).

Уставка таймеру дорівнює 30 днів (можливий максимум 49 діб 17 годин). По

задньому фронту сигналу M1_RUN(зупинка двигуна) вихід таймеру ET (плинне

значення) записується в M1_RuningTime. Якщо двигун може працювати

неперервно більше ніж 49 діб 17 годин такий підхід не годиться.

Для відлову заднього фронту використовується функціональний блок типу

F_TRIG. При використанні M1_RUN типу EBOOL замість BOOL, для відлову

заднього фронту можна скористатися функцією FE.

Рис.5.18. Розрахунок тривалості часу роботи механізму: варіант 1.

225

5.4. Приклади роботи зі структурами, масивами та циклами

Завдання. Діагностика роботи виконавчих механізмів.

Розробити програму для діагностики роботи виконавчих механізмів з

датчиками кінцевого положення штока/заслінки.

Виконавчі механізми (ВМ) управляються сигналами з ПЛК одним

дискретним виходом (TRUE=відкрити, FALSE=закрити). Для зворотного зв’язку

по положенню на ПЛК приходить стан 2-х датчиків кінцевого положення штоків:

датчик повного відкриття і датчик повного закриття. Якщо після команди

відкриття через заданий час не спрацює кінцевий датчик повного відкриття, або

включений датчик повного закриття, то повинен спрацювати біт тривоги

відкриття. Те ж саме стосується закриття: якщо після відключення команди

відкриття через заданий час не спрацював кінцевий датчик закриття, або

включений датчик відкриття – повинен спрацювати біт тривоги закриття. Біти

тривоги скидаються при активному біті підтвердження тривоги (квітування).

Заданий допустимий час закриття і відкриття однакові.

Загальні підходи до рішення.

Якщо подібних виконавчих механізмів в програмі повинно бути багато – є

сенс розробляти для них структурний тип, на основі якого створювати масив

змінних, а потім їх обробляти в одній підпрограмі з використанням циклів.

Другий спосіб – створити похідний функціональний блок користувача (DFB) з

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

змінна повинна мати унікальне ім’я, або компоненти структури являються

незалежними змінними. Тут вирішимо задачу першим способом.

Для такого типу задач може бути зручним створення структурного типу

даних користувача (DDT). Створимо DDT з ім’ям VALVE_D (рис.5.20):

Рис.5.19. Розрахунок тривалості часу роботи механізму: варіант 2.

226

Рішення1.Індивідуальна обробка.

Для одиничного випадку діагностики ВМ, тобто без роботи з масивами, або

у випадку використання коду програми в DFB, можна використати мову LD, так

як для цієї задачі вона добре підходить. Створюємо змінну VA1 з типом VALVE_D,

і в поле значення для TimeSP прописуємо TimeSP=5, тим самим задаємо

максимальний час відкриття/закриття рівним 5 секунд.

Нижче наведена програма на LD (рс.5.21). Зверніть увагу, що в програмі

взагалі не використовуються таймери. Замість них, використовується системний

біт %S6 (секундний меандр), по передньому фронту якого збільшується на 1

(процедура INC) значення плинного часу TimeV. Враховуючи, що це значення

зберігається для кожної змінної клапана, цей підхід менш ресурсоємний.

Плинне значення TimeV завжди збільшується, а при нормальній комбінації

станців кінцевих датчиків і команди на клапан – обнуляється. Наприклад, при

відкритті клапану (CMD_OPN=TRUE), при TimeV>TimeSP спрацьовує

Рис.5.20. Структура DDT VALVE_D.

Рис.5.21. Програма діагностики роботи виконавчих механізмів

227

ALRM_OPN. Відключення біту ALRM_OPN пройде в момент команди квітування

(ALRM_ACK=TRUE). Аналогічно працює програма контролю закриття.

Значення TimeV обнуляється при спрацюванні/відключенні відповідних

кінцевих датчиків, а також при зміні напрямку відкриття<->закриття. Останнє

потрібно для запобігання спрацьовування обидвох тривог при спрацюванні хоча б

однієї з них. Для відлову моменту початку закриття і відкриття потрібно

відловити фронти змінної ALRM_OPN.

У програмі фронти відловлюються наступним підходом: використовується

змінна CMD_PREV для зберігання попереднього значення команди і порівнюється

плинне і попереднє значення. Комбінація різних станів CMD_PREV та CMD_OPN

відловить один з фронтів. Нагадаємо, що в LD є спеціальні контакти -|P|- та -|N|-,

якими теж можна було б скористатися.

Рішення2. Групова обробка.

Для групової діагностики ВМ по приведеному вище алгоритму є сенс із елементів

типу VALVE_D створити масив, який потім обробляти з використанням циклів.

Тобто кожний елемент масиву буде відповідати за певний ВМ. У прикладі

використовуються 10 ВМ, тому масив буде мати вигляд як на рис.5.22.

Для кожного елементу масиву задаються свої значення уставок TimeSP. Для

обробки даних масиву використовується цикл в мові ST (рис.5.23).

Рис.5.22. Масив елементів типу VALVE_D

228

Наведений лістинг програми в основному повторює логіку програми,

написану на LD, дещо стиснуту для економії ресурсів. Однак є деякі особливості.

У сучасних Modicon змінні в комірках %S являються типу BOOL, хоч в ранніх

версіях вони були EBOOL. Однак функції RE та FE, які призначені для відлова

фронтів працюють тільки зі змінними типу EBOOL. Тому на початку програми

йде переприсвоєння %S6 в комірку %M6 (типу EBOOL). Адреса комірки вибрана

довільно і замість неї можна скористатися нелокалізованою змінною типу

EBOOL.

Наступною особливістю є використання функції XOR для відлову

відмінності попереднього та плинного значення команд на клапан, що значить

передній або задній фронт сигналу.

Все інше – аналогічне попередньому прикладу. Неважко зрозуміти, що

об’єм такої програми не залежить від кількості виконавчих механізмів. Однак слід

відмітити, що налагоджувати код з використанням циклів важче, ніж без них,

особливо коли немає можливості вставляти точки зупинки, які приводять до

зупинки програми. Тому бажано налагодити програму на одному циклі (як в

прикладі з одним клапаном) а потім "обгорнути" її інструкціями циклу.

5.5. Приклади роботи з підпрограмами та функціональними блоками

користувача

Завдання. Управління однотипними бункерами.

Розробити програму для управління трьома бункерами: один – цукрового

сиропу, два – води (рис.5.24).

Рис.5.23. Програма роботи діагностики виконавчих механізмів з використанням

масивів

229

Робота кожного бункеру описується наступним алгоритмом. У бункерах

необхідно підтримувати заданий межами рівень рідини за допомогою насосів М1.

При вибраному режимі START, насос М1 повинен:

- вмикатися при відключенні сигналізатора LS1 (нижня межа);

- вимикатися при спрацюванні сигналізатору LS2 (верхня межа);

Тобто в бункері повинна постійно знаходитись рідина в межах розміщення

сигналізаторів рівнів.

При вибраному режимі STOP, насос М1:

- вмикається при нажиманні оператором кнопки ManPump;

- вимикається через 5 с по відключенні кнопки.

Загальні підходи до рішення. Самий простий спосіб вирішення задачі – написати програму для одного

бункеру, наприклад як в главі 1.11 і розмножити методом копіювання ще на два

бункера. Крім простоти, перевагою даного підходу являється можливість

індивідуального підходу до алгоритму управління кожним бункером, а також

відносна простота налагодження. Однак якщо індивідуального підходу не

потребується, а кількість бункерів буде набагато більше, наприклад десятки, то

виникає ряд недоліків в такому підході:

- при необхідності зміни програми, це потрібно буде робити в кожній

копії;

- величина програми збільшується пропорційно кількості копій;

Враховуючи однотипність бункерів та однаковий алгоритм управління, є

сенс зменшити програму одним із наступних способів:

- використовуючи підпрограми;

- використовуючи масиви і цикли: тобто всі змінні закласти в масив з

кількістю елементів, яка дорівнює кількості бункерів, а програму

обробки вставити в тіло циклу;

Рішення1. З використанням підпрограм .

SR (підпрограми) очевидно залишились в UNITY PRO для сумісності зі

старими прикладними програмами PL7, при їх конвертуванні в нові версії UNITY

PRO. Без них обійтись можна, використовуючи більш зручний механізм DFB.

Тим не менше в цьому рішенні ми скористаємося SR а також структурами

користувача DDT. Нагадаємо, що підпрограми UNITY PRO не можуть приймати

фактичних параметрів при виклику. Однак реалізація виклику функцій/процедур з

Рис.5.24. Функціональна схема бункерів

Цукровий

сироп

Вода 1 Вода 2

230

передачею параметрів все одно на нижньому рівні реалізуються приблизно

наступним способом:

- в стек поміщуються потрібні параметри процедури/функції;

- запускається потрібна процедура/функція, код якої використовує

значення стека;

- по закінченню процедури або раніше, йде повернення в основну

програму, з розміщенням в стек параметрів які повертаються;

Ми можемо скористатися цим же принципом. Однак замість стека ми

будемо використовувати яку-небудь виділену область пам’яті. Щоб робити з нею

як з єдиним цілим, зручно скористуватися структурними змінними.

Таким чином послідовність роботи програми буде наступною:

- в структурну змінну записується потрібні значення вхідних параметрів;

- запускається підпрограма, код якої використовує значення структурної

змінної;

- по закінченню підпрограми йде повернення в основну програму, де

значення вихідних параметрів зчитується зі структурної змінної;

Створюємо структурний тип користувача DDT "Bunker" (рис.5.25).

Всі поля крім останніх двох відповідають за однойменні змінні в задачі з

глави 1.11. Призначення полів StartDelay та TimeOFF описане нижче. Далі

необхідно створити 4-ри структурних змінних типу Bunker (рис.5.26).

D – змінна, яка використовується в підпрограмі як формальний параметр;

Рис.5.25. Структурний тип користувача "Bunker"

Рис.5.26. Структурний тип користувача "Bunker"

231

B_Sugar, B_Water1, B_Water2 - змінні, які використовуються як фактичні

параметри.

Основу підпрограми з назвою "Dozator" містить код, який приведений в

главі 1.11, як альтернативний варіант програми на LD. Однак програму

прийшлося дещо модифікувати, а саме:

- звичайні змінні замінені на структурні по причинам, які описані раніше

по тексту;

- замість таймерів використовується підрахунок імпульсів;

Таймер в підпрограмах використовувати дозволяється, але це завжди буде

один і той саме екземпляр на всі виклики, а потрібно щоб таймери працювали

незалежно один від одного. Тому таймери TON в підпрограмі замінені

лічильником імпульсів, які надалі в тексті називаються таймерами. Ці таймери

характеризуються наступними значеннями:

- TimeOFF – показує зворотній відлік в масштабі 100 мс;

- StartDelay – сигналізує про пуск таймеру;

Розглянемо роботу програми. У режимі Start все працює аналогічно як в

альтернативному варіанті рішення задачі у главі 1.11. У режимі Stop (-|/|- D.Start)

включення D.M1 проводиться нажиманням кнопки D.ManPump, а відключення -

по відключенню D.ManPump і коли зупиниться таймер D.StartDelay=FALSE,

алгоритм роботи якого описаний далі.

У режимі Stop, і при включеному двигуні D.M1, і відключеній кнопці

ручного запуску насосу (-|/|- D.ManPump), і не запущеному таймері (-|/|-

D.StartDelay), що відповідає ситуації відпускання кнопки ручного запуску насосу,

- час зворотного відліку встановлюється у початкову точку D.TimeOFF:=50, і

виставляється в TRUE змінна D.StartDelay (таймер запущений).

Під час роботи таймеру (-| |- D.StartDelay), при кожному спрацюванні

імпульса Imp100ms, змінна D.TimeOFF зменшується на 1. Таким чином швидкість

зменшення D.TimeOFF буде залежати від періодичності спрацювання Imp100ms.

У основній програмі необхідно забезпечити, щоб Imp100ms спрацьовував через

Рис.5.27. Структурний тип користувача "Bunker"

232

кожні 100 мс рівно на один цикл. При цих же умовах перевіряється чи досяг

таймер своєї межі, і якщо так - D.StartDelay скидається, що значить закінчення

роботи таймеру.

Основну програму запишемо на мові ST (рис.5.28).

Перші два рядки забезпечують генерацію імпульсів Imp100ms тривалістю в

один цикл і періодичністю 100 мс. Інші три – викликають підпрограму Dozator,

передаючи туди фактичні параметри шляхом присвоєння змінній D (яка слугує

формальним параметром) значення потрібних змінних. Після виклику

підпрограми, проходить зворотне присвоєння вихідних параметрів

Рішення2. З використанням DFB Використання DFB дає більш зручний механізм, ніж використання

підпрограм. Створимо похідний тип функціонального блока користувача (DFB

Type) з іменем BunkerDFB. (рис.5.29)

Рис.5.28. Основна програма

Рис.5.29. Похідний тип користувача BunkerDFB.

233

Як видно з рис.5.29 секція Logic практично не відрізняється від 1-го

варіанту реалізації LD у главі 1.11. Єдиною відмінністю є прив’язка уставки

таймеру Timer1.PT до змінної OFFTime, яка визначена в розділі глобальних

мінних функціонального блока. Цього не було в постановці задачі, ми його ввели

для максимального розкриття гнучкості використання DFB. Таким чином,

екземпляри DFB можна налаштувати на конкретний час затримки в режимі Stop.

У змінних проекту достатньо задати три екземпляри DFB, та викликати їх в

програмі, прив’язавши входи і виходи блоків до потрібних фактичних параметрів.

(рис.5.30).

Частина програми для обробки бункеру з цукровим сиропом показана на

рис.5.31. У блоці ".1" виставляється час відключення OFF_Time функціонального

блоку B_SugarFB.

Рис.5.30. Екземпляри функціональних блоків типу BunkerDFB.

Рис.5.31. Виклик BunkerDFB для обробки бункеру з цукровим сиропом.

234

5.6. Приклади створення та використання кусочно-лінійних функцій.

За допомогою кусочно-лінійних функцій можна організувати програмний

задавач (формування завдання в залежності від часу), задавач співвідношень X/Y,

реалізувати кусочно-лінійну апроксимацію нелінійної функції і т.д. Кусочно-

лінійна функція визначена в діапазоні всіх дійсних чисел наступною залежністю:

nn

iiiii

XXприY

niдеXXXприYkXX

XXприY

Y

,

)1..(0,,)(

,

1

00

(5.5)

)(

)(

1

1

ii

ii

iXX

YYk

(5.6)

Графічний вигляд кусочно-лінійної функції показаний на рис. 5.32.

У бібліотеці ControlLIB є функціональний блок LOOKUP_TABLE1, який

реалізовує кусочно-лінійну функцію (див. параграф 6.3.3). Нижче розглянемо

написання власного DFB для цих цілей.

5.6.1. Реалізація кусочно-лінійної функції

Завдання.

Розробити DFB для реалізації кусочно-лінійної функції.

Рішення.

Координати точок Xi і Yi у всьому діапазоні будемо задавати 2-ма масивами

типу REAL. Враховуючи, що кількість точок залежить від задачі, в якій буде

задіяний даний блок, масив повинен бути динамічним. У DFB параметри

INPUTS, OUTPUTS та INOUT можуть бути визначені як ANY_ARRAY_xxx (де xxx

тип масиву) – динамічний масив, що дозволяє прив’язувати до них фактичні

параметри з довільним розміром масиву. Ми скористуємося цією

функціональністю. Таким чином інтерфейс типу DFB блока з іменем PWL_FN має

вигляд як на рис.5.33.

Рис.5.32. Кусочно-лінійна функція.

235

X_IN та Y_OUT – відповідно вхід та вихід функції. Масиви X та Y задають

координати вузлів функції. Для роботи DFB визначені внутрішні змінні (private) i

- для задання індексу масиву та AR_LEN для визначення довжини масиву. Без

останньої можна б було обійтись, але використаємо для наглядності прикладу.

Програмну секцію є сенс написати на мовах ST або IL, так як

використовуються масиви, для обробки яких потрібні цикли (рис.5.34).

На початку секції визначається довжина масиву за допомогою функції

LENGTH_ARREAL, єдиним аргументом якої є один із масивів. Слід відзначити,

що:

- масиви X та Y обов’язково повинні бути одного разміру;

- елементи X повинні рости з ростом індексу в масиві;

Рис.5.33. Опис DFB-типу PWL_FN

Рис.5.34. Програмна секція DFB-типу PWL_FN

236

- незалежно від того, з якого індексу починається фактичний параметри для X

та Y, в програмній секції DFB масиви завжди будуть починатися з 0;

- для роботи з динамічними масивами їх необхідно явно дозволити (Tools-

>Project Settings->Variables->AllowDynamicArray);

Далі в програмі, в залежності від значень X_IN розраховується Y_OUT.

5.6.2. Програма розрахунку об’єму рідини в резервуарі неправильної

форми за датчиком рівня

Завдання.

Розробити програму для розрахунку об’єму рідини в резервуарі

неправильної форми за датчиком рівня.

Основна концепція.

Об’єм рідини в резервуарі правильної форми можна визначити по рівню,

підставивши його в формулу розрахунку об’єму. Найбільш простий випадок – це

резервуари з незмінним перерізом по вертикалі (наприклад циліндричної форми),

що дозволяє доволі просто масштабувати значення з датчика рівня, помноживши

його на коефіцієнт. Однак для резервуарів з неправильною формою розрахувати

об’єм по рівню доволі проблематично.

Один із способів – це експериментально визначити залежність об’єму від

рівня. Для цього на етапі налагодження системи, на нелінійній ділянці (або по

всій висоті) резервуара знімається характеристика V(L), де V – об’єм рідини, L –

рівень. Спосіб визначення об’єму і тип датчика рівня в даному випадку не має

значення, головне – це отримати кусочно-лінійну апроксимацію залежності з тією

точністю, яка потрібна згідно умови задачі. Далі в програмі реалізувати обернену

задачу – по заданій характеристиці V(L) визначати об’єм по рівню.

Рішення.

Скористуємось функціональним блоком типу PWL_FN з попереднього

параграфу. По отриманим точкам V(L), наприклад 6 точок, задаємо два масиви

V(0..5) та L(0..5). При визначенні масиву можна відразу задати значення

елементів при ініціалізації. Далі їх можна змінювати, наприклад в

конфігураційних екранах HMI/SCADA. Змінні та програма наведені на рис. 5.35.

237

5.6.3. Програмний задатчик

Завдання.

Розробити тип функціонального блоку користувача для програмного

задатчика.

Основна концепція.

У системах з програмним управлінням, регулятор повинен підтримувати

значення, задане кусочно-лінійною залежністю від часу. Наприклад залежність

може задаватися наступним графіком (рис.5.36).

Рис.5.35. Використання DFB-типу PWL_FN при розрахунку об’єму

Рис.5.36. Діаграма для програмного задатчика

238

Такий регулятор крім блока, який реалізує один із законів регулювання

(наприклад П, ПІ або ПІД), повинен вміщувати блок програмного задатчика (далі

по тексту ПРЗ), як показано на рис.5.37.

У UNITY PRO для реалізації функціоналу ПРЗ можна використати

бібліотечний блок LOOKUP_TABLE1, приклад використання якого показаний в

параграфі 6.8.2. Тут розглянемо два варіанти з використанням функціональних

блоків користувача.

Рішення1. З використанням спеціально розробленого DFB.

Конкретизуємо задачу: необхідно створити тип функціонального блоку,

який буде на основі заданих координат 4-х вузлів графіка залежності

розраховувати Y=f(T). Даний тип назвемо PRZ3. На рис.5.38 представлений

виклик екземпляру блоку PRZ1 та інтерфейс блоку.

Вхід Start – використовується для запуску внутрішнього таймеру, по якому

проводиться розрахунок вихідного значення. При Start=FALSE значення виходу Y

буде дорівнювати значенню ініціалізації Y0. Входи T1,Y1 і T2,Y2 і T3,Y3 – це

Рис.5.37. Структура регулятору з програмним задатчиком.

Рис.5.38. Структура DFB-типу PRZ3 та приклад його використання.

239

задані координати відповідних вузлів. Крім розрахункового значення на вихід

PRZ3 також подається значення внутрішнього таймеру.

Для роботи блоку потрібен таймер, тому в розділі Private включений

екземпляр типу TON з іменем Timer1.

На рисс.5.39-5.40 показана програмна секція блоку PRZ3. Ідея заключається

в розрахунку значення виходу на кожній ділянці між вузлами. На ділянці T≤T0 (до

старту) значення Y=Y0, а на ділянці T≥T3 - значення Y=Y3. Розрахункових ділянок

всього три: 0..T1, T1..T2, T2..T3. У межах цих ділянок вихідне значення

розраховується за формулою:

YpTpTk

YpYkTpTY

)(

)()( (5.7)

де Tp, Yp – координати вузла початку ділянки; Tk, Yk – координати вузла кінця

ділянки.

Тобто, програма визначає на якій ділянці вона знаходиться, і присвоює

Tp,Yp та Tk,Yk значення відповідних координат. Враховуючи, що координати

T1,Т2,T3 мають тип TIME, їх попередньо необхідно перетворити в тип REAL, так

як такий тип у виходу Y. Таким чином розділ блоку Private включає змінні

Tp_REAL, Tk_REAL и T_REAL.

У блоці враховується, що кількість вузлів може бути менше ніж 4-ри. У

цьому випадку вузли з 0-ю міткою часу не враховуються. Для цього на вхід

Рис.5.39. Програма DFB-типу PRZ3.

240

внутрішнього таймеру Timer1 в якості уставки подається максимальне значення

серед T1,T2,T3.

Вихід таймеру ET подається на вхід блоку, а також перетворюється в

значення типу REAL. Далі визначається ділянка, порівнюючи плинне значення

таймеру з часовими координатами вузлів. Для запобігання роботи незадіяних

вузлів використовується умова спрацювання попередньої уставки по AND. На

кожній із ділянок відбувається переприсвоєння кінцевих точок. На рис.5.40

показана розрахункова формула на кожній із ділянок.

Рішення2. З використанням блоку PWL_FN.

У цьому варіанті використаємо функціональний блок з реалізацією

універсальної кусочно-лінійної функції з параграфу 5.6.1. Для цього створюємо

два масиви: Т – для координат вузлів по часу і Y – для координат вузлів по

значенням. Програма буде мати вигляд як на рис.5.41.

Лічильник CTU_S формує значення часу в секундах від початку

спрацювання Start_Prog. Для цього на вхід CU подаються імпульси системного

Рис.5.40. Програма DFB-типу PRZ3 (продовження).

Рис.5.41. Використання PWL_FN для формування програмного задатчика.

241

секундного меандру %S6. При Start_Prog=FALSE, лічильник обнуляється (CV=0).

Уставка PV=3600 взята довільно, головне щоб була більше >=45, так як це

остання точка по осі часу (T[3]=45.0). Функція INT_TO_REAL використовується

тільки тому, що PWL_FN працює з типом REAL. Вихід PWL_FN і буде значенням

ПРЗ.

Перевагою даного підходу порівняно з минулим заключається в його

універсальності та компактності. У параграфі 6.8.2 показаний приклад

використання в якості ПРЗ функціонального блоку LOOKUP_TABLE1.

5.7. Приклад імітаційної моделі

Завдання. Імітаційна модель установки з 2-ма танками та дозаторами

Розробити DFB-блок для реалізації імітаційної моделі установки, опис якої

наведений нижче, та показати приклад використання цього DFB блоку.

Установка складається з наступних елементів (рис.5.42):

- танки Т1 та Т2, в яких готовляться продукти за різними рецептами; танки

обв’язані наступними засобами КВПіА:

запірні клапани набору та зливу, кожний з датчиками кінцевого

положення "закритий" та "відкритий";

регулюючий клапан (0-100%) подачі теплоагента у теплообмінний

кожух танку (далі по тексту клапан нагрівання);

датчик рівня (0-100%) в танку;

датчик температури в танку (0-100С);

- дозатори (мірні ємності) D1 та D2, які забезпечують подачу дози компоненту;

дозатори обв’язані наступними засобами КВПіА:

сигналізатор нижнього і верхнього рівнів;

запірні клапани набору та зливу, кожний з датчиками кінцевого

положення "закритий";

- 3-ходовий клапан перемикання трубопроводу подачі з дозаторів на танки T1 та

T2; в нормальному стані положення "на Т1"; має датчики кінцевого положення

"Т1" та "Т2".

Модель необхідно розробити з урахуванням наступних припущень:

- ємність і кожух танків і дозаторів – це об’єкти з зосередженими

параметрами;

- густини на входах і виходах кожуха і ємності танків та дозатора однакові;

- танки мають ідеальну теплову ізоляцію, тому втратами теплоти в

навколишнє середовище можна знехтувати;

- теплова ємність конструкції мала, тому можна знехтувати нею;

- площина теплообміну залежить від ступені заповнення танків;

- кожух танків завжди заповнений рідиною;

- об’єм дозаторів вважається дуже малим порівняно з об’ємом танків, тому

можна вважати що витрата з дозаторів не впливає на температуру та

об’єм рідини в танку;

- всі ємності являються циліндричними;

- всі виконавчі механізми разом з регулюючими органами мають лінійні

витратні характеристики;

242

- довжиною трубопроводів можна знехтувати;

- характеристики обладнання та речовин наведені в табл. 5.1.

Таблиця 5.1

Характеристики обладнання та речовин.

танки Т1, Т2 Об’єм ємності 1 м3

Об’єм кожуха 0.05 м3

Поперечний переріз ємності 1 м2

Повна поверхня теплообміну кожуха 10 м2

Коефіцієнт теплопередачі кожуха 2 кВт/(м2*С)

Висота кожуха 1 м

дозатор D1 Об’єм ємності 3 л

Поперечний переріз ємності 20 дм2

дозатор D2 Об’єм ємності 2 л

Поперечний переріз ємності 20 дм2

рідина Діапазон витрат рідини в Т1, Т2 0-25 л/с

температура рідини на вході Т1, Т2 20 С

густина рідини 1000 кг*м3

теплоємність рідини 4.19

кДж/(кг*К)

Рис.5.42. Операторський екран для контролю та управління за процесом

приготування продукту.

243

теплоагент Діапазон витрат теплоагента в кожух

Т1, Т2

0-30 л/с

температура теплоносія на вході Т1,

Т2 90 С

густина теплоносія 1000 кг*м3

теплоємність теплоносія 4.19

кДж/(кг*К)

компонент дозатора Діапазон витрат компоента в/з

дозатора

0-1 л/с

клапан набору Т1 час повного відкриття

клапану/заслінки

3 с

клапан набору Т2,

клапани зливу Т1, Т2

час повного відкриття

клапану/заслінки

4 с

клапани набору та зливу

D1,D2

час повного відкриття

клапану/заслінки

1 c

Примітка. Всі наведені характеристики взяті тільки для прикладу і не мають

зв’язку з реальним обладнанням.

Рішення.

Основна концепція. Згідно прийнятого підходу в главі 4.4, імітаційна

модель буде являти собою програму, яка використовує стандартні функціональні

блоки моделей елементів об’єкту. У даному випадку це будуть 2 ємності

дозаторів, які можна змоделювати подібно до об’єкта в параграфі 4.4.5, 2 ємності

з теплообмінним кожухом (див. параграф 4.4.6), 8 клапанів з різними настройками

(див. параграф 4.4.10). У загальному задача може бути зведена до такої

послідовності:

1) корекція імітаційних моделей компонентів (при необхідності);

2) визначення інтерфейсу DFB імітаційної моделі об’єкту;

3) визначення внутрішніх та глобальних даних DFB імітаційної моделі

об’єкту;

4) написання програмної секції DFB імітаційної моделі об’єкту;

5) написання програми та її налагодження для перевірки імітаційної моделі

об’єкта.

Корекція імітаційних моделей компонентів. Враховуючи велику кількість

входів/виходів імітаційної моделі ємності в параграфі 4.4.5, спростимо цю модель.

Для цього створимо DFB тип smLevelCyl1, структура та програма якого показана

на рис.5.43. Крім зменшення кількості вхідних та вихідних потоків, модель має

два додаткові виходи для сигналізаторів рівнів: LSH – верхнього, і LSL –

нижнього.

244

Всі інші імітаційні блоки з глави 4.4 використовуються без змін.

Визначення інтерфейсу DFB імітаційної моделі об’єкту. Вхідними

параметрами блоку є значення на виконавчі механізми (рис.5.44): для запірних

регулюючих органів (РО) - типу BOOL, для регулюючих клапанів - типу INT в

діапазоні 0-10000. Вихідними параметрами блоку є стан датчиків: для дискретних

- типу BOOL, аналогових - типу INT в діапазоні 0-10000.

Згідно прийнятого в посібнику підході до імітаційного моделювання, блок

повинен включати вхід INIT, через який ініціалізується модель, приймаючи

початкові значення.

Рис.5.43.Блок DFB для імітації дозаторів.

245

Визначення внутрішніх та глобальних даних DFB імітаційної моделі

об’єкту.

Для кожного елементу імітаційної моделі створюється окремий екземпляр

DFB, який інкапсулюється в середині екземпляру DFB загальної моделі. Таким

чином, для кожного клапану, дозаторів та танків створюється свій екземпляр

конкретного типу (рис.5.45). Саме тут визначаються їх глобальні параметри

згідно таблиці 5.1. Нагадаємо, що локальні параметри DFB в тому числі і

екземпляри функціональних блоків недосяжні для доступу з боку зовнішньої

програми. Однак тип DFB блоків повинен бути визначений в проекті.

Крім екземплярів функціональних блоків, DFB також включає глобальну

змінну d_t, призначення якої не відрізняється від прийнятих в інших моделях.

Рис.5.44. Інтерфейс блоку DFB для імітації установки.

246

Рис.5.45.Внутрішні і глобальні блоки DFB для імітації установки.

247

Написання програмної секції DFB імітаційної моделі об’єкту. DFB

включає дві програмні секції (див. рис.5.45):

SimulObj, яка реалізовує безпосередньо модель (див.

рис.5.47-5.48); SET_dt, яка забезпечує

переприсвоювання загального для моделі масштабу

часу (періодичності виклику) всім елементам моделі

тобто екземплярам блоків (див. рис.5.46).

Програма реалізації моделі показана на

рисс.5.47-5.48. Хоч розрахунки в моделі проводяться

в основному з типами REAL, вхідні і вихідні дані

повинні бути INT, оскільки передбачається, що

модель буде задіяна по 1-му або 2-му варіанту (див.

параграф 4.4.2).

FBD секція складається з 5 ланцюгів:

- імітаційна модель роботи танку Т1 та

обв’язаних клапанів;

- імітаційна модель роботи танку Т2 та

обв’язаних клапанів;

- імітаційна модель роботи дозатору D1 та

обв’язаних клапанів;

- імітаційна модель роботи дозатору D2 та обв’язаних клапанів;

- імітаційна модель роботи 3-х ходового клапану переключення подачі дози

на Т1 та Т2;

У центрі перших двох FBD-ланцюгів (рис.5.47) знаходяться по одному

екземпляру DFB типу smTankT, який описаний в параграфі 4.4.6. Ці екземпляри

реалізують імітаційні моделі безпосередньо танків. Параметри Tin (температура

вхідної рідини) та Tain (температура теплоагента на вході кожуха) задані згідно

таблиці 5.1. При необхідності визначення їх, як змінних параметрів (збурення або

управління), ці входи можна вивести в зовнішній інтерфейс блоку, або в глобальні

параметри блоку. У даній задачі параметри були прийнятими константами

навмисно для спрощення моделі.

Значення входів Fin (вхідна витрата рідини), Fout(вихідна витрата рідини)

та Fa(витрата теплоагента) розраховуються по стану відповідних клапанів.

Модель усіх клапанів в програмі реалізовані з використанням екземплярів DFB-

типу smValve, який описаний в параграфі 4.4.10. Вихід клапану Kf (коефіцієнт

витрати, від 0-1) попередньо перемножується на потрібний масштабний

коефіцієнт відповідно до діапазону витрат, заданого в таблиці 5.1. Слід звернути

увагу, що для запірних клапанів значення глобального параметру APOS повинно

бути FALSE, а для регулюючих - TRUE. Усі запірні клапани управляються одним

сигналом – на відкриття, який подається з входу інтерфейсу блоку на вхід

cmdOPN, тому на cmdCLS подається його інверсна копія. Виходи stOPN та stCLS

екземплярів клапанів набору та зливу, подаються на відповідні виходи інтерфейсу

блоку для імітації роботи датчиків кінцевого положення штоку.

Рис.5.46.Секція SET_dt.

248

Ри

с.5

.47

. П

ро

грам

а D

FB

бло

ку

ім

ітац

ійн

ої

мод

елі.

249

Ри

с.5

.48

. П

ро

грам

а D

FB

бло

ку

ім

ітац

ійн

ої

мод

елі

(про

до

вж

енн

я).

250

Робота наступних двох FBD-ланцюгів працює подібним чином (рис.5.48).

У центрі ланцюга використовуються блоки типу smLevelCyl1, який описаний

вище. Конструктивні параметри задаються в дециметрах, а витратні – в літрах.

Клапани набору та зливу мають тільки датчики положення "закритий".

Імітація роботи 3-х ходового клапану заключається тільки в часових

характеристиках спрацювання датчиків кінцевого положення, оскільки зроблені

припущення для моделі дозволяють не враховувати вплив витрати з дозаторів на

об’єм рідини в танках.

Написання програми та її налагодження для перевірки імітаційної

моделі об’єкта. Для перевірки роботи імітаційної моделі необхідно створити

екземпляр DFB блоку, який потім викликати в програмі з прив’язкою до

потрібних фактичних параметрів (рис.5.49). У якості входів можна використати

вихідні змінні або адреси типу %Q та %QW. Виходи не можна безпосередньо

прив’язати до %I та %IW, так як ці адреси доступні тільки для читання. Однак для

запису в ці комірки можна використати функції WRITE_INPUT_EBOOL та

WRITE_INPUT_INT, які описані в параграфі 4.2.3. На рис.5.49 показаний тільки

фрагмент програми, інші виходи використовуються аналогічно.

Ініціалізація моделі проходить по умові %S21=TRUE. %S21 – це системний

біт, який переводиться в TRUE на першому циклі Задачі, і скидується на

наступному циклі (див. параграф 3.4.5). Таким чином для ініціалізації моделі

достатньо перезапустити Задачу в ПЛК (STOP, RUN).

Для періодичного виклику моделі використана зв’язка %S5->%M100->FE->

JUMP. %S5 системний меандр, який змінюється з періодичністю 100 мс. Комірка

Рис.5.49.Фрагмент секції для перевірки моделі.

251

%M100 використана для можливості відлову фронтів. Таким чином по задньому

фронту %M100, тобто кожні 100 мс на один цикл на виході FE буде формуватися

TRUE. Інвертований сигнал на виході FE буде відправляти програму на

виконання по мітці SMOUT (знаходиться нижче блоку імітації, на рис. не

показана) завжди, окрім моменту спрацювання заднього фронту. Таким чином,

блок smObject1 буде викликатися 1 раз в 100 мс а також в момент спрацювання

%S21, тобто на 1-му циклі Задачі.

Один із зручних способів перевірки моделі – це використання

операторського екрану, як наприклад на рис.5.42. Окрім індикаторів датчиків та

елементів управління виконавчими механізмами (кнопок, полів для вводу) можна

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

d_t, який впливає на швидкість імітації. У прикладі до кнопки "х10" прикріплена

команда запису уставки smObject1.d_t:=1.0, що вказує на масштаб часу 1 с.

Враховуючи що фактична періодичність виклику при цьому не змінюється (100

мс), модель буде працювати в 10 раз швидше ніж в реальному часі.

5.8. Приклад використання мови FBD

Завдання. Програма управління танком на FBD.

Створити проект для ПЛК М340, для реалізації програми управління

установкою, що описується наступним

алгоритмом (рис.5.50). Після натискання

кнопки СТАРТ відкривається клапан

набору першого продукту. Після

досягнення середнього рівня клапан 1-го

продукту закривається, відкривається

клапан набору 2-го продукту. Після

спрацювання сигналізатору верхнього

рівня закривається клапан набору 2-го

продукту, відкривається клапан пари на

100% (діапазон виходу 0-100%). Після

досягнення температури 95ºС (діапазон

датчику 0-150ºС), клапан пари

залишається відкритим на 20% ще

протягом 10 с. Після закінчення

витримки, рідина зливається з апарату.

Після відключення сигналізатору нижнього рівня, цикл повторюється у випадку

якщо кнопка СТОП не нажата. Якщо СТОП нажата – клапан зливу закривається.

У ПЛК поступає сигнал від датчика рівня з діапазоном вимірювання 0-5 м.

Написати секцію з програмою імітатору роботи датчика та сигналізаторів

рівня і температури. У окремих секціях написати програму масштабування входів

та виходу. Логіку виконання програми теж реалізувати в окремій секції. Програму

перевірити та налагодити з використанням таблиць анімацій або операторських

екранів. Програми в усіх секціях створити на мові FBD.

Рис.5.50. Приклад операторського

екрану до задачі.

252

Рішення.

Відповідно до поставленої задачі, необхідно 3 дискретні входи, 3 дискретні

виходи, 2 аналогові входи і 1 аналоговий вихід. Один з варіантів вибору апаратної

конфігурації показаний на рис.5.51.

Для прив’язки до входів та виходів можна створити локалізовані змінні, які

показані на рис.5.52.

Враховуючи запропонований в посібнику підхід (див. параграф 4.4.2)

структура програми може мати вигляд як на рис.5.53.

Масштабування аналогових входів проводиться у секції Inputs(рис.5.54) а

виходів – в Outputs(рис.5.55). Для масштабування вхідних параметрів використані

функціональні блоки SCALING (див. параграф 6.6.1). Для задання параметрів

масштабування використовуються змінні типу Para_SCALING (рис.5.56). Вихід на

виконавчий механізм масштабується з використанням множення на коефіцієнт.

секція імітації рівнів та температури

секція масштабування входів

секція логіки програми

секція масштабування виходів

Рис.5.53. Структура програми.

Рис.5.52. Перелік змінних входів/виходів.

Рис.5.51. Конфігурація ПЛК М340 до задачі.

253

Секція з програмою управління показана на рис.5.57. У логіці роботи

програми використаний автоматний підхід, подібний до SFC. Тобто система може

знаходитись в одному із станів, який визначається кроком, що записується в

StepProg. У залежності від значення кроку (від 1 до 5) перевіряються інші умови, і

якщо вони справджуються проводиться певна дія і перехід на інший крок. Для

активації блоку присвоєння MOVE задіяний вхід EN. Мультиплексор MUX,

забезпечує управління виконавчим механізмом клапану пари в залежності від

значення кроку, яке подається на вхід K. Тригери RS призначені для управління

виконавчими механізмами з запірними регулюючими органами.

Рис.5.55. Секція Outputs.

Рис.5.54. Секція Inputs.

Рис.5.56. Змінні для масштабування.

254

Для перевірки роботи програми можна скористатися програмним

імітатором (рис.5.58). Цей імітатор значно простіший ніж запропоновані в главі

4.4, однак для перевірки даної задачі цілком достатній.

Рис.5.57. Секція Program.

255

5.9. Приклад використання мови SFC

Завдання. Програма управління танком

Елементи установки. Створити проект з ПЛК М340, для реалізації програми

управління установкою, що складається з наступних елементів (рис.5.59):

- танки Т1 та Т2, в яких готовляться продукти за різними рецептами; танки

обв’язані наступними засобами КВПіА:

запірні клапани набору та зливу, кожний з датчиками кінцевого

положення "закритий" та "відкритий";

регулюючий клапан (0-100%) подачі теплоагента у теплообмінний

кожух танку (далі по тексту клапан нагрівання);

датчик рівня (0-100%) в танку;

датчик температури в танку (0-100С);

- дозатори (мірні ємності) D1 та D2, які забезпечують подачу дози компоненту;

дозатори обв’язані наступними засобами КВПіА:

сигналізатор нижнього і верхнього рівнів;

запірні клапани набору та зливу, кожний з датчиками кінцевого

положення "закритий";

- 3-ходовий клапан перемикання трубопроводу подачі з дозаторів на танки T1 та

T2; в нормальному стані положення "на Т1"; має датчики кінцевого положення

"Т1" та "Т2".

Рис.5.58. Секція імітації датчиків та сигналізаторів рівня і температури .

256

Опис алгоритму задач управління установкою. Управління дозаторами та

танками повинно бути розв’язане одне від одного (але координоване), оскільки

дозатори можуть бути використані в інших процесах. Дозатори в стані очікування

завжди повинні бути наповнені.

Управління процесом приготування повинно відбуватися за таким

алгоритмом:

1) У початковому стані (старті ПЛК) клапани набору та зливу танків Т1 та Т2

повинні бути закритими. Закритість клапанів контролюється кінцевими

датчиками положення. Після цього система управління приготуванням

продукту переходить в стан готовності.

2) Оператор повинен задати рецепт продукту для приготування в Т1 та Т2.

Рецепт включає наступні поля:

a. кількість доз компоненту з D1;

b. кількість доз компоненту з D2;

c. температуру попереднього нагрівання;

d. час витримки;

3) Після натискання оператором кнопки "Пуск" відкривається клапан набору

танку Т1.

4) Після досягнення рівня 50% паралельно з набором включається дозування

компонентів D1 та D2 відповідно до рецепту.

5) При досягненні рівня 80%, відкривається клапан набору танку Т2.

6) Коли клапан набору Т2 повністю відкрився (по датчику положення

"відкритий"), клапан набору Т1 закривається, і паралельно з

Рис.5.59. Операторський екран для контролю та управління за процесом

приготування продукту

257

приготуванням продукту в Т1 йде наповнення і приготування продукту в

танку Т2.

7) При досягненні рівня 50% в Т2 паралельно з набором включається

дозування компонентів D1 та D2 відповідно до рецепту. Якщо дозатор в

цей час використовується при дозуванні Т1, необхідно дочекатися

закінчення роботи дозаторів.

8) При досягненні рівня 80%, закривається клапан набору танку Т2.

9) Після закриття клапану набору в танку Т1 (в наступних пунктах для Т2

аналогічно) і закінченні дозування, відкривається повністю клапан подачі

теплоагента;

10) Рідина в танках повинна нагрітися до вказаного в рецепті значення, після

чого клапан залишається відкритий на 10% протягом вказаного в рецепті

часу;

11) Після витримки відкривається клапан зливу і рідина зливається з танку;

12) Через 5с після досягнення рівня менше 1% клапан зливу закривається;

13) Коли обидва танки Т1 та Т2 порожні, система переходить в початковий

стан.

У будь який момент часу система повинна мати можливість переходу в

початковий стан.

Рішення.

Апаратна конфігурація та змінні вводу/виводу.

Відповідно до поставленої задачі, необхідно 15 дискретних входів, 9

дискретних виходів, 4 аналогові входи і 2

аналогові виходи. Один з варіантів вибору

апаратної конфігурації показаний на

рис.5.60.

Для прив’язки до входів та виходів

можна створити локалізовані змінні, які

показані на рис.5.61. Також створені 2

змінні: Pusk для запуску процесу, і InitSFC

для можливості переводу системи в

початковий стан.

Загальні принципи роботи

програми. Для реалізації даної задачі використовуються 4-ри секції (рис.5.62):

"D1" і "D2" (на мові SFC) для управління дозаторами, "Production" (на мові SFC)

для управління приготуванням продукту, та "CTRL_SFC" (на мові LD) для

ініціалізації мереж SFC в цих секціях (скидання кроків і перехід на початковий

крок). Секція "Simulation" призначена тільки для імітації об’єкта і є

необов’язковою.

Рис.5.60. Конфігурація ПЛК М340 до

задачі.

258

Управління дозаторами. Дозатори управляються незалежними автоматами

станів, які реалізовані через секції D1та D2. Вони ідентичні по своїй структурі і

відрізняються тільки використовуваними змінними. Для формування завдання

(кількість доз), його запуску та виконання використовуються структурні змінні

Dozator1 та Dozator2 заздалегідь створеного типу Dozator (рис.5.63).

При ініціалізації мережі SFC (рис.5.62) закривається клапан VSliv_D1, та на

один цикл (специфікатор Р) запускається секція Dinit1, де обнулюються поля

START та PV структурної змінної управління дозуванням Dozator1. Коли клапан

зливу закривається, що сигналізується його датчиком кінцевого положення, -

відкривається клапан VNabor_D1. Клапан набору буде до тих пір відкритий, поки

крок D1_Nabor активний (специфікатор N), тобто поки не спрацює сигналізатор

верхнього рівня LSH_D1. Після спрацювання датчика кінцевого положення

закриття клапану набору, програма переходить до кроку D1Ready. На цьому кроці

програма очікує команду дозування Dozator1.START, яка повинна надійти

(змінитися в TRUE) з іншої частини програми.

Рис.5.61. Вхідні, вихідні змінні та змінні управління

259

Процес роботи дозування заключається у відпрацюванні заданої кількості

вивантажень дози, що підраховується змінною-лічильником Dozator1.CV. Тому

при Dozator1.START=TRUE, протягом одного циклу активності D1Sliv

відбувається збільшення значення Dozator1.CV на 1. Крок буде активний а клапан

Vsliv_D1 буде відкритий до тих пір, поки не відключиться сигналізатор нижнього

рівня, що сигналізує про порожність дозатору.

Крок D1VSlvCLS буде активний до тих пір, поки не спрацює датчик

кінцевого положення закриття клапану зливу (VSliv_D1_Cls). На останньому

циклі активності кроку запускається секція D1Count, в якій при досягненні

кількості доз рівній уставці, скидається команда Dozator1.START і обнулюється

Рис.5.62. Структура задачі MAST та Секція "D1" для управління дозатором D1

Dinit1

D1Count

Структура задачі Mast

260

плинне значення лічильника. Слід зазначити, що після останньої вивантаженої

дози, дозатор все одно набирається, що задовольняє умовам задачі.

Управління приготуванням продукту. Секція управління приготуванням

продукту "Production" побудована з використанням макрокроків (рис.5.64). При

ініціалізації мережі SFC проходить закривання всіх клапанів танків Т1 та Т2.

Ініціалізація закінчується при спрацюванні датчиків положення "закрито"

клапанів набору та зливу.

Для одночасності процесів приготування продуктів в танках Т1 та Т2

використане паралельне відгалуження. Кожна з гілок після ініціалізації

переходить в стан готовності (кроки T1Ready та T2Ready):

- для танку Т1 це очікування кнопки Pusk;

- для танку Т2 це закінчення набору Т1, що сигналізується активністю кроку

T1WaitT2 (T1WaitT2.x=TRUE).

Кожна з паралельних гілок ідентичні одна одній, за винятком певних

особливостей, що стосуються координації їх роботи. Тому розглянемо тільки

гілку для управління танком Т1 і особливості гілки Т2. Гілка управління Т1

включає 3 макрокроки, які відповідають за певний етап роботи: T1Nabor – за

набір і дозування, T1Nagrev – за нагрівання і витримку, T1Sliv – за вигрузку

продукту.

Рис.5.63. Структурні типи та змінні проекту

261

Макросекція кроку T1Nabor показана на рис. 5.65. Вхідний крок макросекції

активує відкриття клапану VNabor_T1, специфікатор S вказує на те, що після

деактивації кроку, клапан повинен залишитись відкритим. Після наповнення 50%

Рис.5.64. Секція "Production" для управління виробництвом продукції

ProdInit

262

(умова в секції MidleLT1: LE_T1>=5000) мережа SFC знову ділиться на 2

паралельні гілки: ліва гілка для повного наповнення танку, права – для дозування.

Таке розгалуження дає можливість вчасно закрити клапан набору, навіть

якщо дозування ще не закінчилось.

Після наповнення рівня до 80%, ліва гілка переходить до кроку T1WaitT2,

активність якого (T1WaitT2.x=TRUE) сигналізує гілці управління танком Т2, що

необхідно відкривати клапан набору танку Т2 (рис.5.64, перехід T1WaitT2.x).

Після спрацювання датчика положення "відкрито" клапану набору танку Т2

VNabor_T2_OPN, закривається клапан набору Т1 (R VNabor_T1).

Перший крок правої гілки T1VDtoT1 перемикає 3-х ходовий клапан в

положення дозування в танк Т1 (VDoz_T1toT2=FALSE). Після спрацювання

датчика положення запускається процес дозування шляхом задання кількості доз

для D1 і D2 згідно рецепту, і запуску дозаторів шляхом подання команди START

(див. рис. 5.65).

Після початку дозування, якщо команда закриття на клапан набору

відправлена, тобто коли активні кроки T1VnbCls і T1Dozes, йде вихід з

макросекції.

Рис.5.65. Макросекція "T1Nabor"

StartDozesT1

263

Умовою переходу до макрокроку T1Nagrev (рис.5.64) є спрацювання датчика

кінцевого положення "закрито" клапану набору Т1.

Для Т2, макросекція набору має аналогічну структуру, за винятком

відсутності кроку очікування відкриття сусіднього танку і присутності кроку

очікування закінчення дозування (рис.5.66). Таким чином програма набору танку

Т2 перед дозуванням буде чекати поки дозатор не відпрацює всі замовлені для

нього дози, тобто поки Dozator1.START та Dozator2.START не стануть рівними

FALSE.

Макросекція нагрівання (рис.5.67) починається з відкриття клапану

нагрівання на 100%. Специфікатор Р1 вказує на те, що дія виконається один раз,

при активації кроку. При досягненні заданої в рецепті температури, крок T1Vytrym

отримує маркер. При активації кроку клапан нагрівання прикривається до 10%,

при деактивації (специфікатор Р0), клапан закривається повністю. Сам крок

залишається активним протягом заданого в рецепті часу, тобто поки не спрацює

умова переходу задана в секції DelCompleteT1: T1Vytrym.t>=RecipeT1.Delay, де t –

час активності кроку. Після виходу з макросекції нагрівання, маркер автоматично

переходить до макрокроку вигрузки T1Sliv (див. рис.5.68), так як умова переходу

завжди TRUE.

Рис.5.66. Макросекція "T2Nabor"

264

Макросекція T1Sliv, починається з відкриття клапану зливу (рис.5.70).

При досягненні рівня в танку Т1 менше ніж 1% (100 в діапазоні 0-10000),

активується крок витримки PauseT1, яка потрібна для повного випорожнення

танку. Час затримки досягається за рахунок налаштування мінімального часу

активності кроку Delay=T#5s. Умова переходу TRUE, відразу пропускає маркер на

крок T1VSlivClose, в якому відбувається закриття клапану зливу. Після

спрацювання датчика "закритий" клапану зливу Т1, і активності останнього кроку

в гілці управління Т2 маркер покидає макросекцію, з’єднується з маркером з

паралельної гілки і переходить на крок ініціалізації (рис.5.64) .

Рис.5.68. Макросекція "T1Sliv"

Рис.5.67. Макросекція "T1Nagrev"

265

Секція ініціалізації мереж SFC. Для

запобігання "зависання" маркеру на певному

кроці при нештатній ситуації, в програмі

передбачена секція ініціалізації мереж SFC під

назвою "CTRL_SFC". Секція написана на мові

LD (рис. 5.69) і виконується на кожному циклі

Задачі MAST, незалежно від активності кроків

SFC. При спрацюванні змінної-команди

InitSFC=TRUE (див. на рис.5.59 кнопка

"ІніціалізКроків") через виклики системної

функції INITCHART ініціалізуються всі мережі

SFC секцій Production, D1 та D2:

- при переході InitSFC з FALSE->TRUE

скидає (деактивує) всі кроки;

- при переході InitSFC з TRUE -> FALSE

ініціалізує мережі SFC, тобто активує

початковий крок.

Функція INITCHART розглянута в

параграфі 3.10.7.

Перевірка роботи програми. Для

перевірки роботи програми можна скористатися

секцією імітації, яка описана у главі 5.7.

Рис.5.69. Секція CTRL_SFC для

ініціалізації SFC