PLC數(shù)據(jù)采集的實現(xiàn)方法

　　在工業(yè)的信息化、智能化，甚至工業(yè)4.0的大潮中，很多高級算法都是由上位機、云來實現(xiàn)，那么PLC數(shù)據(jù)采集是最基本的前提條件之一。

　　面對這種需求，新的PLC大都開始支持以太網(wǎng)（以前的串口局限性太大了），有的甚至在CPU上直接設置以太網(wǎng)接口，編程，數(shù)據(jù)傳輸，都可以通過這個端口來搞定，不再需要增加一個以太網(wǎng)接口卡。

　　硬件有了，要實現(xiàn)數(shù)據(jù)的采集，還需要軟件，從軟件上來說，實現(xiàn)方式大概有以下幾種：

　　1、PLC編程，與外部建立以太網(wǎng)連接，通過收發(fā)指令進行數(shù)據(jù)交換：

　　為了實現(xiàn)這種方式，可能需要通過硬件配置來建立連接通道，然后再由用戶自己編程進行收發(fā)。要想順利完成這種通訊和調(diào)試，需要一位既懂計算機編程，又懂PLC編程調(diào)試的人員，否則，經(jīng)常雞同鴨講，困難重重。

　　在調(diào)試完畢后，如果想再增加一個變量，從上到下全部需要修改，那個酸爽呀！

　　2、PLC提供不需要編程的外部訪問協(xié)議，比如，OPC-UA、MODBUSTCP等：

　　OPC-UA是目前比較火的開放協(xié)議，被工控界宣傳得神乎其神，實際情況卻是：困難重重。首先，PLC的OPC-UA協(xié)議不是隨便用的，要購買授權(quán)。?。〔幻赓M？不免費！其次，OPC-UA客戶端那么容易實現(xiàn)嗎？OPC-UA協(xié)議號稱免費，但是，你如果真的從底層開始開發(fā)，如果能真的搞定了，那絕對就是通訊大佬，不需要在苦逼的工控圈混了。如果沒有這個實力，就要再次掏銀子去購買別人的SDK進行二次開發(fā)，貌似也不便宜。OPC-UA控制得比較嚴，目前還沒有哪家敢用和諧版的SDK來公開做項目，做產(chǎn)品。

　　那么，就用MODBUSTCP吧！這個是免費的。不錯，免費，但是也需要在PLC里進行編程、配置（那些原生支持的除外，比如施耐德PLC），并且對下兼容不一定好（我的一個項目里就遇到過，西家1500PLC，通過CP網(wǎng)卡就是無法和老的INTOUCH進行通訊，通過CPU上的網(wǎng)口就沒有問題。由于CPU上的網(wǎng)口還需要做環(huán)網(wǎng)，后來只好更換了多網(wǎng)口的CPU，解決了問題，這不需要成本嗎？）?，F(xiàn)場的技術(shù)專家、西家的技術(shù)支持都不相信這個事實“MODBUSTCP就是加載在標準以太網(wǎng)協(xié)議之上而已，CP沒有理由轉(zhuǎn)不過去呀！”

　　3、通過通訊中間件或者中間軟件進行中轉(zhuǎn)

　　如果以上都不能搞定，就只好用通訊的中轉(zhuǎn)軟件了。最典型的就是OPC軟件，一端訪問PLC，另外一端對外提供數(shù)據(jù)。OPC軟件有的是廠家提供，有的是第三方，曾經(jīng)大行其道，可惜，從效率、安全性、系統(tǒng)兼容性上看，OPC軟件逐步過時了。另外，某些廠家的OPC軟件可不便宜了。

　　除了OPC，還有專業(yè)的中間軟件，比如KEP某某，那是真專業(yè)，可同時訪問的PLC和協(xié)議非常多，對外提供數(shù)據(jù)的途徑也很多，OPC、OPC-UA等等。但是，一套配置下來，1萬RMB能搞定嗎？另外，對外的協(xié)議，依然是個問題。

　　國內(nèi)出來一個小軟件PLC-Recorder，用于專業(yè)錄波（支持大部分主流PLC，自帶驅(qū)動庫，體積極小，可在很多場合替代PLC-Analyzer或iba軟件），最近順手增加了數(shù)據(jù)轉(zhuǎn)發(fā)功能，并且用了兼容性極強的WebScoket協(xié)議和Json數(shù)據(jù)通訊格式。客戶端開發(fā)非常簡單，用一個web頁面就能搞定用戶驗證、訂閱、實時數(shù)據(jù)刷新等功能。如果用高級語言（比如C#、Java等）開發(fā)，能實現(xiàn)更加豐富的功能。官網(wǎng)上有轉(zhuǎn)發(fā)協(xié)議文本及客戶端源代碼可以參考。