Язык программирования контроллеров

ПЛК — что это такое?

Доброго времени суток, уважаемые жители Хабра!
Прочитав пост про программирование ПЛК Siemens серии S7, я залез в поиск по Хабру, и был весьма удивлен, что тема промышленной автоматики вообще, и программирования ПЛК в частности, освещена весьма и весьма скудно. Возьму на себя смелость поделиться своим опытом в данной области, описав базовые принципы программирования ПЛК, в частности, производства компании Beckhoff.

Введение

Я занимаюсь автоматизацией зданий. Сложилось так, что в основном мы строим свои системы на базе ПЛК Beckhoff. Такой выбор был сделан прежде всего потому, что эти контроллеры являются свободно-программируемыми в полном смысле этих слов. Что это значит? Возьмите контроллер TAC Xenta, например, и попробуйте на нем реализовать обмен с внешним устройством через RS232 по собственному протоколу, на уровне «байт послал — байт принял». Не получится, эти контроллеры так не умеют — используйте только те протоколы, которые в них заложил разработчик. А Beckhoff умеет. Но прежде чем лезть в такие дебри, давайте посмотрим на среду разработки? На каком, собственно, языке, мы будем писать?

Стандарт МЭК 61131-3

Промышленные ПЛК программируются на языках стандарта МЭК 61131-3. Всего этих языков 5, некоторые производители добавляют свои. Языки друг на друга совсем не похожи, и, наблюдая за коллегами, могу предположить, что выбор того или иного языка связан прежде всего с тем, чем человек занимался до того, как он пришел в эту отрасль.

  1. IL, instruction list, список инструкций. Похож на ассемблер. Не видел никого, кто его использовал бы, но подозреваю, что олдскульные кодеры, пробивавшие перфокарты по памяти, оценят.
  2. LD, ladder diagram. Визуальный язык, для тех, кто занимался разработкой схем релейной автоматики.
  3. ST, structured text. Более всего напоминает «классические» языки программирования, чем-то похож на Паскаль. Оттого ценится теми, кто до ПЛК занимался программированием на других языках и платформах, в частности — мной.
  4. FBD, functional block diagram. Этакая блок схема, любим прежде всего технологами, решившими податься в программирование, за свою наглядность.
  5. SFC, sequential function chart. Графический язык, больше ничего не скажу. Ни разу не видел, чтоб его использовали.

Из не всеми поддерживаемых языков стоит отметить язык CFC (continuous flow chart), Beckhoff его поддерживает. Это дальнейшее развитие языка FBD, одним из наиболее существенных отличий, на мой взгляд, является поддержка явной обратной связи в схемах. Зачем это нужно? Например, вот такой генератор коротких импульсов на CFC будет работать, а на FBD – нет.

Блок TON — это стандартный блок, таймер с задержкой включения. Логика работы: выход Q становится TRUE, когда на входе IN сигнал TRUE в течение не менее времени PT.
Самая популярная, наверное, среда разработки под ПЛК — это CoDeSys. Многие производители берут ее за основу, и либо делают к ней библиотеку для работы со своим ПЛК, либо доделывают среду под себя.

Как работает ПЛК?

Программа ПЛК работает циклично. Время цикла может быть от единиц миллисекунд до единиц секунд, в зависимости от задач, которые на этот ПЛК возложены. Большинство ПЛК позволяют задавать время цикла разработчику программы, однако в некоторых моделях такой возможности нет. Многие ПЛК, в частности Beckhoff, позволяют в одной программе создать более одной циклически выполняемой задачи, и задать приоритет для этих задач. Что нам дает эта возможность?

Представим ситуацию: ПЛК управляет вентиляционной установкой, и к нему подключена панель управления через RS232. Температура в помещениях меняется не быстро, и запускать алгоритм управления вентиляцией чаще, чем раз в 50 — 100 мс просто нет смысла. Зато панель оператора опрашивает контроллер постоянно, и задержка ответа ПЛК более 10 мс уже выражается в «притормаживании» интерфейса пользователя, а при задержке 20 мс у нас переполнится аппаратный буфер COM-порта. Наличие нескольких задач позволяет нам решить эту проблему красиво: пусть «быстрая» задача работает с COM-портом, и вызывается каждые 2 мс, а «медленная» реализует логику работы вентиляции, и вызывается каждые 50 мс. Все работает хорошо, панель оператора не тормозит, пользователь доволен.

А что у этих железок внутри?

