1、PLC编程，与外部构建以太网联接，通过收发指令进行数据交换

　　在工业的信息化、智能化，甚至工业4.0的大潮中，很多中级算法都是由上位机、云来实现，那么PLC数据采集是最基本的前提条件之一。

　　面对这些需求，新的PLC大都开始支持以太网（以前的并口局限性很大了，速度慢，出错机率高），有的甚至在CPU上直接设置以太网插口，编程，数据传输，都可以通过这个端口来搞定，不再须要降低一个以太网插口卡。

　　硬件有了，要实现数据的采集，还须要软件，从软件上来说，实现方法大约有以下几种：

　　1、PLC编程，与外部构建以太网联接，通过收发指令进行数据交换：

　　为了实现这些方法，可能须要通过硬件配置来构建联接通道，然后再由用户自己编程进行收发。要想顺利完成这些通信和调试，需要一位既懂计算机编程，又懂PLC编程调试的人员，否则，经常鸡同鸭讲，困难重重。

　　在调试完毕后，如果想再降低一个变量，从上到下全部须要更改，那个酸爽呀！

　　这种方法尽管施行困难，但是每次发送的数据量大，速度快。以西门子为例，标准的以太网通信，一次可以发送8000字节，但是用非编程的方法，可能只有200多字节（因PLC的机型而不同）。另外，电文发送是由PLC程序控制，节奏可控。iba PDA的一个重要的高速数据采集模式就是这样的（在PLC内部进行编程，只不过，人家将模块给你打算好，你组织数据，进行调用即可）。

　　2、PLC提供不需要编程的外部访问合同，比如，OPC-UA、MODBUS TCP等:

　　OPC-UA是目前比较火的开放合同，被工控界宣传得神乎其神，实际情况却是：困难重重。首先，PLC的OPC-UA合同不是随意用的，要订购授权。啊！不免费？不免费！其次，OPC-UA客户端这么容易实现吗？OPC-UA合同堪称免费，但是，你若果真对着厚厚的合同文本，从底层开始开发。如果能真的搞定了，那绝对就是通信大鳄，不需要在悲催的工控圈混了。如果没有这个实力，就要再度掏银子去选购他人的SDK进行二次开发，貌似也不实惠。OPC-UA控制得比较严，目前还没有哪家敢用和谐版的SDK来公开做项目，做产品。

　　那么，就用MODBUS TCP吧！这个是免费的、古老的合同。不错，免费，但是也须要在PLC里进行编程、配置（比如，西门子PLC，需要自己调用MODBUS TCP库，配置好资源，才能使用。但是，有些PLC原生支持该合同，比如施耐德PLC，就可以直接用。另外有一些PLC须要进行配置，启用该功能，也不需要编程施行）。但是，该合同兼容性不一定好，有很多变化，比如地址是否从0开始，高低自己是否颠倒等。另外，我的一个项目里就遇见过一个奇怪的问题：西家1500PLC，通过CP网卡如何都难以和老的INTOUCH进行通信，通过CPU上的网口就没有问题。由于CPU上的网口还须要做控制环网，后来只得更换了多网口的CPU，解决了问题，这不需要成本吗？。现场的技术专家、西家的技术支持都不相信这个事实“MODBUS TCP就是加载在标准以太网合同之上而已，CP没有理由转不过去呀！”

　　3、通过通信中间件或则中间软件进行中转

　　如果以上都不能搞定，就只得用通信的中转软件了。最典型的就是OPC软件，一端访问PLC，另外一端对外提供数据。OPC软件有的是厂家提供，有的是第三方，曾经大行其道，可惜，从效率、安全性、系统兼容性上看，OPC软件逐渐过时了。另外，某些厂家的OPC软件可不实惠了。

　　除了OPC，还有专业的中间软件，比如KEP某甲，那是真专业，可同时访问的PLC和合同特别多，对外提供数据的途径也好多，OPC、OPC-UA等等。但是，一套配置出来，要好几万RMB就能搞定。另外，对外的合同，依然是个问题。

　　国内下来一个小软件PLC-Recorder，用于专业录波（支持大部分主流PLC，自带驱动库，体积极小，可在好多场合代替PLC-Analyzer或iba软件，具体可参考链接），最近顺手降低了数据转发功能，并且用了兼容性极强的WebScoket合同和Json数据通信格式。客户端开发十分简单，用一个web页面能够搞定用户验证、订阅、实时数据刷新等功能。如果用中级语言（比如C#、Java等）开发，能实现愈发丰富的功能。官网上有转发合同文本及客户端源代码可以参考。该软件目前功能还在不断丰富，稳定性在逐渐提升，另外一个巨大优势：便宜。

　　2020年7月9日发，7月21日改