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

СТА 2/2006 www.cta.ru Ц ЕЛИ В то время как в сфере компьютерных приложений объ- ектноориентированное программирование (ООП) давно стало составной частью всех ведущих языков, в сфере кон- троллерных приложений оно применяется крайне редко. Говорят, что это происходит в силу некоторой консерватив- ности, свойственной программистам контроллеров (ПЛК). Отчасти это действительно так. Но всё же в более значи- тельной степени здесь сказываются ограниченные возмож- ности инструментов программирования. Конечно, почти все современные контроллерные платформы дают возмож- ность так или иначе использовать C++ (за дополнительные деньги). Однако компилятор обеспечивает только лишь ас- пекты чистого программирования. Функции отладки и вво- да в эксплуатацию этих систем практически непригодны для контроллерных приложений. Даже для элементарного мониторинга значений входоввыходов приходится писать вызовы библиотечных функций. О таких приёмах, как «го- рячая» замена кода прикладной программы без остановки контроллера, вообще нужно забыть. Помимо этого автома- ты и задачи с битовыми операциями реализуются в C++ достаточно сложно. Т РЕБОВАНИЯ В результате компанией 3SSmart Software Solutions было принято решение расширить нормы стандарта МЭК 611313, введя поддержку ООП в новое поколение системы программирования CoDeSys. Расширения стан- дарта должны подчиняться следующим требованиям: ● ООПрасширения должны быть не обязательными, а оп- циональными; ● ООП и не ООПпрограммирование можно совмещать; ● существующие приложения должны полностью поддер- живаться с возможностью их плавной трансформации в ООП с учетом целесообразности; ● ООП должно быть применимо во всех языках МЭК 611313; ● программист не должен сталкиваться со сложными опре- делениями. Р АСШИРЕНИЯ Основное расширение МЭК 611313 касается превраще- ния функционального блока (FUNCTION_BLOCK) в класс. Подобным образом структуры выросли в классы в языке C++. Это достигается введением методов. Фактиче- ски метод — это функция, встроенная в функциональный блок. В реализации функции доступны не только значения её параметров и локальных переменных, но и данные эк- земпляра функционального блока. В итоге вызов метода всегда включает имена экземпляра и метода. Следующий пример показывает определение и вызов простого метода. TYPE Direction: (Forward, Backward); END_TYPE FUNCTION_BLOCK Pump VAR Enabled: BOOL ; Direction: Direction; END_VAR METHOD GetState : BOOL GetState := Enabled; END_METHOD METHOD Start: BOOL (* Метод Start *) VAR_INPUT WantedDirection: Direction; END_VAR Enabled := TRUE ; Direction := WantedDirection; END_METHOD END_FUNCTION_BLOCK PROGRAM Main VAR Pump1: Pump; Pump2: Pump; END_VAR Pump1.Start(Forward); (*Вызов метода Start*) Pump2.Start(Backward); END_PROGRAM Естественно, вызов метода можно выполнить и в графи- ческих языках (рис. 1). Даже если функциональный блок имеет методы, ничто не мешает использовать его обычным образом, как определено в стандарте МЭК 611313. В ЗАПИСНУЮ КНИЖКУ ИНЖЕНЕРА Объектно-ориентированные расширения МЭК 61131-3 Дитер Хесс 90 Рис. 1. Пример вызова метода в FBD