我是Beckhoff技术的老用户，尤其是TwinCAT。目前，由于TwinCAT 3（面向对象）带来的新功能，我们正在对PLC架构进行改造
目前我们正在开发新的PLC架构，我们对如何前进有几个问题。目前几乎引起我们注意的一个非常好的例子是新方法和与行动的总体差异。
从我自己的角度来看，创建方法不仅是为了定义和实现接口，还是为了简化FunctionBlocks及其内部状态机。例如，如果我有一个FB_Conveyor，里面有自己的状态机，我可以选择为输送机创建内部METHOD（M_INIT），检查输送机，以检查输送机处于INIT状态时是否有任何产品，检查Method输出值。 MEthod将包含其获胜的状态机，并且在输出返回TRUE值之前不会就绪。
第一个问题来到这里，因为我们的一些实时程序员的意见是没有为此完成方法，在这种情况下我们应该实现从FB_CONVEYOR调用的FB_INIT，它包含自己的变量，所以两者都有REF到FB_MOTOR。
主要论点是，METHODS是一个工具，用于创建接口和控制FB，例如，我自己的FB_CONVEYOR可以从具有方法M_TakeIn的I_Conveyor扩展，但不用于实现内部功能，因为初始化它
一个参数也是Method使用自己的堆栈变量，因此方法的所有数据都是临时的，并且只在执行期间有效。这意味着如果实现它的方法过大，我们将无法确保实时的正确延迟。然后根据我自己的经验，TC将始终占用处理器的尽可能多的资源以确保正确的周期时间，因此使用内部堆栈变量实际上并不是架构错误，但它确实可取，因为实际TC确保实时操作但不需要实现为全实时（基于C的实时）过程。
讨论一直在进行，并且非常感兴趣的是，如果将方法作为内部操作使用或不作为内部操作，或者我们是否应该实际遵循TC2 Motion FB的架构，不同的功能将如何产生不同的意见块控制不同的功能，每个功能共享一个轴（FB_MOVE，FB_HOME等）
在任何文档中都没有找到任何真正的答案。在定义接口的情况下几乎总是提到方法，但从不编写内部FB功能的情况。
那么，是否可以将方法用于内部功能，这将有助于将来在根据情况需要重新实现方法init的接口中转换孔FB时。？
对于新版本的CodeSyS来说，这个问题几乎是一样的，它们也有方法和接口。
答案 0 :(得分：1)
你几乎已经明白了这一点，但是长话短说，PLC中的功能块定义了一般的“功能”类。该类将具有某些输入和输出，以及操作它们的方法/操作。必须创建功能块的实例才能使用这些方法。该实例只要程序执行就会持续，然后删除（PLC停止）。
在新的TwinCAT和CodeSys中，已经使用方法扩展了操作。这些方法有自己的输入和输出变量以及操作它们的代码。可以使用此功能来分离（更好地模块化）他/她的代码，并在需要时执行它。
在这里阅读更多相关信息： http://infosys.beckhoff.com/content/1033/tc3_plc_intro/html/pou_method.htm
答案 1 :(得分：1)
方法与Action不同，主要是因为它有自己的声明。
默认情况下，方法中的所有变量都是VAR_TEMP类型，这意味着它们只会在运行期间存在。所以每个周期都会被重置。
VAR_TEMP使用有限的堆栈空间和大型数据类型不能这样声明。
但是你可以在方法中声明任何类型的变量。与VAR_INST类似，因为它是在FB（功能块）级别（FB中的默认变量）创建的，因此每个实例都是私有的。或者，您可以声明对所有实例都通用的VAR_STAT。方法可以使代码更清晰。
Method和Action都可以使用它的FB中的所有变量。
可以使用与FB不同的编程语言开发方法和操作。示例：FB使用ST编写，但它的方法或操作可以用梯形图编写。
我个人认为Method存在与Interface之间没有联系。我不会急于使用OOP提供的所有功能。如果不明智地使用，继承，接口和属性可以使您的程序成为一场噩梦。虽然TwinCAT中的封装充其量是虚拟的。
编辑：
在Program中创建Method（TwinCAT中的静态对象）时，无法在此方法中创建VAR_INST，因为Program中不存在任何实例。只有VAR_STAT和VAR_TEMP可以在程序的方法中使用。它与其他无法实例化静态类的编程语言非常相似，它们的变量也只能是静态的。
答案 2 :(得分：0)
我使用方法作为接口，并将功能块代码分成较小的部分。
例如，我有一个记录器块，它将给定的字符串写入日志文件。它也可以将该日志读取到PLC阵列。
该块看起来像这样：
<强> FB_Logger
功能块本身也有一些在每个循环中调用的代码。
我以非常丰富的方式使用这些OOP功能。有时我会向PROGRAM添加方法以使其更清晰。在我有一个功能块和五个辅助函数之前，现在我有一个带私有方法的功能块。
试试吧！