隨著工業自動化的發展，PLC 驅動程序的設計和開發成為最常遇到的問題。信道利用率和數據采集效率直接影響到整個監控系統的性能。本文討論了設計和開發PLC 驅動程序的方法；詳細介紹PLC 底層驅動函數的設計和實現；并探討了提高信道利用率的幾個關鍵問題。實驗證明，能夠降低開發成本并大大提高計算機監控系統與PLC 之間的數據通信的效率和信道利用率。

1、引言

隨著計算機科學技術、工業控制等方面的新技術的迅速發展，使用計算機監控系統與現場PLC 設備進行數據交換得到了廣泛的應用。這類數據交換往往具有以下的特點，數據量大，采集點分散，帶寬較窄。由于不同廠家所提供的PLC 現場設備的通訊機制并不相同，計算機監控系統軟件需要開發的設備通信驅動程序就越來越多。這種復雜的設備驅動程序的開發具有以下的特點：

首先，上位監控系統與PLC 設備間的數據交換，應用較普遍。

其次，這種數據通訊過程，缺乏有通用性的框架設計，開發周期長，難度大，難以通用。

再者，在有限帶寬限制條件下的大數據量傳輸，普遍存在著信道利用率低，系統效率差，不穩定的情況，迫切需要大幅度提高信道利用率的算法。而且在已有的數據交換標準中，對于有限帶寬條件下的信道利用率也沒有成熟的設計。

如上所述，開發PLC 設備的通用性數據通信接口具有廣泛的應用前景和實現價值。本文主要針對上位監控系統與PLC 設備之間的數據通信進行分析，介紹了PLC 設備的驅動開發的方法，并提供PLC 通信的實例。

2、 PLC 驅動的使用

本文中以使用串口通訊的PLC 為例進行分析和說明，監控系統為北京昆侖通態公司生產的MCGS 監控軟件。開發工具為VC++6.0。

MCGS 中PLC 已經將串口通訊的波特率設置等功能集成至串口父設備中，因此PLC 設備驅動是作為MCGS 監控軟件設備管理窗口中的子設備提供的。它可以使用父設備的通訊功能，即可以與其他設備共享父設備的通訊功能。由于使用串口的PLC 設備較多，在這里我們以使用串口通訊方式的PLC 為例進行說明PLC 通用驅動的構架的開發。如使用自定義編程電纜方式或使用以太網方式連接，此PLC 驅動構架同樣適用。

使用串口通訊的PLC 與上位機的通訊方式中，有RS232、RS485、RS422 多種方式。如果設備是采用RS232 方式通訊，那么在一個串口下面只能掛接一個設備。如果采用RS485 或者RS422 的方式通訊，那么可以使用多個設備構成一個網絡，在這個網絡中，為了識別各個不同的設備，給每一個設備加上一個標志，一般來說把這個標志稱作設備地址。這個總線上的設備分為主設備和從設備兩類。在工作時，從設備一直在監聽通訊線路上的數據，并對這些數據進行分析，當收到對自己的請求時，會發送一個相應的應答幀。主設備在工作時會根據需要向從設備發送請求幀，請求一些數據或者是發送一條命令，在發完請求幀后主設備需等待從設備的回答，這個等待的過程有一個超時時間限制。如果過了一定的時間還沒有收到回答，它會認為本次通訊失敗，然后按照一定的邏輯判斷是應該重發請求還是放棄。

通訊使用的通訊協議，分為ASCII 通訊和16 進制通訊兩類。PLC 的通訊協議中大多數都是使用16 進制通訊。而且在串口通訊中，為了保證通訊的正確性、完整性，通常在通訊幀的尾部加上校驗，常見的有和校驗，異或校驗，CRC 校驗等等。

在通訊過程中，上位機的MCGS 監控軟件調用PLC 驅動，根據具體協議，向PLC 設備發送寄存器的讀寫命令，并接收應答數據。

3 、主要流程

3.1 采集流程

為便于說明，此處以一個采集周期內僅需單次采集的最簡情況為例。在5.1 中的密集采集模式中，描述了對一周期內需多次采集的算法。

采集過程描述如下：首先進行初始化，隨后創建通道。進入數據采集周期，在每個數據采集周期中，首先形成讀命令，隨后校驗發送數據幀，讀寫串口完成一次通訊，如果通訊成功，那么校驗后將接收到的數據解碼輸出到通道，返回成功標識，如果通訊不成功或校驗失敗，返回失敗標識。

3.2 解析函數流程

上圖為解析數據幀的流程圖。不同的設備具有不同的協議內容，使用定義好的模版解析函數只需要開發人員按照設備協議將幀分割為有效的數據部分，添入聯合體FrameField 即可。該聯合體可將協議數據最小分割為位來進行操作。

如上圖所示，第一個字節為幀頭，最后一個字節為幀尾，第二個字節為狀態標示，第三至第六個字節為模擬量，第七個字節為單位，第八個字節按位分為四路輸入和四路輸出。

4 、接口設計

通常來說，一個廠家的同系列的PLC 產品，通訊協議一般是一樣的。區別只是在于其中一些寄存器的大小不同。這樣我們就考慮可以讓這一個系列的設備使用同一個驅動。為了提高通用性，同時一般情況下，用戶也不需要使用所有的寄存器，所以把這種設備構件的通道設計成用戶可以在組態時自己進行定義。所有的通道及其所對應的參數（即是寄存器地址）都由用戶自己進行定義。驅動程序根據用戶定義的信息進行通訊。而且PLC 當中可能有一些參數用戶并不常用，如果組成通道，每一個采集周期都要進行通訊，效率比較低下，考慮到這種情況，我們提供了一些外部接口供監控系統調用，在這些接口中可以發送命令，支持所有的寄存器通道。

