Инициализация каскада

Другое использование параметров BKCAL – инициализация каскадных блоков (см. раздел Основы использования каскадов). Это случается при замыкании каскадного контура (например, когда блоки переходят из Ручного режима в Авто или Кас режим). Самый простой случай управляющего каскада – это когда блок ПИД связан с вторичным блоком аналогового выхода. Обмен, происходящий между блоками во время такого процесса, проиллюстрирован на приведенных ниже диаграммах.

1. Начало – оба блока находятся в режиме Ручной, являющемся Требуемым режимом.

Блоки в режиме РУЧ, являющимся Требуемым режимом.

На шаге 1 каскад разомкнут, то есть, нет автоматического управления. Оба блока имеют требуемый режим Ручной. Учтите, что блок ПИД1 имеет текущий режим ИРуч, поскольку он “чувствует”, что имеется еще и подчиненный последующий блок, и этот блок посылает первичному блоку статус Not Invited через связь BKCAL. Not Invited сообщает первичному блоку, что вторичный блок находится не в Каскадном режиме. Поэтому, каскад незамкнут и первичный блок не может работать как регулятор. Кроме того, вторичный блок посылает информацию о статусе через свой параметр BKCAL_OUT. Это происходит потому, что статус, поступающий через параметр CAS_IN – НормаКаскад, а не НормаНе-Каскад. Если статус CAS_IN был бы НормаНеКаскад, то вторичный блок сделал бы вывод, что первичный блок не является частью управляющего каскада.

Замкните каскад, во-первых, переведя вторичный блок в режим Каскад. Установите требуемый режим для AO1 в Кас. Это приведет к двум результатам: текущий режим блока AO перейдет в Авто, и AO1/BKCAL_OUT пошлет запрос инициализации предыдущему блоку, информируя его о том, что последующий блок пытается перейти в режим Каскад. Это показано на шаге 2.

1. Установите требуемый режим для последующего блока в Кас.

Требуемый режим последующего блока установлен в Кас.

1. Предыдущий блок инициализируется и информирует последующий блок о том, что произошла инициализация.

Инициализация Предыдущего Блока и Информирование Последующего Блока.

На шаге 3, первичный блок получил запрос инициализации и инициализировался, то есть, установил SP для безударного перехода. Затем, первичный блок дает знать вторичному блоку, что он получил запрос инициализации и успешно провел ее. Этот процесс – Подтверждения Инициализации – осуществляется посылкой через параметр OUT первичного блока. Если в первичном блоке что-нибудь было не в порядке (например, было включено отслеживание или статус входа был Плохой), он не смог бы инициализироваться и каскад не был бы замкнут. AO1 остался бы в режиме Кас/Авто, выполняя свой алгоритм с использованием внутреннего задания блока.

1. Последующий блок переходит в режим Кас и оповещает предыдущий блок об этом изменении.

Последующий блок переходит в режим Кас и оповещает предыдущий блок.

После того, как подчиненный блок получит сигнал Подтверждения Инициализации от первичного блока, его текущий режим становится Кас (шаг 4). На этом каскад замыкается. Подчиненный блок выполняет свой алгоритм, используя задание SP, полученное от первичного блока. В этот момент, каскад замкнут, но нет автоматического регулирования. Первичный ПИД блок все еще находится в режиме Руч.

1. Предыдущий блок переводится в режим Авто.

Последующий Блок переводится в Режим Авто.

Шаг 5 представляет полностью автоматический каскад. Требуемый режим первичного регулятора установлен в Авто. Поскольку PID1/BKCAL_IN имеет статус, отличный от Не Затребовано (т.к. вторичный блок в режиме Кас), ПИД блоку разрешено перейти в режим Авто. Учтите, что, если пользователь установил требуемый режим PID1 в Авто на шаге 1, то блок останется в режиме Авто/ИРуч, т.к. статус Не Затребовано получен по BKCAL_IN.