В предыдущих статьях мы фрагментарно описали практику автоматного программирования для ПЛК. Здесь мы сведем все в одном месте и кое-что добавим. Ответы на вопросы, которые все же могут возникнуть после прочтения данного материала, можно найти в ранее написанных статьях автора. Перечень базовых статей следующий:
- Автоматное программирование: определение, модель, реализация.
- Вот, как просто! Автоматы в деле. Для ПЛК фирмы DELTA.
- Автоматы в деле. Штабелер. Засады ПЛК.
Задание на проектирование программы
В предшествующей статье мы уже рассматривали штабелер. Здесь будет более сложный его вариант. Это узкое «крыло», которое, находясь в исходном состоянии, с паузой после старта проката подхватывает лист металла и поддерживает его в процессе движения.
После останова проката и отсечения листа оно выполняет «отскок» вперед, освобождая конец листа, который падает на приемное устройство — гидростол. После этого «крыло» возвращается в исходное состояние. Во время этих движений прокат должен быть остановлен.
Часть 5: Язык программирования LD
После исполнения задания (формирования нужного числа листов заданной длины) «крыло» перемещается в заключительную позицию за пределы гидростола. Возврат в исходное состояние происходит после нажатия кнопки «Штабелер». Выполнение самого задания начинается с нажатия кнопки «Прокат», а длина отдельного листа и общее их количество указывается на панели оператора.
После нажатия кнопки «Сброс» (прокат останавливается, переходя в режим паузы) штабелер должен войти в режим паузы. Повторное нажатие кнопки выполняет реальный сброс системы управления. Продолжить прокат, находясь в ситуации паузы, можно с помощью кнопки «Прокат». Штабелер, находясь в режиме «Автомат», может входить в тот же режим паузы, но после формирования текущего листа.
Работа штабелера в режиме системы «Полуавтомат» несколько отличается от работы в режиме «Автомат». В первом случае он останавливается после выполнения проката и ожидает срабатывания гильотины (в режиме «Полуавтомат» она запускается вручную). Дождавшись, он сбрасывает лист и перемещается в заключительную позицию. Из нее нажатием кнопки Штабелер «крыло» возвращается в исходное состояние. В режиме «Автомат» перемещение в заключительную позицию происходит только после выполнения задания.
Алгоритм управления штабелером в форме двух взаимодействующих конечных автоматов (КА) представлен на рис. 1. Более простой автомат представляет алгоритм работы с датчиками, другой — алгоритм управления штабелером. Реакцию на сигнал паузы, на кнопку «Штабелер», а также на сигнал запуска реализуется обычными средствами языка LD и вынесено за рамки нашего обсуждения.
Процесс создания модели программы
Программирование начинается с модели программы. В нашем случае это будет модель в форме конечного автомата. Ее (модель) можно «держать в голове», рисовать на листе бумаги, но настоятельный совет – используйте графический редактор. У нас это редактор Microsoft Office Visio. Он обладает всем, что помогает нарисовать граф, подобный графу автомата на рис.
Пример создания программы предпусковой сигнализации для ПЛК в CodeSys на языках LD и CFC
1. Причем, чем сложнее автомат, тем больше выгоды будет от его применения. Далее, например, путем обычного копирования элементов имеющегося графа можно создавать графы уже любой сложности.
В нашем случае от графического редактора нужно не так уж много. Рисовать, во-первых, состояния в форме кружков с пометками внутри – именами состояний (у нас это будут только номера). Во-вторых, соединять состояния направленными дугами и помечать их условиями переходов и выдаваемых сигналов. Кроме этого, Visio позволяет легко изменять вид графа, перемещая вершины, что ведет к автоматическим изменениям соединяющих их дуг.
Вершинам графа можно поставить в соответствие то или иное действие, ассоциировать с ним некую предысторию работы алгоритма и т.д. и т.п. Например (см. рис.1), вершина 0 – это начальное состояние алгоритма. Вершина с номером 33 – состояние ошибки. В состоянии 1 выдаются сигналы управления движением крыла. В состоянии 4 – лист сброшен и выполняется «отскок», при котором крыло попадает в состояние 2. Из него модель может продолжить работу или, выполнив задание, перейти в состояние 44 и т.д. и т.п.
Фактически каждое состояние алгоритма имеет тот или ной смысл, а потому, наблюдая за ними (а мы такую уникальную возможность имеем!), можно понять, что происходит с алгоритмом в любой момент времени. Возможность наблюдения за состояниями превращает тестируемый алгоритм из «черного ящика» в «белый ящик».
Автоматная модель позволяет объективно оценить сложность будущей программы. Она зависит от числа состояний автомата, количества входных/выходных каналов, связности графа, т.е. множества и разнообразия переходов, и сложности предикатов и действий. Предикаты и действия в случае ПЛК достаточно просты. Обычно это: прочитать вход ПЛК в случае предиката и/или установить выходной сигнал в случае действия. А вот логика алгоритма, особенно при взаимодействии с другими функциональными блоками, способна доставить массу хлопот.
Так что программирование для ПЛК не столь уж простое, как это может показаться на первый взгляд.
Процесс кодирования
Создав модель, мы переходим к ее реализации. Перейдя в дерево проекта, в папке функциональных блоков (ФБ), создаем заготовку — функциональный блок. Он должна иметь элементы, соответствующие конструкции автомата на языке LD. Как минимум, это два входа и один выход. Входные каналы – это канал сигнала сброса и канал с присвоенным автомату элементом массива текущих состояний автомата.
Выходной канал – элемент массива теневых состояний с индексом равным индексу текущих состояний.
Код вызова ФБ для штабелера представлен на рис. 2. Данный функциональный блок имеет описанные выше каналы. Остальные каналы задаются локальными переменными соответствующего типа. Так, переменные типа VAR_INPUT создают входные каналы, VAR_OUTPUT – выходные, VAR_IN_OUT – совмещенные входные/выходные каналы, а тип VAR – это обычные локальные переменные.
Рис.3 дает полное представление о локальных переменных. Переменные с именами bClear, inState, outState соответствуют упомянутым выше каналам. На рис. 4 приведен код инициализации ФБ и код работы с таймерами. Инициализация при включении ПЛК и/или получении сигнала сброса устанавливает автомат в начальное состояние.
Создав заготовку, можно приступить к кодированию автомата. Код каждого перехода автомата имеет единый вид: сначала идет проверка текущего состояния автомата и входных условий, затем, если это необходимо (для автоматов Мили), — выполнение действий и в завершение изменение текущего состояния. Если текущее состояние не изменяется, то последнюю операцию можно опустить. Образец кодирования переходов, исходящих из начального состояния 0 (см. рис.1) дан на рис. 5.
Реверс-инжиниринг
Не секрет, что программисты не любят документировать программы. От этого часто страдают они же сами, т.к. часто спустя уже какое-то время даже сам автор программы с трудом может разобраться в своем творении. Но, даже понимая это, рисование блок-схем, графов, детальное описание алгоритма и т.п. – это не про программистов. Достаточно кратко, весьма ярко и доходчиво процесс документирования программ описан в статье [1]. Полемизируя с ней, можно утверждать, что в рамках технологии автоматного программирования программы все же обладают свойством самодокументирования и это совсем не чушь.
Безусловно, разобраться с алгоритмом программы по ее коду весьма проблематично. На рис. 6 приведен код программы, созданный для модели на рис.1, в режиме просмотра для последующей распечатки. Это восемь убористо заполненных листов на языке LD. Сравните его с графом автомата.
Что из них нагляднее и понятнее, думаю, вопрос риторический.
Но, с другой стороны, зная принцип кодирования автоматной программы, вы можете по коду программы легко восстановить граф автомата. Так, во-первых, сразу ясно, сколько состояний имеет программа. Во-вторых, легко восстановить переходы между состояниями, т.к. каждой цепи соответствует, как правило, ровно один переход, а действия программы привязаны или к состояниям программы, или представлены на соответствующих переходах. Останется только добавить смысловую интерпретацию условий и действий, в чем может помочь уже комментарий. Конечно, если их нет (совсем уж, видимо, «гениальный» программист создавал программу или комментарии просто не доступны), то придется все интерпретировать самому.
Тестирование программы
Тестирование, наверное, самый важный этап во всем процессе разработки программы. Программа, работающая с ошибками, ни кому не нужна, будь она трижды автоматной или какой-то там еще. Но автоматы и здесь предоставляют возможность, которой нет у программ, спроектированных обычным способом. Только автоматная программа позволяет автоматически отслеживать текущее состояние программы. А это может сказать о многом, т.к. отражает поведение программы в динамике.
Конечно, в программу можно ввести флаги, отражающие ее поведение. Но, во-первых, флаги нужно придумать, правильно расставить и предусмотреть код для их установки и сброса. Т.е. то, что на уровне автомата формируется естественным образом, в случае использования флагов требует определенных усилий и сосредоточенности. В конце концов, использование флагов просто ненадежно, за что их не критиковал разве что только ленивый.
Но у ПЛК есть одна неприятная особенность – отсутствие пошаговой отладки. Присуще ли это только ПЛК фирмы DELTA или и другим – не знаю, но в данном случае, как говорится, что есть, то есть. Для программистов, привыкших к возможностям современных отладчиков, это будет, скорее всего, если не шоком, то определенной «новостью» (как это было для автора). Но и здесь состояния автомата более чем кстати.
Рис. 7 демонстрирует процесс отладки. Из него следует: штабелер находится в состоянии 1 и идет процесс проката, т.к. флаг проката bЕслиПрокат = true. «Крыло» находится в движении, о чем говорят установленные сигналы управления двигателем – Y20 и Y22. При этом оно явно сошло с исходной позиции, т.к. awState[47] = 2 (см. автомат датчиков на рис.1).
Режим работы выбран автоматический – bM10M11 = true, т.е. это режим «Полуавтомат» или «Автомат». Нам остается только крутить энкодер и отслеживать состояние проката на панели оператора, где отображается текущая длина листа в поле «Исполнено» (см. рис.8).
Существует просто огромный пласт информации, обсуждающий этапы проектирования программ (см., например, [2]). Но среди этой информации мало такой, которая бы за базу брала модель программы. А от нее зависит многое, если не все. В основе технологии автоматного программирования лежит сетевая конечно-автоматная алгоритмическая модель.
Это позволяет охватить и параллельные процессы, без которых современное проектирование просто немыслимо. И если обычное программирование только-только осваивает параллелизм, то в ПЛК в той или иной мере его используют давно. Здесь он может быть представлен модулями POU, которые содержать разнообразные функциональные блоки, работающие параллельно.
Но параллельно работающие ФБ, взаимодействуя друг с другом, порождают достаточно сложные процессы, поведение которых необходимо анализировать. Анализ этого — весьма сложная и трудоемкая задача. Для модели штабелера это еще выполнимо и сводится к построению для сети из двух автоматов эквивалентного однокомпонентного автомата. Это будет автомат, имеющий 27 состояний. Уже одно их количество (а, ведь, нужно еще найти все переходы между состояниями) способно подавить любое желание строить подобные планы.
Поэтому дальнейший анализ на уровне параллельных процессов, как правило, делается на основании интуитивных предположений. Например, если нет сомнений в правильности созданных автоматов, то не так уж много причин беспокоиться и по поводу их совместной работы. Хотя в этом случае только полноценное тестирование способно рассеять все сомнения на этот счет.
И все же основной вывод, к которому пришел лично я, как программист, уже довольно давно: только следование технологии — необходимая основа качественного программирования. Нынешнее программирование, если и является, как принято считать, искусством, то искусством кустарным. Все в нем сделано как-то — «на коленке». Чтобы искусство превратилось в мастерство, нужна технология, опирающаяся на теорию. Я выбрал и выбираю автоматную технологию, которую описал в своих статьях.
Если бы была технология, которой бы я доверял больше, чем своим автоматам, то я бы использовал ее. И, казалось бы, есть из чего выбирать. Тот же UML или Simulink, на память приходят автоматы в Qt, SWITCH- технология, в конце концов, и т.д. и т.п. Но на поверку оказывается, что это или вовсе не автоматы, а только их названия, или весьма ограниченные версии автоматов.
Поэтому я выбираю те автоматы, где . правильно работает модель RS-триггера. Почему он? Потому что объективные доказательства правильности его работы доказывают корректность параллельных свойств среды исполнения параллельных процессов. Ведь, все так просто!
Ну, вы понимаете о чем я. Лично у меня-то выбора уже нет, а у вас . на одну испытанную технологию больше. Везет же! Но только кому.
Источник: habr.com
Язык релейных диаграмм LD (Тема)
Язык LD представляет собой графическую интерпретацию процесса разработки релейно-контактных схем управления. Первоначально на языке LD программировались контроллеры производства компании Allen Bradley . Ввиду его удобства и значительного количества пользователей, обладающих навыками проектирования логических систем на базе реле и контакторов, язык LD был введен в стандарт IEC 61131-3 и в настоящее время является одним из наиболее распространенных языков программирования ПЛК. Этот язык наиболее удобен для программирования небольших задач дискретной логики, поэтому многие контроллеры младших классов имеют язык LD в качестве основного для разработки программ управления.
Программы, написанные на языке LD , состоят из последовательности ступеней, которые выполняются ПЛК последовательно, слева направо.
Ступень состоит из набора графических элементов, ограниченных слева и справа условными шинами питания.
Набор графических элементов языка LD включает:
1) Входы/выходы ПЛК (кнопки, датчики, реле, индикаторные лампы и т.д.);
2) Стандартные управляющие системные функции (таймеры, счетчики и т.д.);
3) Арифметические, логические и специальные операции;
4) Внутренние переменные ПЛК.
Рис. Пример программы на языке LD
Дискретные входы ПЛК и результаты выполнения логических операций представляются в виде условных контактов реле, нормально разомкнутых (замыкаются при появлении сигнала на соответствующем входе или истинности поставленного в соответствие данному контакту логического выражения) и нормально замкнутых (с логикой работы, обратной предыдущей). Дискретные выходы ПЛК или результаты выполнения данной ступени представляются в виде обмотки реле, питание на которой появляется после прохождения сигнала от левой условной шины питания через все находящиеся на ступени элементы. Левая шина соответствует исходному питанию схемы, правая – выходу схемы, сигнал в котором появляется после замыкания всех контактов и выполнения всех логических условий.
Графические элементы языка LD можно условно разделить на базовые элементы, функциональные и операционные блоки. Каждый базовый элемент занимает одну ячейку (одну строку по высоте и одну колонку по ширине). Блоки могут занимать несколько ячеек. Базовые элементы и блоки языка LD приведены далее.
Таблица. Базовые элементы и блоки языка LD
Нормально откры тый контакт
Контакт замкнут, когда битовая переменная, которая управляет им, равна 1
Нормально закры тый контакт
Контакт замкнут, когда битовая переменная, которая управляет им, равна 0
Контакты, срабатывающие по перепаду
Возрастающий перепад: контакт замкнут, когда битовая перемен ная, которая управляет им, изменяется с 0 до 1
Убывающий перепад: контакт за мкнут, когда битовая переменная, которая управляет им, изменяет ся с 1 до 0
Используются для соединения элементов условий и элементов действия, расположенных после довательно между двумя шинами питания
Вертикальные свя зи
Используются для параллельного соединения элементов действия и условий
Используются для соединения дву х объектов, использующих разные связи
Устанавливает соответствующий битовый объект в значение, рав ное результату, полученному в проверочной зоне
Устанавливает соответствующий битовый объект в значение, рав ное инверсии от результата, полученного в проверочной
Устанавливает соответствующий битовый объект в 1, когда резуль тат, полученный в проверочной зоне, равен 0
Сбрасывает соответствующий би товый объект в 0, если результат, полученный в проверочной зоне, равен 1
Условный переход к другой ступени
Обеспечивает соединение с поме ченной строкой, причем послед няя может быть расположена до или после текущей ступени
Обмотка вызова подпрограммы
Позволяет подсоединиться к подпрограмме, если результат, полу ченный в проверочной зоне, ра вен 1
Возврат из
подпрограммы
Зарезервировано для подпро грамм, позволяет возвращаться в вызывающий модуль, когда результат, полученный в прове рочной зоне, равен 1
Останов выполнения программы, когда результат, полученный в проверочной зоне, равен 1
Блоки:
Таймер
Счетчик
Одновибратор
Регистр
Контроллер
барабана
Каждый из блоков стандарт ной функции использует вхо ды/выходы, через которые обес печиваются связи с другими гра фическими элементами
Вертикальный блок сравнения
Позволяет сравнивать два операнда. В зависимости от результа та соответствующий вход прини мает значение, равное 1. Размер: 2 колонки/4 строки
Горизонтальный блок сравнения «Compare»
Позволяет сравнивать два операнда. Выход принимает значение, равное 1, если при сравнении получен истинный результат. (Блок может содержать до 4096 символов). Размер: 2 колонки/1 строка
Операционный блок «Operate»
Выполняет арифметические, логические и другие операции и использует синтаксис языка структурированного текста. (Блок может содержать до 4096 символов). Размер: 4 колонки/1строка
Ступень содержит до 7-ми строк и до 11-ти колонок, разделенных на две зоны – проверочную и зону действий. Каждая ступень может быть снабжена меткой и озаглавлена комментарием. Метки могут быть использованы для идентификации ступени внутри программного объекта (головной программы, подпрограммы и т.д.), но не являются обязательными.
Метки имеют синтаксис % Li (где i от 0 до 999) и располагаются в левом верхнем углу перед шиной питания. Каждая метка может присваиваться только одной ступени в пределах данного программного объекта. Система сканирует ступени в том порядке, как они были введены, независимо от порядка нумерации меток.
В состав ступени может быть введен комментарий, содержащий до 222 алфавитно-цифровых символов и обрамленный с обоих концов символами (*и*). Это упрощает интерпретацию ступени. Введение комментария не является обязательным. Комментарий запоминается в ПЛК и в любой момент может быть вызван пользователем. Следует учитывать, что комментарии используют память программ.
Ступень изображается в форме, похожей на релейные диаграммы. Простейшие проверочные элементы и элементы действия занимают одну строку и одну колонку ступени. Все линии контактов начинаются от левой шины питания и должны заканчиваться на правой шине питания. Проверочные операции всегда располагаются в колонках с 1 по 10. Операции действия всегда располагаются в колонке 11.
Предполагается, что между шинами питания протекает ток, который имеет следующее направление:
– по горизонтальным связям – слева направо;
– по вертикальным связям – в обоих направлениях.
Проверочная зона содержит: контакты, которые могут быть помечены любым, ранее определенным битовым объектом; функциональные блоки; блоки сравнения. Возрастающие и убывающие фронты могут быть связаны только входными и выходными битовыми объектами и внутренними битами.
Зона действий содержит: прямые, инверсные, фиксирующие и инверсно-фиксирующие обмотки, которые могут быть помечены любым битовым объектом; записанные пользователем операционные блоки; другие элементы действия ( Call , Jump , Halt , Return ).
На одной линии возможно до 10-ти контактов. В одной колонке максимально может параллельно проверяться до 7-ми контактов. До 7-ми обмоток могут быть включены параллельно. Ступень может быть разделена на несколько независимых линий контактов, причем каждая линия управляет независимой обмоткой.
Операционные блоки всегда расположены в зоне действий. Внутри блока записывается фраза на языке ST . Операционный блок должен быть присоединен непосредственно к правой «шине» питания.
Ступени исполняются последовательно друг за другом; каждая ступень исполняется слева направо. В тех случаях, когда встречается вертикальная связь, выполняется подступень, соответствующая этой связи, и только после этого возобновляется исполнение оставшейся части ступени.
В соответствии с указанным порядком исполнения система:
1) Оценивает логическое состояние каждого контакта, соответствующее текущему значению внутренних переменных объекта управления, или состояние входов модулей ввода/вывода ПЛК, считываемых в начале сканирования;
2) Выполняет рабочие действия, соответствующие функциям, функциональным блокам и подпрограммам;
3) Обеспечивает битовые объекты, соответствующие обмоткам (выходы модулей ввода/вывода обновляются в конце сканирования);
4) Переходит к другой помеченной ступени в данном программном модуле (переходы к другой ступени >>%Li), возвращается в вызывающий модуль или останавливает программу .
Источник: mc-plc.ru
Примеры программ на ld
Структурированный текст, ST
Язык ST является текстовым языком высокого уровня и очень сильно напоминает Паскаль:
Листинг 2. Пример программы на языке ST
IF Voltage>220 THEN
Current:=Current — 10; (*Если V>220 В, то уменьшить ток на 10*)
Current:=50; Speed:= ON;(*Установить ток 50А и включить мотор*)
Язык ST имеет много отличий от языка Паскаль и разработан специально для программирования ПЛК. Он содержит множество конструкций для присвоения значений переменным, для вызова функций и функциональных блоков, для написания выражений условных переходов, выбора операторов, для построения итерационных процессов.
Этот язык предназначен в основном для выполнения сложных математических вычислений, описания сложных функций, функциональных блоков и программ.
Язык релейно-контактных схем, LD
Графический язык релейной логики впервые появился в виде электрических схем, которые состояли из контактов и обмоток электромагнитных реле (Рис. 1).
Рис. 1. Пример программы на языке LD (слева) и ее эквивалент в виде электрической цепи с реле и выключателями (справа)
Такие схемы использовались в автоматике конвейеров для сборки автомобилей до эры микропроцессоров.
Язык релейной логики был интуитивно понятен людям, слегка знакомым с электротехникой и поэтому оказался наиболее распространенным в промышленной автоматике. Обслуживающий персонал легко находил отказ в оборудовании, прослеживая путь сигнала по релейной диаграмме.
Однако язык LD проблематично использовать для реализации сложных алгоритмов, поскольку он не поддерживает подпрограммы, функции, инкапсуляцию и другие средства структурирования программ с целью повышения качества программирования. Эти недостатки затрудняют многократное использование программных компонентов, что делает программу длинной и сложной для обслуживания.
Инкапсуляция (от лат. in capsule — в оболочке) — это заключение данных и функционала в оболочку. В объектно-ориентированном программировании в роли оболочки выступают классы: они не только собирают переменные и методы в одном месте, но и защищают их от вмешательства извне.
Для выполнения арифметических функций в язык LD были добавлены функциональные блоки, которые выполняли операции сложения, умножения, вычисления среднего и т.д.
Сложные вычисления в этом языке невозможны. Недостатком является также то, что только маленькая часть программы умещается на мониторе компьютера или панели оператора при программировании.
Несмотря на указанные недостатки, язык LD относится к наиболее распространенным в мире, хотя используется для программирования только простых задач.
Диаграммы функциональных блоков, FBD
FBD является графическим языком и наиболее удобен для программирования процессов прохождения сигналов через функциональные блоки.
Язык FBD удобен для схемотехников, которые легко могут составить электрическую схему системы управления на «жесткой логике», но не имеют опыта программирования.
Функциональные блоки представляют собой фрагменты программ, написанных на IL, SFC или других языках, которые могут быть многократно использованы в разных частях программы и которым соответствует графическое изображение, принятое при разработке функциональных схем электронных устройств, см. Рис. 2.
Рис. 2. Пример программы на языке FBD
Язык FBD может быть использован для программирования функций, функциональных блоков и программ, а также для описания шагов и переходов в языке SFC. Функциональные блоки инкапсулируют данные и методы, чем напоминают объектно-ориентированные языки программирования, но не поддерживают наследование и полиморфизм.
Все то, что во время компиляции или исполнения программы может содержать или обрабатывать значения различных типов — является полиморфным, например:
- переменные, меняющие свое значение на значение другого типа
- объекты, обладающие свойствами, которые могут менять значение текущего типа на значение другого типа
- функции, принимающие аргументы различных типов
Но пожалуй, самое лаконичное определение полиморфизма, можно найти в книге Бенджамина Пирса «Типы в языках программирования»: Термин «полиморфизм» обозначает семейство различных механизмов, позволяющих использовать один и тот же участок программы с различными типами в различных контекстах.
Под контекстом, грубо говоря, понимается набор всех доступных переменных в текущем участке программы.
Типичным применением языка FBD является описание «жесткой логики» и замкнутых контуров систем управления.
Язык функциональных блоков является удобным также для создания и пополнения библиотеки типовых функциональных блоков, которую можно многократно использовать при программировании задач промышленной автоматизации.
К типовым блокам относятся блок таймера, ПИД-регулятора, триггера, генератора импульсов, фильтра, и т. п.
Последовательные функциональные схемы, SFC
SFC называют языком программирования, хотя по сути это не язык, а вспомогательное средство для структурирования программ.
Он предназначен специально для программирования последовательности выполнения действий системой управления, когда эти действия должны быть выполнены в заданные моменты времени или при наступлении некоторых событий. В его основе лежит представление системы управления с помощью понятий состояний и переходов между ними.
Язык SFC предназначен для описания системы управления на самом верхнем уровне абстракции, например, в терминах «Старт», «Наполнение автоклава», «Выполнение этапа № 1», «Выполнение этапа № 2», «Выгрузка из автоклава».
Язык SFC может быть использован также для программирования отдельных функциональных блоков, если алгоритм их работы естественным образом описывается с помощью понятий состояний и переходов.
Например, алгоритм автоматического соединения модема с коммутируемой линией описывается состояниями «Включение», «Обнаружение тона», «Набор номер», «Идентификация сигнала» и переходами «Если длинный — то ждать 20 сек», «Если короткий — перейти в состояние «Набор Номера» и т.д.
Источник: finestart.school