Доброго времени суток, уважаемые жители Хабра!
Прочитав пост про программирование ПЛК Siemens серии S7, я залез в поиск по Хабру, и был весьма удивлен, что тема промышленной автоматики вообще, и программирования ПЛК в частности, освещена весьма и весьма скудно. Возьму на себя смелость поделиться своим опытом в данной области, описав базовые принципы программирования ПЛК, в частности, производства компании Beckhoff.
Я занимаюсь автоматизацией зданий. Сложилось так, что в основном мы строим свои системы на базе ПЛК Beckhoff. Такой выбор был сделан прежде всего потому, что эти контроллеры являются свободно-программируемыми в полном смысле этих слов. Что это значит? Возьмите контроллер TAC Xenta, например, и попробуйте на нем реализовать обмен с внешним устройством через RS232 по собственному протоколу, на уровне «байт послал — байт принял». Не получится, эти контроллеры так не умеют — используйте только те протоколы, которые в них заложил разработчик. А Beckhoff умеет. Но прежде чем лезть в такие дебри, давайте посмотрим на среду разработки? На каком, собственно, языке, мы будем писать?
Промышленные ПЛК программируются на языках стандарта МЭК 61131-3. Всего этих языков 5, некоторые производители добавляют свои. Языки друг на друга совсем не похожи, и, наблюдая за коллегами, могу предположить, что выбор того или иного языка связан прежде всего с тем, чем человек занимался до того, как он пришел в эту отрасль.
Из не всеми поддерживаемых языков стоит отметить язык 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.
Но это «голова» контроллера, а ведь ему еще нужны входы и выходы, чтобы общаться с внешним миром. Тут есть два подхода:
Вот так выглядит внешне подход «все в одной коробке». На фото Carel pCO3.
А вот другой вариант — голова Beckhoff серии CX9000 (слева на фото) с набором модулей ввода-вывода.
Помимо всего прочего, на голове еще имеется некая шина, позволяющая объединять ПЛК в сеть, а зачастую еще и менять его программу через эту же сеть. Какая это будет сеть — зависит от ПЛК. Это могут быть и незнакомые тем, кто не сталкивался с промышленными сетями EIA-485, Profibus, CAN, а может быть и вполне привычный Ethernet. Именно через эту сеть, называемую fieldbus, и осуществляется подключение ПЛК к верхнему уровню — к СКАДА-системе, например. На фото выше хорошо видны 2 разъема 8P8C на голове Beckhoff'а — это Ethernet, а у Carel сверху слева видны (плоховато, правда) 2 разъема 6P4C — так они сделали RS-485. У этого интерфейса, к сожалению, нет общепринятого разъема.
Вообще, это тема не статьи, а целой книги. Но расскажу то, что увидел на личном опыте, и пусть это будет ложкой дегтя.
Для профессиональных программистов освоение ПЛК во многом покажется деградацией. ООП? Их нет у нас, есть только структуры, перечисления, и некое подобие класса, которое называется «функциональный блок». Что такое Private, Public и прочее, тоже можно забыть сразу — не пригодится. Из любого места вашей программы можно получить доступ к любому другому месту.
Динамическое выделение памяти? Их нет у нас совсем. Не уверен, сколько тебе пришлют данных? Выделяй буфер с запасом, и забудь про эту память — освободить ее не получится. Либо проявляй чудеса скорости и обрабатывай данные на лету, если успеешь уложиться в заданное время цикла.
Исключения? Да что вы… видел я одно чудо, которое намертво висло при выполнении конструкции вида:
Понятно, что переполнение, не влазит foo * bar в 16 бит, но зачем же виснуть-то? Да еще так, что ничего, кроме сброса по питанию не помогает.
Среда разработки? Не у всех CoDeSys, многим хочется пооригинальничать и написать что-нить свое. Одна из таких самописных сред вылетала с runtime error при попытке записать число 86400 в 16-битный INT. А вы говорите, обработка исключений на ПЛК. Ее и в среде разработки-то не всегда нормально могут сделать.
НО! Зато для любителей той тонкой грани, которая отделяет железо от программного обеспечения, софта в просторечии — это очень интересная ветвь ай-ти, правда.
Надеюсь, что этот небольшой обзор будет полезен. Если хабрасообществу будет интересна эта тема, то расскажу про ПЛК подробнее.
Прочитав пост про программирование ПЛК Siemens серии S7, я залез в поиск по Хабру, и был весьма удивлен, что тема промышленной автоматики вообще, и программирования ПЛК в частности, освещена весьма и весьма скудно. Возьму на себя смелость поделиться своим опытом в данной области, описав базовые принципы программирования ПЛК, в частности, производства компании Beckhoff.
Введение
Я занимаюсь автоматизацией зданий. Сложилось так, что в основном мы строим свои системы на базе ПЛК Beckhoff. Такой выбор был сделан прежде всего потому, что эти контроллеры являются свободно-программируемыми в полном смысле этих слов. Что это значит? Возьмите контроллер TAC Xenta, например, и попробуйте на нем реализовать обмен с внешним устройством через RS232 по собственному протоколу, на уровне «байт послал — байт принял». Не получится, эти контроллеры так не умеют — используйте только те протоколы, которые в них заложил разработчик. А Beckhoff умеет. Но прежде чем лезть в такие дебри, давайте посмотрим на среду разработки? На каком, собственно, языке, мы будем писать?
Стандарт МЭК 61131-3
Промышленные ПЛК программируются на языках стандарта МЭК 61131-3. Всего этих языков 5, некоторые производители добавляют свои. Языки друг на друга совсем не похожи, и, наблюдая за коллегами, могу предположить, что выбор того или иного языка связан прежде всего с тем, чем человек занимался до того, как он пришел в эту отрасль.
- IL, instruction list, список инструкций. Похож на ассемблер. Не видел никого, кто его использовал бы, но подозреваю, что олдскульные кодеры, пробивавшие перфокарты по памяти, оценят.
- LD, ladder diagram. Визуальный язык, для тех, кто занимался разработкой схем релейной автоматики.
- ST, structured text. Более всего напоминает «классические» языки программирования, чем-то похож на Паскаль. Оттого ценится теми, кто до ПЛК занимался программированием на других языках и платформах, в частности — мной.
- FBD, functional block diagram. Этакая блок схема, любим прежде всего технологами, решившими податься в программирование, за свою наглядность.
- 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.
Но это «голова» контроллера, а ведь ему еще нужны входы и выходы, чтобы общаться с внешним миром. Тут есть два подхода:
- Можно сделать «все в одной коробке» — голова, некий набор входов / выходов, несколько вариантов конфигурации — вот тут у нас входов побольше, тут поменьше, тут голова помощнее, тут послабее. Так делают, например, Carel, и много кто еще. На маленьком проекте такой подход себя в чем-то, может быть, и оправдывает.
- Но лично мне кажется, что большую гибкость дает другой подход. Голова отдельно, и к ней по шине подключается наборный «хвост» из модулей ввода-вывода. Мы ставим те модули, которые нам нужны, и в том количестве, которые нам нужно. Так делают 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. А вы говорите, обработка исключений на ПЛК. Ее и в среде разработки-то не всегда нормально могут сделать.
НО! Зато для любителей той тонкой грани, которая отделяет железо от программного обеспечения, софта в просторечии — это очень интересная ветвь ай-ти, правда.
Надеюсь, что этот небольшой обзор будет полезен. Если хабрасообществу будет интересна эта тема, то расскажу про ПЛК подробнее.