Тут все очень и очень зависит от производителя. Кто-то делает свою embedded-платформу на RISC-процессоре (например, отечественный «Овен») — этот подход очень популярен. Beckhoff же пошли по другому пути — на их ПЛК установлена Windows CE 5.0 (а если обновить с официального сайта прошивку — то 6.0), или же Windows XP Embedded, а PLC-задача работает как служба. Достаточно интересный контраргумент для любителей рассказывать о нестабильности Windows.
Но это «голова» контроллера, а ведь ему еще нужны входы и выходы, чтобы общаться с внешним миром. Тут есть два подхода:

  1. Можно сделать «все в одной коробке» — голова, некий набор входов / выходов, несколько вариантов конфигурации — вот тут у нас входов побольше, тут поменьше, тут голова помощнее, тут послабее. Так делают, например, Carel, и много кто еще. На маленьком проекте такой подход себя в чем-то, может быть, и оправдывает.
  2. Но лично мне кажется, что большую гибкость дает другой подход. Голова отдельно, и к ней по шине подключается наборный «хвост» из модулей ввода-вывода. Мы ставим те модули, которые нам нужны, и в том количестве, которые нам нужно. Так делают Beckhoff и Siemens, например.


Вот так выглядит внешне подход «все в одной коробке». На фото Carel pCO3.

А вот другой вариант — голова Beckhoff серии CX9000 (слева на фото) с набором модулей ввода-вывода.
Помимо всего прочего, на голове еще имеется некая шина, позволяющая объединять ПЛК в сеть, а зачастую еще и менять его программу через эту же сеть. Какая это будет сеть — зависит от ПЛК. Это могут быть и незнакомые тем, кто не сталкивался с промышленными сетями EIA-485, Profibus, CAN, а может быть и вполне привычный Ethernet. Именно через эту сеть, называемую fieldbus, и осуществляется подключение ПЛК к верхнему уровню — к СКАДА-системе, например. На фото выше хорошо видны 2 разъема 8P8C на голове Beckhoff’а — это Ethernet, а у Carel сверху слева видны (плоховато, правда) 2 разъема 6P4C — так они сделали RS-485. У этого интерфейса, к сожалению, нет общепринятого разъема.

Так все же, как под него программы писать-то?

Вообще, это тема не статьи, а целой книги. Но расскажу то, что увидел на личном опыте, и пусть это будет ложкой дегтя.
Для профессиональных программистов освоение ПЛК во многом покажется деградацией. ООП? Их нет у нас, есть только структуры, перечисления, и некое подобие класса, которое называется «функциональный блок». Что такое Private, Public и прочее, тоже можно забыть сразу — не пригодится. Из любого места вашей программы можно получить доступ к любому другому месту.

Динамическое выделение памяти? Их нет у нас совсем. Не уверен, сколько тебе пришлют данных? Выделяй буфер с запасом, и забудь про эту память — освободить ее не получится. Либо проявляй чудеса скорости и обрабатывай данные на лету, если успеешь уложиться в заданное время цикла.
Исключения? Да что вы… видел я одно чудо, которое намертво висло при выполнении конструкции вида:
foo, bar: int; baz: real; foo := 2000; bar := 2000; baz := INT_TO_REAL (foo * bar);
Понятно, что переполнение, не влазит foo * bar в 16 бит, но зачем же виснуть-то? Да еще так, что ничего, кроме сброса по питанию не помогает.
Среда разработки? Не у всех CoDeSys, многим хочется пооригинальничать и написать что-нить свое. Одна из таких самописных сред вылетала с runtime error при попытке записать число 86400 в 16-битный INT. А вы говорите, обработка исключений на ПЛК. Ее и в среде разработки-то не всегда нормально могут сделать.
НО! Зато для любителей той тонкой грани, которая отделяет железо от программного обеспечения, софта в просторечии — это очень интересная ветвь ай-ти, правда.
Надеюсь, что этот небольшой обзор будет полезен. Если хабрасообществу будет интересна эта тема, то расскажу про ПЛК подробнее.

Контролер – это управляющее устройство. Действительно функциональным он становится только тогда, когда вы создаете и запускаете программу по его использованию.

Отсюда вытекает главная задача программируемого логического контролера – исполнение программы, которая осуществляет руководство технологического процесса.

Какой набор программ доступен для ПЛК? В принципе любой набор возможен. Главное, чтобы размер свободных ресурсов, данного инструмента, вам был не помехой. Разработчик получает широкие возможности по написанию программ.

