醉湮邃虞
醉湮邃虞話老黑
級別: 略有小成
精華主題: 0
發(fā)帖數(shù)量: 229 個
工控威望: 409 點
下載積分: 1577 分
在線時間: 209(小時)
注冊時間: 2009-01-16
最后登錄: 2015-03-18
查看醉湮邃虞的 主題 / 回貼
樓主  發(fā)表于: 2014-02-26 12:35
自編的MODBUS 子站通訊程序與主設備通訊

測試時使用了觸摸屏做主站
觸摸屏單獨連接一個PLC,各種速率通訊正常
但多個PLC連接后,
9600速率,通訊正常,

38400時,偶爾發(fā)生子站丟失,可以自恢復

115200 時,
觸摸屏寫各個PLC數(shù)據(jù),通訊正常
觸摸屏讀數(shù)據(jù),個別PLC有丟失現(xiàn)象,只能發(fā)送寫指令后,才能讀,過幾秒又有子站丟失

懷疑PLC計算CRC時間過長,在高速率下應答超時。試驗增加觸摸屏超時時間,無效果

不知是不是我的程序有問題


棋牌比賽免費得實物,閑暇好去處
http://www.jj.cn/indexTG.html?promoterid=108502812
醉湮邃虞
醉湮邃虞話老黑
級別: 略有小成
精華主題: 0
發(fā)帖數(shù)量: 229 個
工控威望: 409 點
下載積分: 1577 分
在線時間: 209(小時)
注冊時間: 2009-01-16
最后登錄: 2015-03-18
查看醉湮邃虞的 主題 / 回貼
1樓  發(fā)表于: 2014-02-26 14:12
其實這段程序其實一直使用著,沒什么問題

最近只是想提高速率,才出現(xiàn)了問題
有可能是我用的這個觸摸屏 數(shù)字顯示元件 機理有問題

當用三個 數(shù)字顯示元件 分別顯示三個PLC的內(nèi)存數(shù)據(jù)時,高速率就有可能出現(xiàn)設備丟失現(xiàn)象

但同樣的速率下,即使用 六個 數(shù)據(jù)傳輸元件 ,利用觸摸屏內(nèi)部毫秒計時器的第0位作為觸發(fā)傳送條件, 同時讀六個PLC 內(nèi)存數(shù)據(jù),每個每次讀取10字節(jié),通訊、數(shù)據(jù)仍然很正常
棋牌比賽免費得實物,閑暇好去處
http://www.jj.cn/indexTG.html?promoterid=108502812
醉湮邃虞
醉湮邃虞話老黑
級別: 略有小成
精華主題: 0
發(fā)帖數(shù)量: 229 個
工控威望: 409 點
下載積分: 1577 分
在線時間: 209(小時)
注冊時間: 2009-01-16
最后登錄: 2015-03-18
查看醉湮邃虞的 主題 / 回貼
2樓  發(fā)表于: 2014-03-01 14:51
我還是對這個問題 糾纏了起來

我將觸摸屏幕作為從站,兩個PLC,分別一個從站,一個主站,同樣對100字節(jié)進行讀取
經(jīng)測試,觸摸屏應答僅許20毫秒,我的程序超過200毫秒才應答
看來CRC計算是主要問題
于是又測試CRC計算程序,計算一個200字節(jié)的CRC高達165毫秒,
看來得修改CRC計算程序了
把CRC計算改為了查表法后測試,200字節(jié)需要70毫秒(據(jù)兩種算法的原理,平均運算速度應提高5倍左右,可能是因S700采用的是解釋運行,所以速度才提高了1倍左右)
于是得出了結論,
當PLC作為主站時,因不需要即時應答,對CRC的計算時長要求不高,其影響的只是數(shù)據(jù)查詢周期、掃描周期
當PLC作為從站時,需要及時應答,最好采用硬件驗證CRC,但S7200未提供MODBUS 硬件,所以一定要用查表法

犧牲這512字節(jié)的表格內(nèi)存空間是必要的。
這也就是一直未發(fā)現(xiàn)我的程序有問題的原因,因為一直用這段程序作為主站。
[ 此帖被醉湮邃虞在2014-03-03 14:58重新編輯 ]
棋牌比賽免費得實物,閑暇好去處
http://www.jj.cn/indexTG.html?promoterid=108502812
醉湮邃虞
醉湮邃虞話老黑
級別: 略有小成
精華主題: 0
發(fā)帖數(shù)量: 229 個
工控威望: 409 點
下載積分: 1577 分
在線時間: 209(小時)
注冊時間: 2009-01-16
最后登錄: 2015-03-18
查看醉湮邃虞的 主題 / 回貼
3樓  發(fā)表于: 2014-03-03 14:56
這兩天折騰的。!

終于搞定
115200 也不丟設備了
棋牌比賽免費得實物,閑暇好去處
http://www.jj.cn/indexTG.html?promoterid=108502812