Я старый пользователь технологий Beckhoff, особенно TwinCAT. В настоящее время мы претерпеваем трансформацию архитектуры наших ПЛК из-за новых функций, которые предоставляет TwinCAT 3 (объектно-ориентированный).
В настоящее время мы разрабатываем новую архитектуру ПЛК, и у нас есть несколько опасений по поводу того, как двигаться дальше. Один очень хороший пример, который в значительной степени привлекает наше внимание в данный момент, — это новые Методы и общие различия с Действиями.
С моей точки зрения, методы создаются не только для того, чтобы определять и реализовывать интерфейсы, но и как способ упростить функциональные блоки и их внутренние конечные автоматы. Например, если у меня есть FB_Conveyor, внутри которого есть собственный конечный автомат, я могу выбрать создание внутреннего МЕТОДА (M_INIT) для конвейера, который будет проверять конвейер, чтобы проверить, есть ли какие-либо продукты, когда конвейер находится в состоянии INIT. , проверяя выходное значение метода. MEthod будет содержать свою выигранную конечную машину и не будет готов, пока его вывод не вернет значение TRUE.
Первое беспокойство возникает здесь, так как некоторые из наших программистов реального времени считают, что методы не предназначены для этого, что в этом случае мы должны реализовать FB_INIT, который вызывается из FB_CONVEYOR и содержит свои собственные переменные, поэтому оба имеют REF для FB_MOTOR. .
Основной аргумент заключается в том, что МЕТОДЫ являются инструментом для создания интерфейсов и управления FB, так что, например, мой собственный FB_CONVEYOR мог бы быть расширен из I_Conveyor, который имеет метод M_TakeIn, но НЕ для реализации внутренней функциональности, такой как ее инициализация.
Одним из аргументов также является то, что методы используют свои собственные переменные стека, поэтому все данные метода являются временными и действительны только во время выполнения. Это означает, что если методы станут слишком большими для того, кто их реализует, мы не сможем обеспечить правильную задержку в реальном времени. Тогда, по моему собственному опыту, TC всегда будет потреблять столько ресурсов процессора, чтобы обеспечить правильное время цикла, поэтому использование внутренней переменной стека на самом деле не является архитектурной ошибкой, но это нормально и желательно, потому что на самом деле TC обеспечивает работу в реальном времени, но не требует должен быть реализован как процесс полного реального времени (реального времени на основе C).
Дискуссия продолжается, и очень интересно, как возникают разные мнения относительно того, следует ли использовать методы или нет в качестве внутренней операции, или мы должны фактически следовать архитектуре FB TC2 Motion, где разные функциональные блоки управляют разными функциональность, и каждый из них имеет ссылку на определенную ось (FB_MOVE, FB_HOME и т. д.)
Не нашел реального ответа на этот вопрос ни в каких документах. Методы почти всегда упоминаются в случае определения интерфейсов, но никогда в случае программирования внутренней функциональности FB.
Итак, можно ли использовать методы для внутренней функциональности, это поможет в будущем при преобразовании FB дыры в интерфейсе, для которого метод init необходимо будет повторно реализовать в зависимости от случая.?
Этот вопрос практически одинаков для новых версий CodeSyS, в которых также есть методы и интерфейсы.
