(工業的問題)為什麼ASCII會比RTU慢???
 

我在做MODBUS時發現用同樣的時間週期送同樣的指令下，ASCII模式硬是比RTU模式容易漏，我想說應該是ASCII太慢了所以他還沒解碼完我就再丟


可是我看過設定後感到怪怪的，我的鮑率115200，ASCII起始符號是一個符號文字( : )，RTU的起始是等待10ms
如果以同樣的指令來說ASCII要傳送434位元，以鮑率115200來算相當於3.767ms；RTU模式雖然只要傳送99個位元(以鮑率115200來算相當於0.856ms)，但是RTU要先等10ms，所以傳一次RTU要10.856ms


那為什麼ASCII比較容易出錯??還是說速度不是問題傳輸量大才是問題(容易有錯)??

首先你要先了解115200是bps(bits per second)，再確認一下你的時間計算公式是否正確。

再來你文章中ASCII的434跟RTU的99是位元？還是位元組？

如果誠如你所說的
434位元(bit)=>54.25位元組(bytes)?
99位元(bit)=>12.375位元組(bytes)?

老實說，我寫這麼多年的Modbus Master & Slave傳送接收程式碼，還沒寫傳送過小數位的bytes啊！

可以教我嗎？

抱歉，我跳太多以致於非內行的人有點難理解，而且我也算錯很多地方
我用台達馬達的MODBUS說明來解釋


我們先看看RTU的第二層(還是第三層)傳輸方式

右邊的數字代表我要傳送的BYTE數，所以我總共要傳送1+1+4+1=7個BYTE
那假設我RTU用8bit、n(沒有檢馬)、2(2bit stop bit)這種模式傳送(這是底層)，那每傳送一個byte的話底層要要多少個bit

要11個bit

也就是說我傳送完我要的資料要7*11=77個bit(之前我錯算成9個BYTE所以才會寫99)，再來換算成時間77/115200=0.668ms，那再加上前面要等10ms，所以是10.668ms


\\================================
然後來看ASCII

一個字必須兩個位元組來表示，也就是說我必須要34個位元組
假設我用7、E、1(7bit、檢碼偶同位、stop bit 1bit)來傳送

也就是說我每傳送一個位元組要10個bit
34*10=340(我之前算錯成434)，換算成時間 340/115200=2.9513ms




這樣算起來ASCII還是比RTU快很多吧(因為ASCII不用等，他是用符號當作起始點)

如果想要量測實際傳送時間，建議還是上示波器，光是用推斷的，不一定準確，

再者還有一個問題，你是寫在windows架構？還是MCU？

如果是Windows，傳送資料並非你的傳送程式送出後，就馬上傳到設備端，

還須考慮到中斷優先順序，連MCU也可能會有這個問題。

Modbus我接觸了10年以上了，除了Modbus以外，還有接觸各家的通訊協定，

可能這樣還不算你所說的內行吧！

再者還有一個部分，你所謂的一樣傳輸時間週期是多久？

老實說你所描述的條件不太充足，很多部分很難幫你推斷問題何在。

不好意思說你是外行，只是因為你直接拿我實體層的bit去除以8當byte來說我才誤以為你對這塊不了解，看來是我誤會，我接觸才兩年多而已

我只是想問問看這方面的可能性
我是用pc送的，透過com port(RS232轉RS485或者USB轉RS485)送命令到驅動器跟PLC內部，在PC端這邊是有人寫好的現成的發送程式只要我寫對命令塞到程式它就會送出去並接收回傳資料


還有，所謂同樣傳輸時間多久其實我也不知道，因為我只做到驅動這塊，後端寫軟體的他依照機台動作要送命令時就送命令，有時3*N連發(X、Y、Z軸各自下令移動後再各自接判讀移完成信號)，有時常常休息(因為機台沒事幹)

寫傳輸通訊的驅動程式，如果有疑問，最好不要用"推想"，直接實驗是最好的方式。

1. 寫一個接收端 app 來驗證 driver 發送的信號是否正常。
2. 勾示波器或 LA 來看。

上網求教，要虛心一點，隨便說人是外行，再有本事的人也不會想點你。

要罵人外行的前提是，你本來就是想酸人而已。
:laugh: :laugh: :laugh: :laugh: :laugh:

先說一下為什麼modbus asc||很少人在用的原因，主要是傳輸時間和檢查碼較弱的關係，以我家的溫控器來說如果要讀取pv(modbus rtu)的資料我會下

01 03 00 8A 00 01 A5 E0(8個byte)

01 站號8A是PV的暫存器位置 A5 E0 是CRC
如果用O_81的資料格式和38400的鮑率去算的話
一個BYTE的傳輸時間就要0.28645ms，所以傳完整串命令就要2.2916ms


再來是modbus asc||的格式

3A 30 31 30 33 30 30 38 41 30 30 30 31 37 31 0D 0A (17個byte)
以上3A是header 37 31 是LRC 0D 0A是delimiter
如果用O_81的資料格式和38400的鮑率去算的話
一個BYTE的傳輸時間就要0.28645ms，所以傳完整串命令就要4.8697ms

從以上結果得知做一樣的事情rtu要來的比asc||有效率的多，再者asc||的checksum是用累加去算出來的，這種檢驗法無法分辨出位元組是否有交換，假設命令的其中一段為00 01，如果今天傳輸過程中發生錯誤變成01 00，使用crc checksum可以抓到這個錯誤，lrc則無法抓到，因為加總後數值還是一樣，所以可以的話盡量還是用rtu較好

回到你的問題，我比較有疑問的是為什麼你的設備(儀表)在rtu模式時要等10ms?這從mcu端的角度來看是不合理的，因為mcu閒置時永遠是在等你的plc，只要你的plc丟出第一個start bit mcu就會去收你丟過來的資料，至於要收幾個byte，收完後要如何解析資料，這就是韌體設計師要做的事情(讀modbus手冊)，所以要等10ms，這真的無法理解。

還有一個比較常遇到的問題就是master端(plc 人機)中有個參數”delay time”的設定，很多master的預設是0ms，而你資料量大後，或著是遇到比較慢的儀器，就須要去調整這個參數，以上是我的一些意見，也不一定完全正確，有機會再來研究研究，感謝!

:)

感謝



我也不懂但它手冊上就是這樣寫，RTU起始碼是等待10ms
但是因為ascii發生錯誤率比RTU高所以我才以為ASCII傳輸比較慢(上一筆尚未傳完下一筆就下達了)

看看能不能直接監視指令碼的傳送狀態（omron的模組有支援這種功能）
有時線材也會有差、特別是要開高速傳送的時候

如西門子s7你不用它專用線材的話、一般線材跑不到最高速度