而對不同廠家的PLC 設備進行分析，也可以發現，可以將通訊過程和協議方式進行抽象，提取它們的共同點和變化點，封裝和隱藏數據交換過程中的細節，達到通用的目的。通過封裝格式，規范代碼，統一接口，提高驅動開發效率，降低驅動開發的難度。提高代碼的重用性，增強驅動的穩定性，減少設計中容易出現的錯誤。使開發人員把主要的精力放在對設備的熟悉和對協議的分析上，而不是過多地糾纏于編程實現的細枝末節上。

封裝的數據和操作包括：

隱藏一次數據采集中的底層通訊過程（某些設備完成一次采集需要一次以上的發收過程，如西門子S7200）；封裝針對采集點分散的動態采集算法；封裝常用的命令操作；對與監控系統間的交互提供統一的接口；PLC 驅動封裝了底層的通訊過程，只將接口方法暴露在外面，開發人員以統一的方式去調用這個方法，從而保證軟件對客戶的透明性，使開發人員從低層的開發中脫離出來，降低開發的難度。

對驅動的開發人員來說，需要關注的接口僅有以下部分：

定義設備本身的屬性；如地址、實時采集的時間要求等；定義設備的讀寫操作屬性；如通道數量等；通用設計僅提供跟設備協議相關的組包和解包接口，實現過程將由開發人員完成。

5、 關鍵問題分析

為提供信道利用率，提高系統效率，在PLC 的通信框架設計中考慮了幾個關鍵問題。

5.1 三種采集模式

經過對現有的數據交換的分析，將用戶的一般需求擬概括為三種采集模式，即密集采集，按需采集，定時采集。

密集采集模式：在這種情況下，用戶希望能盡量利用物理帶寬，保證最快的采集速度和更新。在這種模式下，理想狀態是設備始終處于采集狀態。采集目前所有激活通道中離需要采集的周期時間最小的通道。保證所有的通道都能獲得采集機會，但是相對與其他模式，在該模式下CPU 占用率會比較高。

按需采集模式：在通訊鏈路需要受控的情況下，比如用戶采用GPRS 進行采集，按流量計費，所以不能進行大量的通訊。這時候通過設置采集模式為按需采集，然后在需要時再調用接口函數啟動單次采集。否則不進行數據采集。

定時采集模式：該模式是在CPU 的占用率和采集速度之間進行折衷的采集框式，保證在用戶設置的通道刷新周期的時間內進行通道的采集，之后直到下一次通道的刷新周期到達再進行下一次采集。

在模塊設計中，采集模式作為設備類的一個屬性，由開發人員根據具體情況，選擇合適的采集模式。不同采集模式的采集算法實現如下：

密集采集執行流程：設置一個采集周期如1000ms。每當開始一個新采集周期時，重新計算采集通道的優先級別。遍歷所有的通道，找出目前優先級最高的通道，進行采集。對通道進行分塊（塊中包含最需要刷新的通道）。進入通訊循環（某些設備進行一次采集至少需要兩次通訊所以需要通訊循環）。發送數據請求并等待回應；根據返回的信息解析出結果，并作相應處理；判斷是否需要下一次采集，如果不需要跳出循環；更新通道和采集標志；繼續發送線程消息啟動下一次采集直到一次通訊循環結束；直到遍歷完所有需采集的通道。

按需采集執行流程：循環對每個通道進行采集，保存采集成功的值，并進行后續處理。定時采集執行流程由定時器觸發，采集流程與密集采集一樣，但在判斷沒有滿足采集要求的通道不進行采集。

5.2 采集點分散的動態采集算法

在現有的數據交換過程中，用戶關心的數據往往只占全部信息的很小一部分，而且這些采集點分散在海量的數據中，如果不加判斷的依次讀取數據，有效信息與采集信息的比例很低，實時性差；如果僅采集有效信息，分配的采集粒度過小，又會造成系統效率低下，信道利用率差。針對這一問題，采取以下的解決方法：

（1）只采集用戶關心的數據。如當有多個通道時，只傳送當前用戶只關心的通道的數據，而不關心其它的通道。保證采集盡量少的通道，為每個需要采集的通道提供更快的采集周期。從而減少通訊量。

（2）對于待采集的數據分配不同的優先級，對實時性要求高的部分數據優先采集?？梢愿鶕脩粼O置的數據刷新時間來改變其優先級。

（3）實現一個動態分塊算法，在一個合理的粒度上對采集的信息分塊傳輸，兼顧信道利用率與有效信息獲取的實時性；實現的分塊算法簡述如下：在采集時判斷，如果當前采集的寄存器類的激活通道可以組成一個數據請求包，則進行處理，提高一次采集的通道數。根據開發人員定義的通道優先級，找出優先級最高的通道地址附近的地址連續（或緊密）的通道，這些通道形成一個通道塊。重復同樣的過程，將剩下的通道繼續分塊，直到形成的塊數大于某一規定的數值比如20 或將本寄存器的所有通道分配完成。

（4）根據通訊協議的特點，在打包數據請求時盡量保證包含更多的請求，從而減少請求的總次數。

6 、結論

根據本文的PLC 通用性數據接口開發人員已開發出多個廠家的PLC 驅動，并在不同項目中得到應用。在此PLC 通用數據接口基礎上開發PLC 驅動，縮短了開發時間和難度。投入運行的系統通信穩定，采集速度快，通用性好，可靠性高。保證了項目的順利實施。本文作者創新點：具有通用性的監控系統與PLC 通信接口設計，能夠大大縮短開發時間和難度，并提高通信穩定性、實時性，具有很高的實用價值和經濟價值。