本文討論了可編程控制器驅動程序的設計和開發方法。詳細介紹了PLC底層驅動功能的設計與實現；并討論了提高渠道利用率的幾個關鍵問題。實驗表明，它可以降低開發成本，大大提高計算機監控系統與可編程控制器之間數據通信的效率和通道利用率。

1.介紹

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

首先，上層監控系統與PLC設備之間的數據交換被廣泛使用。

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

此外，在帶寬有限的大量數據傳輸中，信道利用率低，系統效率差且不穩定，迫切需要大幅提高信道利用率的算法。而且，在現有的數據交換標準中，對于有限帶寬條件下的信道利用沒有成熟的設計。

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

2.可編程控制器驅動程序的使用

本文以采用串行通信的可編程控制器為例進行分析和說明。監控系統為北京昆侖同泰公司生產的MCGS監控軟件。開發工具是VC++6.0。

在MCGS，PLC已經將串行通信的波特率設置等功能集成到串行父設備中，因此在MCGS監控軟件設備管理窗口中，PLC設備驅動程序作為子設備提供。它可以使用父設備的通信功能，即它可以與其他設備共享父設備的通信功能。由于使用串口的PLC設備很多，這里我們以使用串口通信的PLC為例來說明PLC通用驅動程序架構的開發。如果使用用戶定義的編程電纜或以太網連接，該可編程邏輯控制器驅動框架也適用。

PLC與上位機之間采用串行通信，通信方式有RS232、RS485和RS422三種。如果設備通過RS232通信，在一個串行端口下只能連接一個設備。如果使用RS485或RS422進行通信，可以使用多個設備組成一個網絡。在這個網絡中，為了識別不同的設備，每個設備都添加了一個符號，通常稱為設備地址。該總線上的設備分為主設備和從設備。在工作中，從設備一直在監控和分析通信線路上的數據，當它收到自己的請求時，會發送相應的響應幀。當主設備工作時，它會向從設備發送請求幀，請求一些數據或根據需要發送命令。發送請求幀后，主設備需要等待從設備的應答，這個等待過程有超時限制。如果你過了一定時間還沒有收到回復，它會認為這次溝通失敗了，然后按照一定的邏輯判斷是重發請求還是放棄。

用于通信的通信協議分為ASCII通信和十六進制通信。PLC的通信協議大多采用十六進制通信。而且在串行通信中，為了保證通信的正確性和完整性，通常會在通信幀的末尾增加一個校驗，包括和校驗、異或校驗、CRC校驗等。

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

3.主要過程

3.1收集過程

為了便于解釋，這里是一個采集周期只需要一次采集的最簡單情況。在5.1的集采模式中，描述了一個周期多次集采內需的算法。

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

3.2分析功能流程

上圖是解析數據幀的流程圖。不同的設備有不同的協議內容。要使用已定義的模板解析函數，開發人員只需根據設備協議將框架劃分為有效的數據部分，并將其添加到聯合體FrameField中。聯合體可以最低限度地將協議數據分成位進行操作。

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

4.接口設計

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

通過分析不同廠家的PLC設備，我們還可以發現，我們可以抽象出通信過程和協議模式，提取它們的共同點和變化點，并在數據交換過程中封裝和隱藏細節，從而達到通用的目的。通過封裝格式、標準化代碼和統一接口，提高了驅動開發的效率，降低了驅動開發的難度。提高代碼的可重用性，增強驅動的穩定性，減少設計中容易出現的錯誤。讓開發人員專注于設備的熟悉度和協議的分析，而不是過分糾結于編程實現的細節。

封裝的數據和操作包括:

隱藏數據采集中的底層通信過程(一些設備需要發送和接收多次才能完成數據采集

程，如西門子s 7200)；封裝針對分散采集點的動態采集算法；封裝常見的命令操作；提供與監控系統交互的統一接口；PLC驅動封裝底層通信過程，只暴露接口方法，開發人員統一調用此方法，保證軟件對客戶的透明性，使開發人員與底層開發分離，降低開發難度。

對于驅動程序開發人員來說，需要注意的接口只有以下幾個部分:

