Объектно-ориентированное программирование (ООП) – это парадигма программирования, основанная на концепции объектов, которые могут содержать данные в виде свойств и код в виде процедур, известных как методы. Объекты примечательны тем, что они могут иметь процедуры, которые можно использовать для доступа и изменения полей данных объекта, с которым связаны эти поля. В ООП компьютерные программы состоят из взаимодействующих друг с другом объектов. Языки ООП разнообразны, однако, самые популярные из них основаны на классах. Это означает, что используемые в них объекты являются экземплярами классов, которые и определяют типы самих объектов.
Это сведения, которые можно посмотреть на Wiki, об ООП в целом, и это то, что большинство из нас хотели бы иметь у себя при разработке систем ПЛК. Считается, что у меня больше инструментов и возможностей, когда пишу программу на любом языке высокого уровня, таком как C++ или C#. Тогда и процесс разработки продвигается значительно легче и быстрее.
TwinCat3 от Beckhoff ввёл ООП в сферу ПЛК. Вот список появившихся возможностей:
- Методы
- Свойства
- Интерфейсы
Из этого списка мы можем сделать вывод, что теперь есть возможность извлечь выгоду из большинства преимуществ ООП применительно к автоматизации предприятия. Но так ли они новы как кажутся? Привнесут ли они удобство функциональности C# в разработку ПЛК?
Мы хотели бы представить вам серию статей, в которых с помощью простых примеров попытаемся сравнить старые способы CoDeSys2 с новым TwinCat3. Как с ООП, так и без него. Я попытаюсь использовать образец проекта ПЛК Beckhoff, предназначенный для демонстрации некоторых основных функций объектно-ориентированного программирования. В то же время я запрограммирую его в не объектно-ориентированной системе CodeSys2, чтобы все могли увидеть разницу, включая ошибки и функции, которые могут появиться при разработке ПЛК.
Свою первую статью я хотел бы посвятить самой последней функции, доступной в TwinCat3: Свойства.
Изначально свойства появились в языке JavaScript, чтобы просто установить связь между определённым именем и значением объекта. В TwinCAT у свойств уже есть методы доступа Get и Set для получения и установки их значений, соответственно. TwinCAT автоматически вызывает эти методы при чтении или записи в функциональный блок, реализующий свойство.
Свойства можно распознать по следующим характеристикам:
Спецификатор доступа
- PUBLIC: Соответствует спецификации без модификатора доступа.
- PRIVATE: Доступ к свойству возможен только в пределах функционального блока.
- PROTECTED: Доступ к свойству возможен только в пределах программы, функционального блока и его производных.
- INTERNAL: Доступ к свойству возможен только в пределах пространства имён, то есть в пределах библиотеки.
- FINAL: Перезапись свойства в производной от функционального блока не допускается. Это значит, что свойство не может быть перезаписано или расширено в любом из возможно существующих подклассов.
Свойство может быть абстрактным, что означает случай, когда оно не имеет начальной реализации, а его фактическая реализация предоставляется в производном функциональном блоке.
При этом у нас всегда была простая ассоциация в ПЛК: VarIn, VarOut и другие типы переменных с разными типами доступа, которые можно использовать так же просто, как свойства.
Пример: Cylinder.var_in_out_bAtBasePos это то же, что и Cylinder.State_AtBasePos.
Кроме того, мы можем указать некоторые правила для установки и получения значений в пределах функционального блока Cylinder. В целом, я могу ограничиться обычными внутренними переменными.
PROTECTED, INTERNAL и FINAL – действительно новые вещи, придающие свойствам гибкость. Но для их использования потребуется дополнительный код. Также за этим кроется неприятная особенность:
Как вы можете заметить, их невозможно отслеживать!
Но это удивляет лишь на первый взгляд. Добавим немного кода, и надлежащую функциональность удастся восстановить, как поясняется далее.
Прагмы бывают очень кстати для отслеживания свойств в режиме реального времени. Для этого напишите в верхней части деклараций свойств атрибут ‘monitoring’:
{attribute ‘monitoring := ‘variable’}: TwinCAT при доступе к свойству сохраняет фактическое значение в переменной и отображает её значение. Это значение может оказаться устаревшим, если из кода нет обращений к свойству.
{attribute ‘monitoring’ := ‘call’}: Каждый раз при отображении значения TwinCAT вызывает код метода доступа Get. Любой побочный эффект, вызванный этим кодом, может проявиться в мониторинге.
Таким образом, используя свойства, можно задействовать преимущества для библиотек с более сложным кодом. Наша команда программистов не так часто пользуется свойствами в своих внутренних проектах. Однако же свойства удобны в библиотеках для внешнего использования.
Следующая статья познакомит вас с методами, а также с другими новинками современных инструментов разработки для ПЛК.