Что же необходимо, чтобы осуществить программирование контроллера? Во – первых нужен программист, который бы досконально разбирался в данном вопросе. Во – вторых необходим сам компьютер и конечно пакет разработки.

Виды языков программирования для ПЛК

  • Язык LD

LD (Ladder) – это среда разработки, которая основана на графике. Своего рода, она представляет собой подобие релейной схемы. Разработчики данного стандарта считают, что использование такого вида программной среды существенно облегчает переобучение инженеров релейной автоматики на ПЛК.

К главным недостаткам, данного языка программирования, можно отнести неэффективность при обработке процессов с большим количеством аналоговых переменных, так как он построен для представления процессов с дискретным характером.

  • Язык FBD

FBD ( Диаграмма Функциональных Блоков) – здесь также используется графическое программирование. Образно говоря, FBD определяет собой некую множественность функциональных блоков, которые имеют соединения между собой (вход и выход).

Данные связи являются переменными и выполняют пересылку между блоками. Каждый блок в отдельности может представлять определенную операцию( триггер, логическое “или” и т.д.). Переменные задаются с помощью определенных блоков, а цепи выхода могут иметь связи с конкретными выходами контроллера или связи с глобальными переменными.

  • Язык SFC

SFC ( Sequential Function Chart) – может использоваться с языками ST и IL, он также основан на графике. Принцип его построения близок к образу конечного автомата, данное условие относит его к самым мощным языкам программирования.

Технологические процессы, в данном языке, построены по типу определенных шагов. Структура шагов состоит из вертикали, которая идет сверху вниз. Каждый шаг – это конкретные операции. Описать операцию можно не только с помощью SFC, но и с помощью ST и IL.

Как только шаг выполнен, то идет действие по передачи управления следующему шагу. Переход между шагами может быть двух видов. Если на шаге выполнено какое – то условие и дальнейшим действием является переход на следующий шаг, значит – это условный переход. В случае же, если происходит полное выполнение всех условий на данном шаге и только потом осуществляется переход на следующий шаг, то-это безусловный переход.

Недостатком SFC можно считать, что в процессе работы может быть активировано несколько шагов, не в параллельных потоках. Поэтому необходим глобальный контроль со стороны программиста.

  • Язык ST

ST ( Структурированный Текст) – относится к языкам высокого уровня и имеет много сходного с Pascal и Basic.

ST позволяет интерпретировать более шестнадцати типов данных и имеет возможность работать с логическими операциями, циклическими вычислениями и т.д.

Небольшим недостатком можно определить отсутствие графической среды. Программы представлены в виде текста и данное условие усложняет освоение технологии.

  • Язык IL

IL ( Список Команд) – язык подобен Ассемблеру, обычно используется для кодировки блоков по отдельности. Плюсом является то, что данные блоки имеют большую скорость работы и низкую требовательность к ресурсам.

  • Язык CFC

CFC ( Continuous Flow Chart) – относится к языкам высокого уровня. В принципе – это явное продолжение языка FBD.

Процесс проектирования состоит из использования готовых блоков и размещения их на экране. Далее происходит их настройка и размещения соединений между ними.

Каждый блок – это управление определенным технологическим процессом. Здесь идет основной уклон на технологический процесс, математика уходит на второй план.

CoDeSys

Первоначально опубликовано ivanset

Расскажите пожалуйста в двух словах, как происходит связка (заливка) написанной программы в CoDeSys с контроллером, и какие комплектующие (программные и аппаратные) для этого необходимы.

Кратко не реально. Но попробую

Среда программирования CoDeSys универсальна. К ней подключаются TSP файлы, в которых определен тип процессора, распределение памяти и др. Если TSP установлен, то CoDeSys сможет генерировать машинный код для соответствующего ПЛК.

Чтобы программировать ПЛК (или пром PC) в нем должна сидеть система исполнения CoDeSys SP. Это своего рода специализированная ОС. Она включает монитор многозадачности, отладочные функции и функции поддержки железа (они реализуются пишутся изготовителем).

Физически связь ПЛК со средой программирования может быть реализована по последовательному каналу, по любой сети или через разделяемую память. По минимуму для поддержки CoDeSys SP контроллер должен иметь 1 аппаратный таймер, 1 последовательный порт, электрически перепрограммируемую память (или диск) и процессор (из числа поддерживаемых).

