上文說到發(fā)送指令（xmt）型同打乒乓球的發(fā)球，球由發(fā)球一方遵循比賽規(guī)則（通訊協(xié)議）發(fā)出去。如何檢測發(fā)球是否按規(guī)則來發(fā)？是否已經(jīng)發(fā)過了界等一系列問題，用什么方法來判斷、界定？這樣，就說到了串口調(diào)試軟件“cktszs”（當(dāng)然也可以用另一臺plc的接收指令來確認(rèn)，串口調(diào)試軟件適用于單個plc做通訊測試用），該軟件安裝后，插入usb轉(zhuǎn)串口電纜（我這里使用的是深圳力特的那根轉(zhuǎn)換電纜），打開軟件，圖示：
設(shè)置通訊口為com3這個是我安裝usb轉(zhuǎn)換電纜時選擇的端口，這個由黑色圈變紅色亮圈，說明通訊口com3設(shè)置正確，根據(jù)smb30參數(shù)對應(yīng)設(shè)置通訊參數(shù)，圖示：
ppi電纜、usb轉(zhuǎn)換電纜連接與200smart plc集成的基于rs485端子，啟動cpu運行，可以看到cpu向串口調(diào)試軟件按每一秒/次的頻率，發(fā)送字符“siemens”，圖示：（這個測試程序是【說文1】編輯的）
看到這個由plc發(fā)送過來的字符信息時，說明plc程序及通訊電纜連接正常了的。
再寫入一句“ni hao！”（你好）字符，讓秒脈沖的上升沿發(fā)送“siemens”后，再由下降沿發(fā)送“ni hao！”這串字符試試，圖示：
將程序下載到cpu中，看結(jié)果，圖示：
在一片模糊的字符中終于仔細(xì)地找到了cpu發(fā)送過來的字符，見紅色小框，圖示：
既然說modbus通訊如同打乒乓球，那再來試試打幾個“擦邊球”試試球路如何？
先試把發(fā)送數(shù)據(jù)改為0，即vb0 = 0（vb20 = 0）下載到cpu中，看結(jié)果，圖示：
串口調(diào)試助手接收區(qū)沒有了字符，但發(fā)送完成中斷仍然在工作，參見“狀態(tài)圖標(biāo)”圖示：
說明發(fā)送完成中斷是在執(zhí)行的，圖示此刻的中斷次數(shù)已經(jīng)在510次發(fā)送完成中斷了。但字符將不做發(fā)送任務(wù)。
那設(shè)置vb0 = 大于7的數(shù)字的結(jié)果又將如何呢？假設(shè)設(shè)置為vb0 = 100，（vb20 = 100）圖示：
中間會多出一些莫名其妙的字符或字符串出來，見上圖紅色框，說明發(fā)送指令的發(fā)送個數(shù)應(yīng)根據(jù)實際的數(shù)據(jù)個數(shù)來確定。這個原因當(dāng)然有很多，相信大家都能夠看的出來問題的所在。
看來打擦邊球是要給裁判處罰、沒收發(fā)球權(quán)的，此路行不通！
總結(jié)發(fā)送指令xmt：
1） 發(fā)送指令tbl管腳最大字符數(shù)為255個，這個原因應(yīng)該是這個管腳的數(shù)據(jù)類型是byte所規(guī)約的，發(fā)送指令的個數(shù)必須嚴(yán)格按實際個數(shù)填寫，第一個儲存區(qū)數(shù)據(jù)不參與通訊。
2） 字符間的空格位同樣占一個字符的儲存區(qū)。
3） prot管腳只能填0或者1是plc的通訊口地址硬件所決定了的。
4） 通訊前需確定好雙方的通訊參數(shù)協(xié)議內(nèi)容必須是一致的，電纜連接是可靠的。
5） 如果多個字符輪詢發(fā)送，需要有字符間的開始和結(jié)束標(biāo)志字符來區(qū)分，如空格符。這條僅僅對串口調(diào)試軟件的顯示部分而言，實際應(yīng)用時因地址區(qū)的區(qū)分，不存在這個問題。
發(fā)送指令xmt在整個通訊程序中的應(yīng)用相對還是比較簡單的，這如同打球，無論發(fā)出什么樣的類型球，一旦發(fā)出去了，就要看接球方的判斷和應(yīng)變能力了。