胡科幻, 石景龍, 苗 政, 徐 信, 王向超, 齊文斌, 張 軍

(1. 吉林大學 電子科學與工程學院, 長春 130012； 2. 白城福佳科技有限公司 工程技術部, 吉林 白城 137000；3. 吉林電子信息職業(yè)技術學院 信息中心, 吉林 吉林 132001)

0 引 言

目前我國正處于工業(yè)自動化控制的高速發(fā)展時期。自動化控制主要是通過中央處理器發(fā)出控制指令, 生產線上的設備根據中央處理器的指令完成相應動作。其中交聯(lián)電纜生產線的自動化控制是工業(yè)自動化控制成功與成熟的重大體現(xiàn)。在交聯(lián)電纜生產線等自動控制系統(tǒng)中, 主要是針對生產線速度以及溫度的控制。其中對生產線速度控制依賴于對電機的控制, 這是生產線運作的基礎和前提, 同時也是生產線能否高效生產的重要保障, 而電機的驅動則是由專門的直流調速器實現(xiàn)的, 因此一個可靠穩(wěn)定交聯(lián)電纜生產線控制系統(tǒng)對速度的控制是通過中央處理器與直流調速器的通訊實現(xiàn)的。

32位MCU是一種高性能、 低功耗、 低成本的嵌入式應用芯片, 被廣泛的作為中央控制器應用于自動控制系統(tǒng), 工業(yè)控制等領域[1-2]。直流調速器是交聯(lián)電纜生產線自動化控制系統(tǒng)中必不可少的電機驅動設備, 是連接中央處理器與各電機模塊之間的橋梁, 并為電機控制提供支持[3-4]。32位MCU與直流調速器之間的通訊有直接的模擬量控制方式, 但由于模擬量控制抗干擾能力以及傳輸距離的限制, 并不能滿足工業(yè)自動化控制系統(tǒng)的工作環(huán)境。因此筆者就32位MCU與直流調速器通訊問題給出解決方案, 其硬件電路基于RS485硬件結構, 軟件設計基于Modbus總線協(xié)議, 并設計出單個MCU控制多個直流調速器的一主多從通訊協(xié)議。

1 系統(tǒng)整體結構

