背景：

我們現(xiàn)在做鍋爐節(jié)能控制，都是在原有的控制系統(tǒng)上加上西門子的控制器，把我們的算法寫在西門子控制器中，通過通訊的方式讀取第三方系統(tǒng)的數(shù)據運算后把控制指令再發(fā)回去。因為第三方系統(tǒng)使用的系統(tǒng)不同，目前比較多的如ABB，施耐德，GE，上海新華，和利時，浙大中控等，為了實現(xiàn)和這些系統(tǒng)做的控制系統(tǒng)，就要有一個比較合理的通訊方式，目前采用的是opc方式通訊。

目前采用的通訊方式：

目前采用opc方式，鍋爐也是采用母管制的，所以要同時把整個母管中鏈接的鍋爐的數(shù)據都采集過來才好，這樣數(shù)據兩比較大，在大量數(shù)據交換的情況下，速度比較好。我們現(xiàn)在在向大型鍋爐控制上轉型，大型鍋爐都是一爐一機的，針對我們的現(xiàn)在的要求不太合適，我們的特點是需要交換的數(shù)據量小最多兩三百點，但是要求速度快。我們目前的通訊方式是用pc和第三方系統(tǒng)通訊然后pc和PLC通訊，pc中用wincc把讀取到的數(shù)據轉寫到plc的變量中，wincc中如果腳本執(zhí)行的速度過快，則影響到wincc的其他的功能，所以目前最快也就是1s的周期。

目前的技術需求：

而針對一爐一機這種數(shù)據量小，要求速度快的通訊特點，modbus通訊方式更合適，modbus是比較早的通訊協(xié)議，大多數(shù)的智能儀表都支持，控制系統(tǒng)也都支持，所以不存在無法通訊的難點。為了實現(xiàn)這個通訊，我于2014年的年底在江蘇阜寧澳洋熱電廠做了測試。

項目硬件需求：

江蘇阜寧澳洋熱電廠采用的是和利時的DCS控制系統(tǒng)，因為我們的控制思路是在原有控制系統(tǒng)基礎上做的程序，所以硬件中不包含io模塊采用西門子ps407，400控制器以及cp441通訊模塊。網上采購232通訊接頭，自制232通訊線。

硬件組態(tài)：

硬件組態(tài)很簡單，只要按照說明資料一步步操作就可以了，這里沒有什么好說的。

遇到的問題：

1、接線。網上搜索到的232接線圖：

按照這個接線圖連接后無法通訊，后來我考慮到modbus的通訊需要告訴對方是否準備還收發(fā)數(shù)據以及是否收發(fā)結束，所以應該狀態(tài)也發(fā)給對方才行，所以把上面的接線圖改成：

實現(xiàn)了硬件連接，可以通訊了。

2、通訊格式設置：

大家都知道西門子的數(shù)據存儲格式和其他的公司有點不一樣，西門子是低字高位，其他公司大多數(shù)都是采用的高字高位，如果只是傳輸字節(jié)的話，兩者是沒有區(qū)別的，如果用modbus傳輸32位的數(shù)據就需要注意這個問題了，因為modbus只是原封不動的把藥傳輸?shù)?2位地址的數(shù)據傳過去，具體這些位中式什么它不管的，所以如果沒有注意到這個高低位的問題，很有可能你都不知道傳過去的是什么。對方能夠實現(xiàn)換位功能，則只要采用4321的數(shù)據格式就行了，否則就要我們手動把需要傳輸?shù)臄?shù)據在傳輸前或者接收后進行換位操作。第一次使用沒有注意這個問題，通訊后的數(shù)據全變了，后來換位后正常了。

3、處理：

在實際測試使用過程中處理了前面說的問題后，又遇到了新的問題。實數(shù)，整數(shù)都能正確通訊，只有bool量無法通訊，只要增加bool量，則第三方系統(tǒng)報錯，通訊中斷，咨詢技術服務人員也沒有解決問題，后來我想既然整數(shù)能夠正確處理，那么我就把bool量打包成字節(jié)按整數(shù)傳輸，這樣還省了需要傳輸?shù)淖兞繑?shù)，只是雙方都需要編程，發(fā)送bool量方打包數(shù)據把8個bool量轉換成一個字節(jié)的整數(shù)，接收方再把這個整數(shù)分解成8個bool量。

通過以上的處理，終于實現(xiàn)的西門子400控制器通過modbus與和利時dcs系統(tǒng)的通訊。