更多文章關(guān)注公眾號：巨控電子

Modbus RTU 通訊在工業(yè)現(xiàn)場的應(yīng)用是比較普遍的，西門子全系列的PLC都可以通過串口通訊模塊和配套的Modbus 指令讀寫數(shù)據(jù)。

以S7-1500做主站為例，我們在程序中，只需要調(diào)用“Modbus_Comm_load”和“Modbus_Master”即可。

兩個程序塊的背景數(shù)據(jù)塊中也提供了很多其它參數(shù)，我們通常使用默認值，不需要修改。小編今天給大家分享一個實際案例，通過更改這里的配置參數(shù)來解決實際的通訊問題。

話說小編最近接下一個S7-1500 Modbus的調(diào)試，讀取第三方儀表的數(shù)據(jù)，但是調(diào)試過程中指令一直報錯誤16#81EA，通過軟件幫助我們可以大致知道，16#81EA 是說從站響應(yīng)的數(shù)據(jù)幀不滿足Modbus 的最小長度，所以根據(jù)報錯信息，自然把問題的矛頭指向了通訊伙伴，也就是第三方的儀表。

但是，同樣的硬件鏈路下，客戶使用現(xiàn)場的SMART 200 替換S7-1500測試，居然通訊一切正常，這就說明硬件、儀表的配置沒有問題，問題又回到了S7-1500 這一側(cè)上。

再次反復(fù)檢查了通訊的波特率、硬件接線、增大看門狗時間，并沒有任何改善，S7-1500 指令仍然報同樣的錯誤，問題到底是出在哪里呢？難道是S7-1500 模塊有問題？

懷著惴惴不安的心情，小編再次分析錯誤，16#81EA 是說主站接收到了從站的響應(yīng)，但是響應(yīng)的數(shù)據(jù)包不滿足最小長度的要求，也就是說接收到了響應(yīng)數(shù)據(jù)包的一部分就認為結(jié)束了，那Modbus 指令如何判斷Modbus數(shù)據(jù)包的結(jié)束呢？

S7-1500/1200/300/400使用的Modbus指令塊，默認3.5個字符延時時間，作為Modbus報文結(jié)束條件，就是說，如果字符間的間隔時間超過這個時間，就會認為Modbus 報文結(jié)束， 3.5 個字符的延遲時間，和波特率有關(guān)系，如下圖。以9600波特率為例，如果字符間的延遲時間超過4ms，之前進入緩存區(qū)的數(shù)據(jù)就會認為是一包完整的Modbus 響應(yīng)，這樣指令接收到的數(shù)據(jù)當(dāng)然不完整了。

考慮到這里，基本就定位了問題的可能原因，有可能是第三方儀表的工作特性以及網(wǎng)絡(luò)上的延遲，導(dǎo)致了字符間的延遲較大，這樣無法形成完成的Modbus 響應(yīng)幀。有沒有辦法增大字符間的延遲時間呢，仔細研究指令之后，還真找到了參數(shù)“ICHAR_GAP”,以毫秒為單位增大字符延遲時間。

最大延遲時間=“3.5倍字符延遲時間”+ “ICHAR_GAP” 。

最后的結(jié)果果然應(yīng)證了小編的判斷，更改參數(shù)加大了最大延遲時間后，通訊果然恢復(fù)正常！看來指令的背景DB中的隱藏參數(shù)，有時候?qū)φ{(diào)試有時候還真有幫助！

最后，客戶又糾結(jié)了一下，那為什么SMART 200 的指令直接可以呢，SMART 200 和早期的S7-200 PLC 使用的指令基本相同，打開指令的說明，可以看到S7-200/SMART 200 指令，判斷Modbus報文的結(jié)束和S7-1200/1500/300/400 不同，它使用100ms最大延遲作為Modbus 的結(jié)束條件，這樣就可以解釋通之前的現(xiàn)象了！