TwinCAT 3, используя методы для внутренней функциональности FB или только для интерфейсов?

Question

Я старый пользователь технологий Beckhoff, особенно TwinCAT. В настоящее время мы претерпеваем трансформацию наших архитектур ПЛК из-за новых функциональных возможностей, которые предоставляет TwinCAT 3 (объектно-ориентированная)

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

С моей точки зрения, методы создаются не только для того, чтобы определять и реализовывать интерфейсы, но и как способ упростить функциональные блоки и их внутренний конечный автомат. Например, если у меня есть FB_Conveyor, у которого есть собственный конечный автомат, я мог бы выбрать создание и внутренний МЕТОД (M_INIT) для конвейера, который будет проверять конвейер, чтобы проверить, есть ли какие-либо продукты, когда конвейер находится в состоянии INIT., проверяя выходное значение метода. MEthod будет содержать свой выигранный конечный автомат и не будет готов, пока его вывод не вернет значение TRUE.

Первая проблема возникает здесь, так как некоторые из наших программистов в реальном времени считают, что методы для этого не сделаны, что в этом случае мы должны реализовать FB_INIT, который вызывается из FB_CONVEYOR и содержит свои собственные переменные, поэтому оба имеют REF-FB_MOTOR,

Основным аргументом является то, что METHODS являются инструментом для создания интерфейсов и управления FB, поэтому, например, мой собственный FB_CONVEYOR мог быть расширен из I_Conveyor, у которого есть метод M_TakeIn, но НЕ для реализации внутренней функциональности в качестве его инициализации.

Одним из аргументов также является то, что методы используют свои собственные переменные стека, поэтому все данные метода являются временными и действительны только во время выполнения. Это означает, что если методы, которые реализуют его, станут слишком большими, мы не сможем обеспечить правильную задержку в реальном времени. Тогда на моем собственном опыте TC всегда будет тратить столько ресурсов процессора, чтобы обеспечить правильное время цикла, поэтому использование внутренней переменной стека на самом деле не является архитектурной ошибкой, но это нормально и желательно, потому что на самом деле TC обеспечивает работу в реальном времени, но не нуждается быть реализованным как процесс в реальном времени (на основе C).

Обсуждение продолжается, и очень интересно, как появляются разные мнения относительно того, должны ли Методы использоваться или нет как внутренняя операция, или мы должны фактически следовать архитектуре FB TC2 Motion, где разные функции управления функциональными блоками различны функциональность, и каждый из них имеет ссылку на определенную ось (FB_MOVE, FB_HOME и т. д.)

Ни в одном документе не нашли реального ответа на этот вопрос. Методы почти всегда упоминаются в случае определения интерфейсов, но никогда в случае программирования внутренней функциональности FB.

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

Этот вопрос почти такой же для новых версий CodeSyS, которые также имеют методы и интерфейсы.

Answer 1

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

Но вы можете объявить переменные любого типа внутри метода. подобно VAR_INST он будет закрытым для каждого экземпляра, так как он создается на уровне FB (функциональный блок) (переменная по умолчанию в FB). Или вы можете объявить VAR_STAT это будет общим для всех случаев. Метод может сделать код намного более понятным.

И Метод, и Действие могут использовать все переменные из его FB.

И Методы, и Действия могут быть разработаны с использованием языка программирования, отличного от FB. Пример: FB написан с использованием ST, но его Метод или Действие могут быть написаны в Ladder Diagram.

Лично я не вижу связи между существованием метода и интерфейсом. Я бы не спешил использовать все функции, которые предлагает ООП. Наследование, интерфейс и свойства могут превратить вашу программу в кошмар, если не использовать ее с умом. Хотя инкапсуляция в TwinCAT является в лучшем случае виртуальной.

Редактировать: при создании метода в программе (статический объект в TwinCAT) VAR_INST не может быть создан в этом методе, так как ни один экземпляр не существует в программе. Только VAR_STAT а также VAR_TEMP может быть использован в методе Программы. Это очень похоже на другие языки программирования, которые не могут создавать экземпляры статических классов, а их переменные также могут быть только статическими.

Answer 2

У вас в значительной степени есть смысл, но, если коротко, функциональные блоки в ПЛК определяют общий "класс" функциональности. Этот класс будет иметь определенные входы и выходы, а также методы / действия для управления ими. Нужно создать экземпляр функционального блока, чтобы использовать методы. Экземпляр длится до тех пор, пока выполняется программа, а затем удаляется (остановка ПЛК).

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

Подробнее об этом читайте здесь: http://infosys.beckhoff.com/content/1033/tc3_plc_intro/html/pou_method.htm

Answer 3

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

Например, у меня есть блок журнала, который записывает данную строку в файл журнала. Он также может читать этот журнал в массив ПЛК.

Блок выглядит так:

FB_Logger

• AddLogLine
  • Открытый метод для добавления строки журнала
• SaveLogToFile
  • Публичное действие (тоже может быть методом) для сохранения файла журнала
• LoadLogFromFile
  • Публичное действие (тоже может быть методом) для чтения файла журнала
• LogArray
  • Открытый геттер для массива логов. НЕДВИЖИМОСТЬ типа REFERENCE TO ARRAY..
• GetLogFileHeader
  • Закрытый метод для создания заголовка файла
• GetLogFileLine
  • Закрытый метод для создания строки журнала
• Сохранить файл
  • Частный метод, чтобы начать экономить
• ShiftLogItems
  • Приватный метод смещения массива логов

У самого функционального блока также есть некоторый код, который вызывается каждый цикл.

Я использую эти функции ООП очень богатым способом. Иногда я добавляю методы в ПРОГРАММЫ, чтобы сделать их более понятными. Раньше у меня был один функциональный блок и пять вспомогательных функций, теперь у меня есть один функциональный блок с закрытыми методами.

Просто проверь это!