【发布时间】：2017-08-21 12:50:46
【问题描述】：
我是 Beckhoff 技术的老用户，尤其是 TwinCAT。目前，由于 TwinCAT 3（面向对象）带来的新功能，我们的 PLC 架构正在经历一场变革
目前，我们正在开发新的 PLC 架构，并且我们对如何前进有几个担忧。目前引起我们注意的一个很好的例子是新方法以及与操作的总体差异。
从我自己的角度来看，创建方法不仅是为了定义和实现接口，也是为了简化 FunctionBlock 及其内部状态机。例如，如果我有一个内部有自己的状态机的 FB_Conveyor，我可以选择为传送带创建内部方法 (M_INIT)，它将检查传送带以检查传送带处于 INIT 状态时是否有任何产品，检查方法输出值。 MEthod 将包含其获得的状态机，并且在其输出返回 TRUE 值之前不会准备好。
第一个问题来了，因为我们的一些实时程序员认为方法并没有为此完成，在这种情况下，我们应该实现从 FB_CONVEYOR 调用的 FB_INIT，它包含自己的变量，所以两者都有参考 FB_MOTOR。
主要论点是 METHODS 是一种用于创建接口和控制 FB 的工具，例如，我自己的 FB_CONVEYOR 可以从具有方法 M_TakeIn 的 I_Conveyor 扩展而来，但不用于实现内部功能作为初始化它.
还有一个论点是方法使用自己的堆栈变量，因此方法的所有数据都是临时的，并且仅在执行期间有效。这意味着，如果实现它的方法太大，我们将无法确保实时的正确延迟。然后根据我自己的经验，TC 总是会占用尽可能多的处理器资源来确保正确的循环时间，所以使用内部堆栈变量实际上并不是一个架构错误，但它是可以和可取的，因为实际上 TC 确保实时操作但不需要被实现为一个总实时（基于 C 的实时）过程。
讨论一直在进行，对于是否应该将方法用作内部操作或者我们是否应该实际遵循 TC2 Motion FB 的架构（其中不同的功能块控制不同的功能，每个功能共享一个对某些轴的引用（FB_MOVE、FB_HOME 等）
在任何文档中都没有找到任何真正的答案，在定义接口的情况下几乎总是提到方法，但在编程内部 FB 功能的情况下却从未提及。
那么，是否可以将方法用于内部功能，这将有助于将来在接口中转换孔 FB 时需要根据情况重新实现方法 init。？
对于同样具有方法和接口的新版本 CodeSyS，这个问题几乎相同。
【问题讨论】：