Стержневая идея бизнес модели 3S состоит в том, чтобы все было максимально удобно для пользователей контроллеров. Все технические проблемы должны решаться 3S и изготовителем контроллеров. Покупатель ПЛК должен получать полностью готовый к работе продукт в коробке вместе с необходимым ПО. Он не должен ни чего более покупать кроме ПЛК! Обычно система исполнения прошивается при изготовлении контроллера, в его цену включается цена лицензии. Это увеличивает цену ПЛК на 2-10%.

Схема очень нравится пользователям. Но не очень нравится изготовителям контроллеров. Чтобы поддержать CoDeSys они должны проделать определенную работу (адаптировать систему исполнения) и купить оптом лицензии. Т.е. нужно вложить свои средства. Чем больше вложения, тем лучше результат. Если изготовитель уверен в техническом уровне и качестве продукции, то он не боится планировать бизнес на перспективу. В итоге его покупателям CoDeSys достается почти даром.

Все конкурирующие системы применяют иной подход: создания благоприятных условий для изготовителей оборудования. Главное чтобы система легко встраивалась куда угодно. Затраты и проблемы переносятся на покупателей. Изготовителям это нравится.

Поддержать CoDeSys изготовителей могут заставить только заказчики. В итоге он применяется только серьезными успешными компаниями. Если фирма имеет мало заказчиков и делает ПЛК которые нормально держатся на DIN рейке если подложить бумажку под пружинку (и т.п.) то в списке поддерживаемых систем программирования CoDeSys Вы точно не найдете.

Вообще же не проблема создать компромиссную схему удобную заказчикам и изготовителям. Изготовитель может дописывать свои библиотеки и расширять CoDeSys своими оригинальными компонентами. В итоге получается новый инструмент, заточенный на конкретный контроллер. Естественно он не обязан быть бесплатным.

Первоначально опубликовано ivanset
… И еще, насколько я понял, для связки контроллера с CoDeSys нужен target-файл. ПЛК WAGO 750-842..

Да.

Первоначально опубликовано ivanset
У меня есть CoDeSys SP RTE, но она запускается в демо-режиме и требует лицензии. Где можна найти эту лицензию…

Основные языки программирования контроллеров PLC

Главная задача ПЛК – это выполнение прикладной программы управления технологическим процессом. Очевидно, что незапрограммированный контроллер – это всего лишь пустая железяка, не приносящая никакой пользы человечеству.

Какие программы может выполнять промышленный контроллер? Ответ прост: практически любые. Современный контроллер свободно программируем, т.е. предоставляет разработчику возможность создавать пользовательские программы произвольной структуры без ограничений их функциональности, будь то программа управления пастеризатором на молочном комбинате или управление колонной ректификации на НПЗ. По сути, единственным ограничением здесь может быть объем свободных ресурсов контроллера.

Что нужно, чтобы запрограммировать ПЛК? Грамотный специалист. Во-вторых, персональный компьютер или портативный программатор, подключенный к контроллеру по сети. В-третьих, программный пакет разработки, поставляемый, как правило, за дополнительную плату. Иногда среда разработки входит в состав комплексного ПО для инсталляции и эксплуатации всей системы управления.

Современные средства разработки чрезвычайно функциональны и предлагают разработчику множество возможностей:

1. Разнообразные программные библиотеки, функциональные блоки, готовые процедуры и шаблоны. Использование предподготовленных компонентов сильно ускоряет процесс разработки программного обеспечения для ПЛК.

2. Инструменты для отладки, тестирования и симуляции прикладной программы. Последние позволяют выполнять программу ПЛК на персональном компьютере без загрузки в реальный контроллер.

3. Инструменты для автоматизированного документирования разработанной программы в соответствие с принятыми стандартами.

Но у программиста есть и более мощный инструмент. Дело в том, что современные средства разработки прикладного ПО для промышленных контроллеров, как правило, поддерживают до шести разных языков программирования.

Существует международный стандарт IEC 61131, разработанный Международной Электротехнической Комиссией (МЭК, IEC) и состоящий из восьми частей. Наиболее интересной является третья часть, IEC 61131-3, описывающая языки программирования ПЛК. Первоначальной целью стандарта IEC 61131-3 была унификация языков программирования ПЛК и предоставление разработчикам ряда аппаратно-независимых языков, что, по замыслу создателей стандарта, обеспечило бы простую переносимость программ между различными аппаратными платформами и снимало бы необходимость изучения новых языков и средств программирования при переходе разработчика на новый ПЛК.

