摘 要： 利用VC++6.0設計了一種基于串口通信原理的直讀表軟件，實現了PC上位機與RS485型/Mbus型水表、RS485型氣表和電表的串行數據通信。同時，該軟件能查抄表的實時數據，完成重新設置表的地址和密碼等功能。實際的測試結果證明了軟件設計的正確性、有效性。
關鍵詞： 串口通信；VC++；抄表；數據
隨著城市化進程的加快、物業管理智能化的推進普及，城市的供水、供氣單位越來越多地投入使用新型智能遠傳水表、氣表。目前，RS485、M-bus遠傳表已經在居民小區廣泛地投入運用。但由于起步晚、技術不成熟等種種因素，安裝了自動抄表系統的小區，都或多或少會出現一些問題，如抄不到表讀數、表頭壞死等。同時，新表的更替和使用也涉及到表地址的改寫，表頭密碼的設置等問題。因此，在抄表維護工作人員電腦上設計一種基于串口通信原理的直讀表軟件成為一種必然。這將極大地方便水、氣表表頭模塊的檢測和抄表系統的日常維護等工作。本文運用VC++6.0設計一種能夠讀取表讀數和表地址、設置表地址和表密碼，并能測試串口通信情況的直讀表軟件。
1 硬件系統組成原理
硬件系統組成原理框圖如圖1所示，主要由表頭、RS232-RS485轉換器、PC機組成。RS232-RS485轉換器內部包涵了485接口電路、光電隔離和232接口電路。通過該轉換器可以將485總線制設備（光電直讀表模塊）與計算機的串口相連，從而實現計算機與485總線制設備的通信。表頭模塊內部除了包含單片機、光電隔離電路外，同時還集成了功能很強的可實現全雙工通信的485接口電路，可以同時接收和發送數據，能夠方便地和遠端上位機進行通信。
硬件系統各組成部分之間的接線很方便，將485型表的4根線準確地接在RS232-RS485轉換器對應的485端口上，即A、B信號線和P、G電源線分別正確連接；同時232串口線一端連接轉換器，另一端連接電腦，轉換器電源口接上12 V直流電源，RS485轉換器可由P、G線給表頭單片機模塊上電，指令信號則由A、B信號線傳遞，因此在計算機中用直讀表通信軟件即可讀得表數據。
2 軟件設計
讀表軟件的主要功能是通過對軟件界面窗口按鈕的操作，設置串口通信參數、查詢表的通信情況和表的數據信息等，包括上位機與表之間發送、接收指令的顯示；查詢表的類型，實時讀取表的數據、密碼、地址編碼；修改表的地址編碼、密碼和開關閥門狀態。
本軟件依據硬件設備廠家配套的通信協議進行相應開發，此數據通信協議適用于RS485型/Mbus型直讀水表、RS485型氣表、RS485型電表和總線制光電直讀直飲水表，采用異步串行方式（一位起始位/八位數據位/兩位停止位/無奇偶校驗/波特率2 400），采用CRC-CCITT（循環冗余碼）檢驗技術，保證通信數據準確、可靠。通信用數據包以“數據包頭”開頭，“數據包尾”結尾。從上位機到表的發送指令以及從表到上位機的返回指令格式如表1、表2所示。其中，CRC校驗碼為有效數據的校驗碼。CRC校驗數據長度為2 B，CRC—CCITT是一個17位生成多項式G＝[1 0001 0000 0010 0001]，用多項式形式表示為G（x）＝x16＋x12＋x5＋1，由它產生的檢驗碼R的二進制位數是16 bit（2 B）。
根據流程圖，具體設計步驟如下：
（1）建立項目，打開VC＋＋6.0，建立一個基于對話框的MFC應用程序COMTOOL，在項目中插入MSComm控件，對于軟件界面的設計，在VC下運用dialog對話框，可以拖拽控件，對控件布局，極為方便[2]；
（2）在對話框中添加發送和接收數據框。向主對話框中添加兩個編輯框，一個用于顯示接收數據包，ID為IDC_ReceiveEdit；另一個用于輸入發送數據，ID為IDC_SendEdit；再添加一個按鈕，功能是按一次就把發送編輯框中的內容發送一次，將其ID設為IDC_Send。再打開ClassWizard－>Member Viariables選項卡，選擇CSCommTestDlg類，為IDC_ReceiveEdit添加CString變量m_strReceive，為IDC_SendEdit添加CString變量m_strSend。說明：m_strReceive和m_strSend分別用來放入接收和發送的字符數據。
（3）設置串口參數和打開串口。串口參數設置區的設計是關鍵環節，在操作軟件時，只有正確的設置好串口的配置參數，才能保證串行口的正常通信。同時需要設計一個按鈕來打開串口，在界面做一個“打開串口”按鈕，點擊此按鈕打開串口時，同時會顯示串口參數的配置信息。
串口參數設置區的設計主要是向主對話框界面中添加以上參數相應的編輯框，并將編輯框命名相應的參數，把串口選擇、波特率、數據位、停止位和校驗位等編輯框拖拽在一個顯示框內，命名為“串口設置”，這樣方便串口參數的設置和顯示，“串口設置”區的界面設計包括：串口選擇、波特率、數據位、停止位和校驗位的設置。向主對話框界面中添加以上參數相應的編輯框，在工程COMTOOL的主程序文件中對串口選擇、波特率、數據位、停止位和校驗位進行初值定義，程序如下：
int BaudRate[]={300，600，1 200，2 400，4 800，9 600，14 400，19 200，38 400，56 000，57 600，115 200，230 400，460 800，921 600}；
int ParitySelNum=5；
CString Parity[]={_T（"None"），_T（"Odd"），_T（"Even"），_T（"Mark"），_T（"Space"）}；
int DataBits[]={5，6，7，8}；
int StopBits[]={1，2}；
在指令發送、接收編輯框和串口參數配置設計完成后，在軟件界面上設計一個用來決定串口通信開和關的按鈕，即Push Button控制鍵，將其命名為“打開串口/關閉串口”按鈕。在該按鈕的處理函數中打開串口，即在相應的處理函數OnOpenClose（）中添代碼即可實現按鈕功能。
（4）構造發送指令。在串行通信的情況下，由于表的基本數據信息會以數據包的形式傳送，為了上位機能獲取表的數據信息，因此在程序設計起初階段必須構造相應的發送指令，使表頭模塊返回對應的數據信息包（即返回指令）。先為發送按鈕添加一個單擊消息即BN_CLICKED處理函數，打開ClassWizard－>Message Maps，選擇類CSCommTestDlg，選擇IDC_BUTTON_MANUALSEND，雙擊BN_CLICKED添加OnSend（）函數，并在函數中添加發送數據功能代碼，現在可以連接設備測試軟件是否能發送和接收指令，配置好串口參數，點擊發送按鈕，如數據通信成功，進行下一步[3]。
不同的功能按鈕對應不同的發送指令，將每個按鈕賦予一個變量參數，當按鈕操作一次，設定的發送指令字符串便賦給變量參數，同時發送指令數據包就發送出去，因此才能完成軟件的讀取表讀數、改寫表地址等不同功能。例如“手動讀表”按鈕的功能代碼如下：
CString temp；
rec_w=1；
UpdateData（true）；
m_strSend = _T（""）；
m_strReceive = _T（""）；
if（m_strStatus=="關閉"）
{
AfxMessageBox（"請首先打開串口"）；
return；
}
m_strSend=_T（"FE FE FE 42 42 42 42 53 FF FF FF FF 52 2D 3E 45"）；
ClearBuffer（）；
temp=m_strSend；
temp=ChangeCharstr2Hexstr（temp）；
m_SerialPort.WriteToPort（temp.GetBuffer（temp.GetLength（）），temp.GetLength（））；
m_nSendBytes+=temp.GetLength（）；
m_strSendBytes.Format（"%d"，m_nSendBytes）；
UpdateData（false）；
為了實現對表不同的數據信息的讀取，即為了發送不同的指令從而獲取相應不同的返回數據包，軟件界面上會設計不同的功能按鈕，如“手工讀表”、“地址設置”、“密碼設置”等，每個功能按鈕會有不同的發送指令，這樣就能實現不同的功能。每個按鈕的處理函數中會設計相應的發送指令。例如：m_strSend=_T（"FE FE FE 42 42 42 42 53 FF FF FF FF 52 2D 3E 45"）這條廣播讀表指令以字符串形式賦值給“手動讀表”按鈕的變量參數m_strSend，這樣每當操作“手動讀表”或其他按鈕，就會發送一條指令。
（5）CRC校驗。點擊發送指令按鈕，每發送一條指令，正常情況下表模塊會返回一條指令。在主體程序的設計中，這里添加一個接收返回數據包的功能區，將返回的指令數據包暫時存儲，以便對其進行CRC校驗，判斷返回的數據包是否是有效數據。CRC校驗環節是為了測試返回數據包是否是所需要的有效返回指令，即是否是發送指令對應的返回指令，實現CRC校驗環節的主要程序段如下：
CrcA=s[0]；
CrcB=s[1]；
CrcC=s[2]；
for（i=2；i<j；i++）
{
CRC（&CrcA，&CrcB，&CrcC）；
CrcC=s[i+1]；
}
s[j]=CrcA；
s[j+1]=CrcB；
（6）解析數據包程序。在CRC校驗無誤后，才對返回的數據包進行解析，故實現解析功能的程序設計是本設計的重要一環，解析的目的是將返回數據包中的有效數據段轉換成表的相應信息，并正確地顯示在軟件界面上。如實現地址改寫的主要解析程序如下所示：
CString temp=_T（""），temp2；
GetDlgItemText（IDC_AddrEdit，temp）；
UpdateData（true）；
rec_w=2；
m_strSend=_T（""）；
m_strReceive=_T（""）；
ChangeHexstr（temp， New_data）；
for（int j=0；j<4；j++）
NewSend[13+j]=New_data[3-j]；//獲取新地址
for（j=0；j<4；j++）
NewSend[8+j]=Rec_data[j+5]；//獲取舊地址
getCRCCCITT（&NewSend[8] ，result ， 9）；//獲取CRC
NewSend[17]=result[0]；
NewSend[18]=result[1]；
for（ j=0；j<20；j++）
m_strSend+=DevideHexChar（NewSend[j]）+_T（" "）；
temp2=m_strSend；
temp2=ChangeCharstr2Hexstr（temp2）；
ClearBuffer（）；
m_SerialPort.WriteToPort（temp2.GetBuffer（temp2.GetLength（）），temp2.GetLength（））；
UpdateData（false）；
（7）添加表數據顯示框和設置按鈕。為了清楚反映表的數據信息，故設在軟件界面上添加不同的數據顯示框，也是設計的一部分。基本通信成功后，和在對話框中添加發送和接收數據框類似，添加表的數據顯示框，并對每個顯示框設置函數變量，變量的值就是表的數據；添加表的設置按鈕，如“地址設置”等按鈕，并添加相應的處理函數，在處理函數中編寫代碼就能實現按鈕的相應功能。
（8）解析重置和清空緩存。程序設計中，“解析重置，緩存清空”這一環節的設計是為了在一次通信結束，表的數據正確顯示后，將緩存數據包的功能區清空，以便下一次通信返回數據包的緩存，從而使軟件能夠多次、反復地對表模塊發送相同或不同指令，快捷地完成“讀表”、“修改地址”等各種功能。這里在“解析重置”的設計中參數rec_w起到關鍵作用。例如，在“手動讀表”中rec_w=1，同時對應這條發送指令的解析代碼中也將rec_w=1，故不同的發送指令會有不同的解析函數段，這樣，完成一次讀表操作后需要將rec_w的值重置為0，以便下次rec_w重新賦值進行不同的操作。而對于“緩存清空”的代碼設計如下所示：
void CCOMTOOLDlg：：ClearBuffer（）//接收清零
{
for（int i=0；i<30；i++）
{
All_data[i]=0x00；
Rec_data[i]=0x00；
}
m_strReceive=""；
}
如程序設計流程圖所示，基于這種設計思想，實際操作時軟件的工作流程如下：程序配置好通信串口參數后，一直處于等待OnComm事件狀態。上位機需要讀取表的數據時，通過讀表軟件發送一條讀表指令數據包，當接收到表模塊返回的數據包后放入程序中的緩存功能函數中，再經過CRC校驗返回數據包是否正確，校驗成功后才調用解析子函數[4]，對接收指令數據包進行解析，然后將解析出的表的參數完整顯示在讀表軟件界面上，最后將解析函數重置并將緩存功能函數中數據清空，結束本次數據通信。
3 測試結果分析
經過調試運行成功后，設計好的界面如圖3所示。
從圖3中可以看到，使用該軟件調試串口通信、讀取表數據非常方便、直觀。當連接好表等相關設備時，用戶根據實際情況選擇相應的串行端口，設定所需的波特率（在此選用2 400），再設置奇偶校驗位、數據位、停止位；點擊“串口打開”按鈕串口便打開，再點擊“手工讀表”便可以進行指令的傳送和接收，并能正確顯示表的讀數、地址等相關信息；當在表與上位機通信正常情況下，點擊“地址設置”按鈕便可以將表的地址更改；“密碼設置”等按鈕的操作與“地址設置”類似，并且實現其相應的功能。同時，可以通過“清空顯示”按鈕清除接收數據在接收文本框中的顯示。
本軟件經過測試后可以進行上位機與表之間數據包的發送與接收，并能正確解析出返回指令中表的實時數據，如表的讀數，表的地址等表的信息清楚地顯示在軟件界面上；同時，表地址的重新設置，表密碼的修改等功能均能實現。軟件適用于常見的RS485型/Mbus型水表、RS485型氣表和RS485型電表，對遠傳抄表系統的維護和安裝工作有一定的現實意義。
參考文獻
[1] 封亞斌．采用串口通信技術實現Modbus數據通信[J]．自動化儀表，2004，25（10）：56-58．
[2] 張新村，嚴殊．基于ARM的Linux系統下Qt串口助手的設計[J]．軟件導刊，2011，（8）：64-66．
[3] 龔建偉，熊光明．Visual C++/Turbo C串口通信編程實踐[M]．北京：電子工業出版社，2007．
[4] 宋國清，劉暢．基于BTF340開發板的Modbus從機協議實現[J]．雞西大學學報，2011，11（1）：44-45．