筆者闡述一種基于RS485串行口的物理硬件接口電路實現(xiàn)的Modbus總線協(xié)議[5-7]。RS485電平需要電平轉換芯片才可以被STM32驅動, 筆者使用SP3485芯片作為485電平轉換。RS485的電平轉換芯片電路如圖1所示, 其中TX, RX分別為發(fā)送端和接收端, RE為使能端, AB兩線為數據傳輸線。RS485通信原理如圖2所示, 將TTL電平信號轉化成差分信號A/B線進行傳輸, 根據A/B線的電壓差標定數據信息(A線電壓>B線電壓標定輸出為1, A線電壓

圖1 RS485電平轉換芯片 圖2 RS485通信原理圖 Fig.1 RS485 level shifting chip Fig.2 RS485 communication schematic

通訊系統(tǒng)框架如圖3所示, 其中STM32、 ETD790P分別為系統(tǒng)的主機和從機, 物理層基于RS485總線, 應用層基于Modbus應用協(xié)議實現(xiàn)整個通訊系統(tǒng)的設計。主機通過Modbus應用協(xié)議將命令發(fā)送到從機, 從機解析協(xié)議并做出響應回傳到主機, 主機根據應用協(xié)議解析從機回應的數據, 即是整個通訊系統(tǒng)的實現(xiàn)過程。

圖3 通訊系統(tǒng)框架圖Fig.3 Communication system framework

2 Modbus總線協(xié)議

2.1 Modbus簡介

在我國, Modbus總線協(xié)議[3-4,8-14]已經是國家標準, 也是工業(yè)史上首個用于工業(yè)現(xiàn)場的總線協(xié)議, 一般應用于各種數據采集和過程監(jiān)控。筆者將其用于32位MCU與直流調速器的數據通訊方向。

根據7層OSI通信模型, Modbus標準模型包括應用層、 數據鏈路層和物理層, 其中應用層是Modbus應用協(xié)議； 數據鏈路層是主-從協(xié)議； 而物理層支持不同的物理接口如RS485(筆者選用)、 RS232等。其中主-從協(xié)議是筆者設計的關鍵, 具體表現(xiàn)為在同一時刻, 只有一個主節(jié)點連接于總線, 一個或多個子節(jié)點(最多247個)連接于同一個串行總線, 主節(jié)點在同一時刻只會發(fā)起一個Modbus事務處理, 從節(jié)點在沒有收到主節(jié)點的請求時并不主動發(fā)送數據, 也不與其他子節(jié)點通信。

2.2 Modbus幀描述

圖4 Modbus通訊協(xié)議數據單元Fig.4 Modbus communication protocol data unit

Modbus通訊協(xié)議數據單元如圖4所示, Modbus應用協(xié)議所定義的最基本的數據單元(PDU： Protocol Data Unit)包括功能碼段和數據段, 筆者使用到的數據單元包括地址碼、 功能碼、 數據段以及錯誤校驗碼。Modbus合法的地址碼為0～247, 主節(jié)點通過將子節(jié)點的地址放到報文的地址碼處對子節(jié)點尋址, 子節(jié)點返回應答時, 將自己的地址放在應答報文的地址碼以讓主節(jié)點知道哪個子節(jié)點在回答； 功能碼指明服務器要執(zhí)行的命令； 數據在功能碼后面表示功能碼含有請求和響應參數； 錯誤檢驗碼是對報文進行冗余校驗的結果。

Modbus有RTU(Remote Terminal Unit)和ASCII(American Standard Code for Information Interchange)兩種模式進行串行傳輸, 這兩種模式均定義了信息如何打包為報文以及如何進行解碼。筆者選用RTU模式傳輸, 此模式下傳輸數據密度大, 在相同的波特率下吞吐率比ASCII模式高。RTU報文幀格式如圖5所示, 其中報文構造由發(fā)送設備將幀定義為帶有起始和結束標記的幀, 這使設備可以準確地檢測報文的起始與結束, 一幀報文必須以連續(xù)的字符流發(fā)送, 如果一幀數據中的兩個字符之間的空閑間隔大于1.5個字符時間, 則報文幀被認為不完整應該被丟棄, 而兩個報文幀之間至少3.5個空閑字符以間隔區(qū)分兩幀報文。

圖5 RTU報文幀格式Fig.5 RTU message frame format

3 通訊協(xié)議設計

RTU模式傳輸狀態(tài)如圖6所示, 其中從初始態(tài)到空閑態(tài)轉換需要3.5個字符時間定時超時, 這可以保證兩個報文幀之間的時間滿足大于傳送3.5個字符時間, 空閑態(tài)是沒有發(fā)送接收任務的狀態(tài)(當無字符傳輸時間超過3.5個字符時, 通信鏈路被認為在空閑態(tài))； 此時在鏈路上檢測到的任何傳輸的字符被定義為幀起始, 有字符傳輸時鏈路變?yōu)榛顒討B(tài)； 當鏈路再次無字符傳輸時間超過3.5個字符的時間時, 被定義為幀結束； 幀結束后, 傳輸的數據在1.5個字符時間完成CRC(Cydic Redundancy Check)計算和檢驗； 然后, 分析地址域以確定幀是否發(fā)往此設備, 如果不是, 則丟棄此幀。通訊協(xié)議的設計是根據RTU模式的報文幀格式以及傳輸狀態(tài)設計的, 這種設計方法標準化程度高, 可移植性強。

圖6 RTU模式傳輸狀態(tài)圖Fig.6 RTU mode transmission status diagram

圖7 程序流程圖Fig.7 Program flow chart

筆者設計32位MCU與直流調速器通訊的Modbus實現(xiàn)方法是將32位MCU作為主機設備, 直流調速器作為從機設備, 從機的Modbus應用協(xié)議已集成, 因此只需設計主機的通訊協(xié)議即可。筆者設計的通訊協(xié)議整體程序流程圖如圖7所示, 首先由STM32作為主機系統(tǒng)對軟硬件初始化, 這里主要包括串口通訊、 中斷服務、 定時器和I/O端口等初始化； 然后由主機向從機發(fā)送操作指令, 筆者涉及的操作指令主要包括從機寄存器的讀、 寫操作(具體涉及到電機轉速、 電流、 轉矩等參數寄存器)； 檢測是否發(fā)送超時, 若發(fā)送超時重新發(fā)送, 發(fā)送正常則等待從機應答； 主機接收從機的應答數據； 因為主機并不知道從機數據何時發(fā)送完畢, 根據RTU模式數據傳輸規(guī)則, 判斷接收字符時間間隔是否超過3.5個字符時間, 未超過則繼續(xù)接收, 超過則判定本次應答數據接收完畢； 然后對接收到的字符校驗是否正確。這里筆者設計采用兩級校驗, 首先是對接收到字符個數的校驗, 個數校驗成功再進行CRC校驗； 應答數據接收正確后進行通訊的應用層協(xié)議分析執(zhí)行。