К сожалению, цели в полном объеме достигнуты не были. Каждый производитель ПЛК сопровождает свой продукт собственной средой программирования, которая, как правило, не совместима с другими, да и о кросс-платформенности программного кода можно забыть. Тем не менее, в части описания языков программирования стандарт IEC 61131 остается чрезвычайно актуальным и является ориентиром для большинства разработчиков ПЛК.

Какие языки используются для программирования промышленных контроллеров? Ниже приведен краткий обзор языков стандарта.

Язык LD

Язык LD (LAD, Ladder) является графическим языком разработки, программа на котором представляет собой аналог релейной схемы. Пример программы на данном языке приведен на рис. 1. По идеи авторов стандарта, такая форма представления программы облегчит переход инженеров из области релейной автоматики на ПЛК.

К недостаткам данного языка можно отнести то, что по мере увеличения количества «реле» в схеме она становится сложнее для интерпретации, анализа и откладки. Еще один недостаток языка LD заключается в следующем: язык, построенный по аналогии с релейными схемами, может быть эффективно использован только для описания процессов, имеющих дискретный (двоичный) характер; для обработки «непрерывных» процессов (с множеством аналоговых переменных) такой подход теряет смысл.

Рис. 1. Язык релейных диаграмм LD.

Язык FBD

Язык FBD (Functional Block Diagram, Диаграмма Функциональных Блоков) является языком графического программирования, так же, как и LD, использующий аналогию с электрической (электронной) схемой. Программа на языке FBD представляет собой совокупность функциональных блоков (functional flocks, FBs), входа и выхода которых соединены линиями связи (connections). Эти связи, соединяющие выхода одних блоков с входами других, являются по сути дела переменными программы и служат для пересылки данных между блоками. Каждый блок представляет собой математическую операцию (сложение, умножение, триггер, логическое “или” и т.д.) и может иметь, в общем случае, произвольное количество входов и выходов. Начальные значения переменных задаются с помощью специальных блоков – входов или констант, выходные цепи могут быть связаны либо с физическими выходами контроллера, либо с глобальными переменными программы. Пример фрагмента программы на языке FBD приведен на рис. 2.

Практика показывает, что FBD является наиболее распространенным языком стандарта IEC. Графическая форма представления алгоритма, простота в использовании, повторное использование функциональных диаграмм и библиотеки функциональных блоков делают язык FBD незаменимым при разработке программного обеспечения ПЛК. Вместе с тем, нельзя не заметить и некоторые недостатки FBD. Хотя FBD обеспечивает легкое представление функций обработки как «непрерывных» сигналов, в частности, функций регулирования, так и логических функций, в нем неудобным и неочевидным образом реализуются те участки программы, которые было бы удобно представить в виде конечного автомата.

Рис.2. Функциональная схема FBD.

Язык SFC

Язык последовательных функциональных схем SFC (Sequential Function Chart), использующийся совместно с другими языками (обычно с ST и IL), является графическим языком, в котором программа описывается в виде схематической последовательности шагов, объединенных переходами. Язык SFC построен по принципу, близкому к концепции конечного автомата, что делает его одним из самых мощных языков программирования стандарта IEC 61131-3. Пример программы на языке SFC приведен на рис. 3.

Наиболее простым и естественным образом на языке SFC описываются технологические процессы, состоящие из последовательно выполняемых шагов, с возможностью описания нескольких параллельно выполняющихся процессов, для чего в языке имеются специальные символы разветвления и слияния потоков (дивергенции и конвергенции, в терминах стандарта IEC 61131-3).

Шаги последовательности располагаются вертикально сверху вниз. На каждом шаге выполняется определенный перечень действий (операций). При этом для описания самой операции используются другие языки программирования, такие как IL или ST.

Действия (операции) в шагах имеют специальные классификаторы, определяющие способ их выполнения внутри шага: циклическое выполнение, однократное выполнение, однократное выполнение при входе в шаг и т.д. В сумме таких классификаторов насчитывается девять, причем среди них есть, например, классификаторы так называемых сохраняемых и отложенных действий, заставляющие действие выполняться даже после выхода программы из шага.

После того, как шаг выполнен, управление передается следующему за ним шагу. Переход между шагами может быть условным и безусловным. Условный переход требует выполнение определенного логического условия для передачи управления на следующий шаг; пока это условие не выполнено программа будет оставаться внутри текущего шага, даже если все операции внутри шага уже выполнены. Безусловный переход происходит всегда после полного выполнения всех операций на данном шаге. С помощью переходов можно осуществлять разделение и слияние ветвей последовательности, организовать параллельную обработку нескольких ветвей или заставить одну выполненную ветвь ждать завершения другой.

