之前2篇实用FC的帖效果都不错。今天再分享一个实用FC。

    今天说的这个FC用于判断buffer中的数据是否更改了。为什么开发这个小FC呢，今天就说说这事。

    事情源于一个小项目。小项目包括5个24V供电的小伺服电机。电机内核是CANOPEN协议。但是可以用modbusRTU写入控制字和读取状态字。于是我用了ET200SP的PTP模块与这些小电机做硬件上的RS485连接。用“Modbus_Master”指令向每个电机读写数据。项目可以顺利的运行，通讯也没    有什么问题。在这个小项目中每个电机用2个“Modbus_Master”指令与伺服电机对话，一个用于读伺服数据，另一个用于写数据。5个电机需要10个“Modbus_Master”指令。在程序中编写了代码用于统计耗时，每个“Modbus_Master”指令大约耗时50-70毫秒。那么整个轮询就需要500-700毫秒，这意味着每个电机的读写和控制的间隔时间接近1秒。在上位软件中经常能感觉到点击运行指令后的延迟。人机的体验很不好。为此我思考有什么办法可以缩短轮询时间。

    CANOPEN通讯有个特点。每个CANOPEN通讯点都可以保存接收到的数据，并且在下次接收数据之前始终保持这些数据。这个特点意味着，只要控制字不变化，就无需每个轮询周期都向伺服电机写控制字。为此在PLC程序中需要判断这次向伺服电机写的控制字与上一次是否相同，如果相同那么就无需调用“Modbus_Master”指令向伺服电机写数据。于是就有了本贴中这个主题FC。

图1

    图1是这个FC Judege_DataChenged的引脚图。

        Buffer_This中给出这次需要向伺服电机写的数据。

        Buffer_Pre是一个buffer，存储上一次向伺服电机写的数据。

        Count_Word告知这个FC需要比较buffer中多少个字。注：因为modbus是以字为单位发送和接收数据的。如果需要我们也可以将之更改为byte。

        Changed代表buffer中的数据更改了。

    图2给出这个FC的内部代码

图2

    然后我们说说在这个项目中如何使用这个块。

图3

    图3是一个FB(PollingTriger_Modbus_RW_PDO_Nimotion)的内部代码。每个FB的实例都会被赋予一个轮询号码。当轮询到这个FB实例时，执行这个FB中的代码。每个轮询号码代表一个电机。也就是当轮询号码等于本FB实例的轮询号码时，就会执行本FB中的任务。任务中首先读取该伺服电机的数据。这在NETWORK1中执行。

    在NETWORK2中，如果能正常读取伺服的数据，那么执行2个FC（FC1,FC18）。通过“Buf_<>PDO”块将读取的数据放到“#INTF_PDO_RW.Read”数据区中，供高层代码使用，同时这个块还负责将高层代码需要写入的数据（#INTF_PDO_RW.Write）放入到“buffer_MB_This”中。然后通过FC Judege_DataChenged判断高层代码写入的数据是否更改。如果更改了，那么在NETWORK3中执行向伺服电机写入的任务。如果没有更改，则免去执行写入的任务。

    以上就是使用FC Judege_DataChenged块的情况。

    对5个电机在程序中添加了数据更改的判断后，整体的轮询时间缩短近一半，平均轮询时间在300-400毫秒左右。在上位机点击运行也没有延迟感了。

    以上就是本主题要分享的FC(Judege_DataChenged)块。 

    总结：本篇给出了一个实用小FC，该FC可以判断缓冲区中的数据是否被更改了。