?

　　本文針對自動抄表系統結構，通過一系列方法來提高上位機軟件的可靠性，從而協調和下位機(硬件)數據及命令的交互。上位機采用Visual Basic 6.0編程工具，采用MSComm控件實現與通訊控制器的通訊。

　　1幀格式的設計

　　要保證數據的正確性和可靠性，必須設計一種盡可能避免錯誤出現的幀格式，我們以01H作為幀起始碼(SOH)，以04H作為幀結束碼(EOT)。在幀內的數據中也有可能出現01H和04H，必須加以替換以區別幀頭和幀尾。文中以DLE+‘x’來代替SOH(01H)，以DLE+‘y’來代替EOT(04H)。此時會出現一個問題，即如何區分數據區中的DLE與替換后出現的DL E;這就必須對數據DLE(10H)再進行替換，以DEL+‘z’來替換DLE，此時所有情況的替換結束。這既能很容易識別出一幀數據，又避免了因數據區中出現特殊字符而導致錯誤數據的出現，再結合奇偶校驗，從而進一步保證了傳輸數據的可靠性。

　　對上位機發送的數據，要先替換后校驗;而對于下位機傳上來的數據，要先校驗再反替換，這是為了保證上位機和下位機在通訊線路中都不出現特殊字符SOH、EOT和DLE而設計的規定。反替換流程相當于替換流程的逆，在此就不再累述了。

　　2串口問題

　　因為本系統的上位機是通過RS232轉RS485與下位機進行通訊的。所以，串口通訊的可靠性直接關系到整個系統的可靠性。而串口的使用借助于Visual Basic 6.0中的MSComm控件。MSComm控件是通過OnComm事件來觸發的，觸發的時機由CommEvent的屬性Rthreshold決定。當設定Rthreshold=1時，即緩沖區每接受到1個字符就引發一次OnComm事件;當設定Rthreshold=10時，即緩沖區每接收到10個字符就引發一次OnComm事件。因考慮到前面的替換問題，每一幀的長度是無法預測的，但根據通訊規程可以知道最短幀的長度。我們采用最少數據長度(沒有任何替換)作為Rthreshold的值。這雖然可以保證對上傳數據的及時響應但無法保證獲得一個完整的幀。當使用此語句讀串口時若接收的數據沒經過任何替換則可接收到完整一幀，否則數據幀不全。解決的方法是在讀串口前加延時以保證讀入數據完全，至于延時的處理不建議用循環語句來實現，這將增加調試的難度，最好的方法是調用API函數Sleep：

　　Sleep()中時間以毫秒作為最小時間單位，a值的選取必須通過多次調試才能獲得最佳效果。另外，為了防止MSComm控件串行通訊問題，在發送讀串口命令時通過啟用定時器處理程序來捕獲串口通訊異常。這些方法可以最大程度的減少因通訊方面的問題而引發的錯誤。

　　3整體抄表問題

　　自動抄表系統的優點在于它既可以對單一用戶又可以對所有用戶的水、電、氣三表進行讀數而不需人工干預。單一抄表比較簡單;但在整體抄表過程中會出現因連續、快速的讀數導致硬件的采集速度與上位機的讀數速度不匹配，或因串口事件處理函數未結束而又有事件觸發，或線路干擾等一系列問題，這些因素都會影響到整體抄表的穩定性和正確率。由于整體讀數的復雜性，僅通過增加錯誤處理程序往往無法達到預期效果。對于本系統，筆者通過不斷實踐發現，在整體讀數程序中引入第二個延時和重復讀數功能可以大大提高整體讀數的正確率。

　　在發出讀數命令并正確讀到數據后，必須進行短暫的延時，然后再讀下一戶，再延時，以此類推直到全部讀完。當對一戶讀數出錯時，要重復對其讀數幾次，若正確再讀下一戶，否則先調錯誤處理函數，再讀下一戶。注意：錯誤數據不能寫入數據庫，以防結算時產生問題。延時的引入盡管會對整體抄表的速度造成一定影響，但考慮到系統的整體性能，以損失一定速度來換取準確性這在絕大多數自動抄表系統中是可以接受的。在整體抄表過程中，“延時”具有關鍵的作用，它不但協調了軟件和硬件之間的問題，也協調了軟件自身的問題。

　　通過上述方法，使得整個系統從細節到整體上都加強了抄表系統的可靠性和對 大多數錯誤情況的避免和處理，從而保證了自動抄表系統高性能和高可靠性的要求，這種方 法在實際應用中收到了良好的效果。