4 實驗數據分析

筆者設計的通訊協(xié)議旨在解決MCU與直流調速器的通訊問題。實驗是基于STM32作為主機與PC端Modbus從機模擬器通訊證實筆者實現(xiàn)的可行性以及可靠性, 這里選取一組數據(主機發(fā)送0x 01 01 00 01 00 04 6C 09)進行詳細說明。

圖8 示波器監(jiān)測主機發(fā)送報文Fig.8 The oscilloscope monitors thehost to send messages

該實驗示波器監(jiān)測主機發(fā)送報文如圖8所示。主機發(fā)送報文的波形, 一個報文幀是8個字符, 1個字符是10位, 包括1位起始位、 8位數據位、 1位停止位, 起始位總是低電平, 結束位是高電平, 8位數據低位在前。如圖8標出的第1個字符, 起始位是低電平, 之后是1個高電平和7個低電平, 最后一位是結束位高電平, 因此中間數據位是1000 0000, 由于低位在前, 所以傳輸數據是0000 0001, 也就是0x01； 再如圖8第7個字符, 起始位低電平, 之后高低電平對應數據為0011 0110, 最后一位是結束位高電平, 因此傳輸的數據是0110 1100, 即0x6C。同理可以分析出示波器上監(jiān)測的數據是0x 01 01 00 01 00 04 6C 09。

PC端Modbus Slave從機模擬器監(jiān)測數據如圖9所示。其中Modbus Slave接收到的數據為0x 01 01 00 01 00 04 6C 09, 響應功能碼后發(fā)送給主機的數據為0x 01 01 01 03 11 89, 并且接收到主機發(fā)送的報文含義為01H地址的從機執(zhí)行01H功能碼。具體執(zhí)行的命令為從起始地址0001H取0004H個線圈寄存器的當前狀態(tài), 如圖9所示, 4個線圈寄存器的狀態(tài)分別為1100。因此Modbus Slave給主機回傳報文為01H地址從機執(zhí)行01H功能碼, 為主機返回01H字節(jié)數據, 具體數據為03H(03H對應二進制00000011, 即4個線圈寄存器狀態(tài))。主機串口監(jiān)測數據如圖10所示。從圖10中可以看出, 主機發(fā)送數據為0x 01 01 00 01 00 04 6C 09, 收到的從機回傳數據為0x 01 01 01 03 11 89, 這表明主機完成報文的發(fā)送并且從機接收到報文作出回應, 并且主機成功接收到從機數據。

為驗證所設計的通訊方式的可靠性, 筆者進行了針對不同功能碼的多次重復實驗, 發(fā)送與接收可靠性實驗數據如表1所示。從表1中可看出, 在不同功能碼下, 主機可以成功的將發(fā)送報文幀發(fā)送給從機, 而從機可準確地接到主機發(fā)送的數據, 并根據功能碼做出相應的數據處理, 將處理后的數據發(fā)送給主機, 最后主機也可以準確的接收到從機發(fā)送的報文幀。這表明筆者設計的通訊方式可準確、 穩(wěn)定地實現(xiàn)數據傳輸, 因此可以實現(xiàn)32位MCU與電機驅動器的通訊進而實現(xiàn)精確的控制電機的目的。

圖9 PC端Modbus Slave從機模擬器監(jiān)測數據 圖10 串口監(jiān)測數據Fig.9 PC-side Modbus Slave slave simulator monitors data Fig.10 Serial port monitoring data

表1 發(fā)送與接收可靠性實驗數據

5 結 語

筆者所涉及到的通訊系統(tǒng)采用STM32作為主機、 ETD790P直流調速器作為從機, 利用Modbus總線協(xié)議實現(xiàn)直流調速器與32位MCU的通訊, 從而實現(xiàn)32位MCU對交聯(lián)電纜生產線中電機的精確控制。采用筆者方法進行通訊具有數據傳輸可靠穩(wěn)定、 可移植性高、 協(xié)議標準化程度高、 易于實現(xiàn)等特點, 可廣泛應用于交聯(lián)電纜生產線中32位MCU對電機的精準控制。