PLC程序的解耦

        在PLC编程这个领域中探讨的帖子比较多，我的前几篇帖子都偏重PLC编程的基础知识。这一篇换个打法，我们探讨稍微有些虚的话题，程序解耦。

        干聊程序解耦就太抽象乏味了。本贴通过一个具体例子来探讨和体会程序的解耦问题。这个例子与上一个帖是一个项目。上一个帖的链接如下

【1500实用FC系列】之三，判断BUFFER中数据是否更改-CSDN博客

1. 需求

                这里简单介绍一下项目中一个需求。项目要控制5个ModbusRTU通讯的伺服小电机。这个电机虽然是RTU通讯，但是内核是CanOpen。

项目的思路是用1个西门子PLC中ET200SP的PTP模块连接5个小伺服电机。要求通过通讯对电机进行控制。

        分析一下需求，很容易把以上的要求划分为2大块功能：

1.        电机通讯功能；

通讯的功能包括单个电机的通讯功能、各个电机的轮询功能、通讯异常处理功能、是否写数据判断功能（这在上一帖中探讨的）。

2.        电机控制功能。

电机控制功能包括电机启停、回零以及多个电机协调运行功能。

2. 构思

        在构思程序时，我的设想是将这2块功能的代码解耦。

        解耦的目的就是要将2大功能各自编写代码，互不干扰。在电机控制代码模块中，代码专注于：如何控制电机；电机如何回零；如何协调电机之间的动作；不操心电机通讯的问题。同样在电机通讯模块中，代码关注如何通讯；如何轮询；如何缩短轮询周期；如何提高通讯强壮性；不关心电机控制的问题。

3. 详解

        本项目是按照以上解耦思路进行代码的编写。

图1

        电机通讯模块在图1中83目录中，电机控制模块在71目录中。这2个模块的代码通过数据通道进行耦合，除此以外没有任何代码的关联，这就实现了解耦的目的。

3.1 数据通道

        先看看数据通道，数据通道在图2中展示

图2

注：虽然小伺服电机是MODBUSRTU通讯接口，但电机内部是CANOPEN的架构，所以熟悉CANOPEN的同行看着很眼熟。

        图2中总共有7个数据通道，每个电机占用一个数据通道（另外2个通道做预留）。电机和数据通道可以任意分派。每个数据通道包含一个伺服电机读写数据及控制数据，控制数据包括：

Enable：本通道是否使用

ComOK：本通道通讯状态

Addr：本通道对应的modbus地址

        前文介绍过数据通道是2个代码模块唯一连接点。下面分别介绍电机通讯代码模块和电机控制模块。

3.2 电机通讯模块

        在通讯模块中（图1中的83文件夹），FB29中编写代码如图3

图3

        图3中，先说明通道与通讯的关系。

        每个通道都如NETWORK5。以通道1为例。

        如图3中的红框内，需要将数据通道1与FB(PollingTriger_Modbus_RW_PDO_Nimotion)的一个实例做连接，这样就完成了通道1的数据与伺服电机进行通讯。

        程序中配置了7个通道。所以共有7个FB(PollingTriger_Modbus_RW_PDO_Nimotion)实例。每个实例对应一个通道。这些实例之间是轮询关系。7个实例的轮询号码是：100、200..700。

        在这个电机通讯模块中，除了有单个电机的通讯代码和轮询代码外，还有初始化代码（NETWORK1）、PTP端口配置代码（NETWORK2）、异常处理代码（NETWORK4）。总之凡是与通讯有关的代码都在图3中。

3.3 电机控制模块

        前面探讨了电机通讯模块的编程。另外一方面，在电机控制模块中（图1的71文件夹），如图4

图4

         在图4中，FB15内部是工艺名称为TRANSFER伺服电机的工艺控制代码。将这个工艺电机的控制与通道1通过红框的方式做了连接，连接后就实现了TRANSFER伺服电机的控制通过数据通道1与通讯模块的代码进行了耦合。换句话说：在电机控制模块内部，将TRANSFER的过程数据传输给通道1，电机通讯模块将通道1中的过程数据通过通讯程序与电机做数据交换。在FB15中，我们可以编写代码控制电机启停、复位、回零等工艺动作。

        其他工艺电机如LIFT1,LIFT2,RT的情况也是如此。

4. 解耦的好处

        以上介绍了例子项目中如何实现电机控制模块和电机通讯模块的代码解耦，以及模块之间的数据耦合。

        这种解耦的程序架构有什么好处呢？

1. 使得程序看起来简洁，易于分块，条理清晰，层次分明。
2. 2个模块无程序之间的耦合。2个模块在独立开发过程中，无需考虑对方模块的任何内容，每个模块只要专注自己模块的开发。容易实现多人共同开发。
3. 易于移植。电机通讯模块可以认为是底层基础模块。电机控制模块是高层工艺应用模块。底层模块可以轻松移植到其他项目中，缩短了项目开发周期。每个项目不同之处只在于高层工艺模块。
4. 调试方便。以电机通讯模块为例，只要有2个电机通讯正常，那么可以肯定电机通讯模块就不会存在BUG。如果出现问题，那么在电机控制模块中找BUG。
5. 模块更换简单。如果未来伺服电机不用MODBUSRTU通讯而改用CANOPEN通讯，那么无需修改电机控制模块中的任何内容，只需修改电机通讯模块中的一少部分内容即可完成整个程序的修改。

        既然解耦的程序架构有这些好处。我们在构思一个新的PLC程序架构时应优先考虑解耦的架构。

5. 解耦的手段

        在本例中，我们利用了博途提供的数据接口实现解耦。

        在其他开发环境下，如SIMATIC AX开发环境和CODESYS开发环境都提供OOP开发。OOP开发环境都支持函数的接口。函数接口和数据接口都为程序的解耦提供了很好的工具方法。本贴探讨了数据接口的手段实现解耦。下面帖子探讨了OOP中的接口手段实现解耦。

PLC的面向对象编程（OOP）探秘9-接口的应用与原理揭秘_plc面向对象编程-CSDN博客

6. 解耦在程序标准化中的作用

        解耦是一种程序架构。谈到程序架构也容易联想到程序的标准化。程序的标准化也是当下的热门话题。其中一个问题是PLC程序为什么要标准化？如何标准化？我觉得，程序解耦是一个重要的优化方向。

7. 小结

        好了，关于PLC程序的解耦先谈这些了，做个小结。

        本篇通过一个例子讨论了程序解耦的一种方法。这只是抛砖引玉。希望各位同行也谈谈自己对程序解耦的体会。

博途项目：

        如果有需要本博途项目的，在跟帖中留下邮箱。

通讯编程：

        本帖专注于PLC程序解耦的探讨，关于通讯编程的探讨（如通讯信号联锁、通讯轮询、通讯异常处理等）不在本贴关注的范围。如果想对通讯编程有更多的了解，可以浏览我的通讯编程系列帖，连接如下：

https://blog.csdn.net/yangSimaticTech/article/details/155999690?spm=1001.2014.3001.5502