Как и любому другому языку, SFC свойственны некоторые недостатки. Хотя SFC может быть использован для моделирования конечных автоматов, его программная модель не совсем удобна для этого. Это связано с тем, что текущее состояние программы определяется не переменной состояния, а набором флагов активности каждого шага, в связи с чем при недостаточном контроле со стороны программиста могут оказаться одновременно активными несколько шагов, не находящихся в параллельных потоках.

Еще одно неудобство языка связано с тем, что шаги графически располагаются сверху вниз, и переход, идущий в обратном направлении, изображается в неявной форме, в виде стрелки с номером состояния, в которое осуществляется переход.

Рис. 3. Язык последовательных функциональных схем SFC.

Язык ST

Язык ST (Structured Text, Структурированный Текст) представляет собой язык высокого уровня, имеющий черты языков Pascal и Basic. Данный язык имеет те же недостатки, что и IL, однако они выражены в меньшей степени. Пример программы на языке ST приведен на рис. 4.

С помощью ST можно легко реализовывать арифметические и логические операции (в том числе, побитовые), безусловные и условные переходы, циклические вычисления; возможно использование как библиотечных, так и пользовательских функций. Язык также интерпретирует более 16 типов данных.

Язык ST может быть освоен технологом за короткий срок, однако текстовая форма представления программ служит сдерживающим фактором при разработке сложных систем, так как не дает наглядного представления ни о структуре программы, ни о происходящих в ней процессах.

Рис. 4. Язык структурированного текста ST.

Язык IL

Язык IL (Instruction List, Список Команд) представляет собой ассемблероподобный язык, достаточно несложный по замыслу авторов стандарта, для его практического применения в задачах промышленной автоматизации пользователем, не имеющим, с одной стороны, профессиональной подготовки в области программирования, с другой стороны, являющимся специалистом в той или иной области производства. Однако, как показывает практика, такой подход себя не оправдывает.

Ввиду своей ненаглядности, IL практически не используется для программирования комплексных алгоритмов автоматизированного управления, но часто применяется для кодирования отдельных функциональных блоков, из которых впоследствии складываются схемы FBD или CFC. При этом IL позволяет достичь высокой оптимальности кода: программные блоки, написанные на IL, имеют высокую скорость исполнения и наименее требовательны к ресурсам контроллера.

Язык IL имеет все недостатки, которые присущи другим низкоуровневым языкам программирования: сложность и высокую трудоемкость программирования, трудность модификации написанных на нем программ, малую степень «видимого» соответствия исходного текста программы и решаемой задачи.

Пример программы на языке IL приведен на рис. 5.

Рис. 5. Язык инструкций IL.

Многие производители инструментальных средств, опирающиеся на стандарт IEC, не ограничиваются поддержкой рассмотренных выше пяти языков стандарта. Можно выделить, как минимум, еще один язык визуального программирования, который довольно популярен среди разработчиков.

Язык CFC

Язык CFC (Continuous Flow Chart) – еще один высокоуровневый язык визуального программирования. По сути, CFC – это дальнейшее развития языка FBD. Этот язык был специально создан для проектирования систем управления непрерывными технологическими процессами.

Проектирование сводится к выбору из библиотек готовых функциональных блоков, их позиционированию на экране, установке соединений между их входами и выходами, а также настройке параметров выбранных блоков. В отличие от FBD, функциональные блоки языка CFC выполняют не только простые математические операции, а ориентированы на управление целыми технологическими единицами. Так в типовой библиотеке CFC блоков находятся комплексные функциональные блоки, реализующие управление клапанами, моторами, насосами; блоки, генерирующие аварийные сигнализации; блоки PID-регулирования и т.д. Вместе с тем доступны и стандартные блоки FBD. Унаследовав от FBD саму концепцию программирования, язык CFC в наибольшей степени ориентирован на сам технологический процесс, позволяя разработчику абстрагироваться от сложного математического аппарата.

Рис. 6. Среда проектирования на языке CFC системы Simatic PCS7.

CFC прост в освоении, и при этом позволяет разрабатывать сложнейшие алгоритмы автоматизированного управления без каких-либо специфических знаний других языков программирования.

Казанцев Андрей

Наверх

This entry was posted in Ремонт. Bookmark the <a href="https://kabel-house.ru/remont/yazyk-programmirovaniya-kontrollerov/" title="Permalink to Язык программирования контроллеров" rel="bookmark">permalink</a>.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *