早在2008年左右，我就在產品中使用Modbus協(xié)議與其它設備進行通信。記得第一款是智能馬達保護器，其作為Modbus從，與Modbus主設備進行通信。這么多年來，一直都沒有使用開源的Modbus協(xié)議代碼，而在在不斷在自己編寫的Modbus協(xié)議代碼上進行優(yōu)化，發(fā)現(xiàn)問題并解決。 自己寫的代碼用起來比較得心應用可以針對不同的平臺進行優(yōu)化，將處理器的性能發(fā)揮到極致。在此期間，也踩過一些坑，現(xiàn)在做一些總結： 串口數(shù)據(jù)接收完之后，到通過IO口重新使用接收的時間間隔。
發(fā)送完成之后切換接收的延時時間 如上圖所示的Td，按照Modbus協(xié)議的規(guī)定，接收完數(shù)據(jù)之后，必須要間隔3.5個字符對應的時間才能發(fā)送。 如果是9600bps的波特率，8位數(shù)據(jù)位，1位起始位，1位停止位，無奇偶校驗位，則1個字符為10個 bit，對應1.04ms，3.5個字符對應3.5ms。 考慮到總線上的電容對傳輸延時的影響，建議在發(fā)送完數(shù)據(jù)1.7個字符的時間之后再使能接收。對于這個時間，可能會犯一些錯誤，比如：
-
在發(fā)送完最后一個字節(jié)的發(fā)送完成中斷中，直接將控制IO口使能485芯片的接收。殊不知，由于電容導致的信號延時，串口數(shù)據(jù)還沒有完全發(fā)送到總線，485芯片就被置為接收狀態(tài)，導致最后幾個bit的數(shù)據(jù)誤碼；
-
沒有正確理解發(fā)送完成中斷以及發(fā)送緩存器空中斷之間的差別；
-
發(fā)送完成中斷一般是指串口數(shù)據(jù)已經從移位寄存器從端口送出。但是并不說明已經被送到RS485總線。從MCU的IO口到RS485總線還需要考慮隔離光耦、電容、RS485芯片的延時；
-
發(fā)送緩存器空中斷是指騰出了緩存的位置，可以緩存數(shù)據(jù)。此時，上一個數(shù)據(jù)可能還在移位寄存器中被緊張有序地按位移出到IO口，此時把RS485芯片置為接收。還正在移位的數(shù)據(jù)就嗝屁了。
因此
-
一定要搞清楚選用的中斷是發(fā)送完成中斷還是緩存器空的中斷；
-
在發(fā)送中斷中，不能立即切為接收，應當延時一段時間，我現(xiàn)在的做法是不管三七二十一，在發(fā)送中斷中，如果判斷為最后一個byte，則延時1.7ms將RS485設置為接收；
-
不應該啟動定時器進行延時，定時器資源很寶貴，應該在100us左右的定時器中斷中，通過變量計數(shù)來進行1.7ms左右的延時；
MODBUS從設備多少時間會應答
Modbus是問答式的通信，主設備發(fā)送完數(shù)據(jù)之后，從設備會做出響應。按照Modbus協(xié)議規(guī)定，從設備3.5個字符時間之后做出響應都是合法的。不同的傳感器應答響應時間各不相同。 有些差的傳感器可能到幾十ms才響應，有些3.5ms左右就立即響應了。 有些甚至沒有按照Modbus的協(xié)議出牌，還沒有到3.5ms左右的時間就響應了。 這就要求主設備在將RS485接收使能之后，立即進行接收狀態(tài)。 如果是用串口中斷進行接收，則應該注意在主程序中是否有關中斷的操作，關中斷的操作是否影響接收。 每一個串口數(shù)據(jù)之間的時間間隔
Ｍodbus根據(jù)數(shù)據(jù)之間的時間間隔來判斷一楨消息的結束，需要保證一楨消息內的前后數(shù)據(jù)之間的間隔不超過3.5個字符。 而數(shù)據(jù)一般在發(fā)送中斷中發(fā)送，有些人為了保證數(shù)據(jù)完整性，保證數(shù)據(jù)訪問的互斥，很喜歡關中斷來保護現(xiàn)場。這種做法一不小心就會使發(fā)送兩個數(shù)據(jù)的間隔超過3.5個字符。 特別是當波特率比較高時，更容易出現(xiàn)這種情況。比如，當波特率為38400時，3.5 個字符僅為850us左右，在發(fā)送串口數(shù)據(jù)的時間內，中斷關閉850us，Modbus通信就嗝屁了。 如果MCU支持DMA，建議使用DMA+定時器進行數(shù)據(jù)收發(fā)。 作為Modbus從設備時，收到數(shù)據(jù)之后，多少時間應答
按照Modbus協(xié)議要求，3.5個字符之后就可以應答。有些Ｍodbus主設備可以是為了保證實時性，對這個應答時間要求比較苛刻。比如我們前一段時間跟西門子的工控屏對接時，就碰到過這樣的問題，總線的波特率為19200bps，我們的設備在收到西門子的命令之后大概在5ms左右做出了應答。但是西門子工控屏卻判為錯誤。之后，我們將應答時間縮短到2ms左右，與西門子的通信才變得正常。 建議在3.5個字符之后，立即應答。 來源：頭條號-IT自動化交流
原文鏈接：https://www.toutiao.com/i6894161680406675981/
免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
