ЖУРНАЛ «СТА» №2/2005

97 СТА 2/2005 www.cta.ru В З АПИС Н УЮ К НИЖК У ИНЖЕ Н Е РА ● возможность применения highend инструментов не только для сверх- производительных, но и для эконо- мичных ПЛК (на 16разрядных ЦП, с 64 кбайт RAM и 64 кбайт флэшпамяти). CoDeSys 3.0 реализует более сотни интересных новшеств. В их числе воз- можность «сворачивать» в одну строку отображение сложных конструкций в языке ST (IF … END_IF, VAR … END_VAR и т.д.), мониторинг проме- жуточных значений в выражениях, МЭКфункции с переменным числом параметров и многое другое. Однако из всех новшеств достаточно легко можно отметить 5 ключевых. Именно они чётко выделяют CoDeSys 3.0 на фоне других программных инструмен- тов ПЛК: ● объектноориентированные расши- рения МЭК; ● сети ПЛК; ● профили версий; ● безопасные системы; ● объединяющая платформа автома- тизации. О БЪЕКТНО - ОРИЕНТИРОВАННЫЕ РАСШИРЕНИЯ Подавляющее большинство значи- мых программных проектов для ПК реализуется сегодня с помощью объ- ектноориентированных языков. Хотя поначалу некоторые программисты скептически относились к ООП, уменьшение сроков разработки и про- стота повторного использования те- перь уже никем не оспариваются. В CoDeSys 3.0 полноценно реализо- ваны фундаментальные особенности объектноориентированного про- граммирования: классы, интерфейсы, наследование, полиморфизм и дина- мическое связывание. 3S расширила МЭК 611313 без его изменения, введя дополнительный набор ключевых слов. Аналогичным образом язык C был расширен до C++. Действительно ли необходимо ООП в контроллерных задачах? Для ответа на этот вопрос попробуйте, например, создать библиотеку функциональных блоков МЭК, которые должны вести себя поразному в автоматическом, ручном режимах и режиме настройки. Насколько красиво это реализуется с ООП, настолько же неуклюже без ООП. Однако это всегонавсего про- стейшая типовая задача. Конечно же, ООП — это не стан- дартное расширение МЭК 611313. Но дело упрощается тем, что в стан- дарте уже заложен фундамент объек- та. Это функциональный блок. Даже в ранних версиях CoDeSys функцио- нальные блоки включали действия, аналогичные методам класса. Доосна- щение блоков всеми свойствами объ- екта выглядит как абсолютно естест- венное их развитие. Новые ключевые слова построены на базе языка Java (рис. 2). Таким образом, знакомые с ООП программисты не встретят никаких затруднений при работе в CoDeSys. Помимо собственно программ, кон- цепция объекта в CoDeSys 3.0 приме- нена и для других элементов проекта, както: графические элементы визуа- лизации, элементы сетевой конфигу- рации и др. С ЕТИ ПЛК Интеллектуальные устройства про- мышленной автоматизации, выпуска- емые более чем 60 компаниямичле- нами CoDeSys Automation Alliance, программируются в CoDeSys версии 2.3 и могут использовать общее прост- ранство сетевых переменных. В вер- сии 3.0 появилась возможность прос- того администри- рования всех ПЛК, объединенных в сеть в одном про- екте. Конечно же, составляющие сеть контроллеры могут быть выпущены разными изготови- телями. Настройка специфических пе- ременных конт- роллеров предельно упрощена. Еще одним интересным новшеством явля- ется возможность выполнения нес- кольких разных приложений и нес- кольких экземпляров одного прило- жения (клонов) в одном устройстве (рис. 3). Помимо этого, конфигуратор сети позволяет теперь настраивать не толь- ко интеллектуальные устройства, но и обеспечивает установку параметров пассивных элементов (датчики угла поворота, исполнительные механиз- мы и т.д.). П РОФИЛИ ВЕРСИЙ Каждому специалисту, занятому об- служиванием, хорошо знаком следую- щий сценарий: незначительный ре- монт оборудования или модернизация технологии приводят к необходимо- сти коррекции программы ПЛК. Ис- ходный проект сохранился, но для его правки желательно использовать именно ту версию программного ин- струмента, в которой он был создан. В результате на компьютере обслужи- вающего техника появляется набор разных версий одного и того же инст- Рис. 2. ООП расширения функционального блока МЭК Рис. 3. Конфигурирование проекта в CoDeSys 3.0