定義設備本身的屬性；如地址、實時采集的時間要求等。定義設備的讀寫操作屬性；比如頻道的數量；總體設計只提供了與設備協議相關的打包和解包的接口，實現過程將由開發者完成。

5.關鍵問題分析

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

5.1三種采集模式

在分析現有數據交換后，將用戶的一般需求歸納為三種采集模式，即集約采集、按需采集和定時采集。

密集采集模式:這種情況下，用戶希望充分利用物理帶寬，保證最快的采集速度和更新。在這種模式下，理想狀態是設備始終處于采集狀態。目前，收集所有活動通道中周期時間最短的通道。保證所有通道都能獲得采集機會，但相比其他模式，這種模式下的CPU利用率會更高。

按需采集模式:在通信鏈路需要控制的情況下，比如用戶使用GPRS按照流量進行采集和收費，無法進行大量的通信。此時將采集模式設置為按需采集，需要時再調用接口函數開始單次采集。否則，不執行數據收集。

定時采集模式:該模式是一種折衷CPU占用率和采集速度的采集幀，保證在用戶設置的通道刷新周期內可以進行通道的采集，然后進行下一次采集，直到下一個通道刷新周期到來。

在模塊設計中，采集方式是設備類的一個屬性，開發者根據具體情況選擇合適的采集方式。不同采集模式的采集算法實現如下:

密集采集執行流程:設置采集周期，如1000毫秒。每當新的采集周期開始時，采集通道的優先級被重新計算。遍歷所有渠道，找出目前優先級最高的渠道，收集。阻塞通道(這些塊包含最需要刷新的通道)。進入通信周期(有些設備一次采集至少需要兩次通信，因此需要通信周期)。發送數據請求并等待響應；根據返回的信息分析結果并做出相應的處理；判斷是否需要下一次收購，如果不需要跳出周期；更新頻道和采集標志；繼續發送線程消息以開始下一次收集，直到通信周期結束；直到所有要收集的通道都被遍歷。

按需采集執行流程:循環采集各通道，保存采集成功的數值，并進行后續處理。定時采集執行過程由定時器觸發，采集過程與密集采集相同，但不滿足采集要求的通道不進行采集。

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

在現有的數據交換過程中，用戶關心的數據往往只占總信息的一小部分，這些采集點分散在海量的數據中。如果不加判斷地依次讀取數據，有效信息與采集信息的比例很低，實時性差。如果只收集有效信息，分配的收集粒度過小，會導致系統效率低，信道利用率差。為了解決這個問題，采用了以下解決方案:

(1)只收集用戶關心的數據。如果有多個頻道，只傳輸當前用戶只關心的頻道的數據，其他頻道不關心。確保盡可能少的通道，并為每個需要收集的通道提供更快的收集周期。從而減少了流量。

(2)對待采集的數據賦予不同的優先級，對一些實時性要求較高的數據給予優先級。優先級可以根據用戶設置的數據刷新時間進行更改。

(3)考慮信道利用率和有效信息獲取的實時性，實現動態分塊算法，以合理的粒度對收集的信息進行分塊和傳輸；分塊算法的實現簡述如下:采集時，判斷當前采集的寄存器類的活動通道如果能形成數據請求包，則進行處理，增加一次采集的通道數。根據開發者定義的通道優先級，在優先級最高的通道地址附近找出地址連續(或接近)的通道，這些通道組成一個通道塊。重復相同的過程，并繼續阻塞剩余的通道，直到形成的塊數大于指定值(如20)或分配了該寄存器中的所有通道。（初學者可以結合PLC視頻教程來新學習。）

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

6.結論

根據本文中PLC的通用數據接口，開發人員開發了多家廠商的PLC驅動程序，并在不同的項目中得到應用。基于該PLC通用數據接口開發PLC驅動程序，縮短了開發時間和難度。該系統投入運行后，通信穩定，采集速度快，通用性好，可靠性高。確保項目順利實施。作者的創新點:監控系統與PLC通信接口的通用化設計，可以大大縮短開發時間和難度，提高通信穩定性和實時性，具有較高的實用價值和經濟價值。

審核編輯：符乾江