背景：
現(xiàn)在做鍋爐節(jié)能控制，都是在原有的控制系統(tǒng)上加上西門子的控制器，把算法寫在西門子控制器中，通過通訊的方式讀取第三方系統(tǒng)的數(shù)據(jù)運算后把控制指令再發(fā)回去。因為第三方系統(tǒng)使用的系統(tǒng)不同，目前比較多的如ABB，施耐德，GE，上海新華，和利時，浙大中控等，為了實現(xiàn)和這些系統(tǒng)做的控制系統(tǒng)，就要有一個比較合理的通訊方式，目前采用的是opc方式通訊。
目前采用的通訊方式：
目前采用opc方式，鍋爐也是采用母管制的，所以要同時把整個母管中鏈接的鍋爐的數(shù)據(jù)都采集過來才好，這樣數(shù)據(jù)兩比較大，在大量數(shù)據(jù)交換的情況下，速度比較好。我們現(xiàn)在在向大型鍋爐控制上轉(zhuǎn)型，大型鍋爐都是一爐一機的，針對我們的現(xiàn)在的要求不太合適，我們的特點是需要交換的數(shù)據(jù)量小最多兩三百點，但是要求速度快。我們目前的通訊方式是用pc和第三方系統(tǒng)通訊然后pc和PLC通訊，pc中用wincc把讀取到的數(shù)據(jù)轉(zhuǎn)寫到plc的變量中，wincc中如果腳本執(zhí)行的速度過快，則影響到wincc的其他的功能，所以目前最快也就是1s的周期。
目前的技術(shù)需求：
而針對一爐一機這種數(shù)據(jù)量小，要求速度快的通訊特點，modbus通訊方式更合適，modbus是比較早的通訊協(xié)議，大多數(shù)的智能儀表都支持，控制系統(tǒng)也都支持，所以不存在無法通訊的難點。為了實現(xiàn)這個通訊，我于2014年的年底在江蘇阜寧澳洋熱電廠做了測試。
項目硬件需求：
江蘇阜寧澳洋熱電廠采用的是和利時的DCS控制系統(tǒng)，因為我們的控制思路是在原有控制系統(tǒng)基礎(chǔ)上做的程序，所以硬件中不包含io模塊采用西門子ps407，400控制器以及cp441通訊模塊。網(wǎng)上采購232通訊接頭，自制232通訊線。
硬件組態(tài)：
硬件組態(tài)很簡單，只要按照說明資料一步步操作就可以了，這里沒有什么好說的。
遇到的問題：
1、接線。
按照這個接線圖連接后無法通訊，后來我考慮到modbus的通訊需要告訴對方是否準(zhǔn)備還收發(fā)數(shù)據(jù)以及是否收發(fā)結(jié)束，所以應(yīng)該狀態(tài)也發(fā)給對方才行，所以把上面的接線圖改成：
實現(xiàn)了硬件連接，可以通訊了。
2、通訊格式設(shè)置：
大家都知道西門子的數(shù)據(jù)存儲格式和其他的公司有點不一樣，西門子是低字高位，其他公司大多數(shù)都是采用的高字高位，如果只是傳輸字節(jié)的話，兩者是沒有區(qū)別的，如果用modbus傳輸32位的數(shù)據(jù)就需要注意這個問題了，因為modbus只是原封不動的把藥傳輸?shù)?2位地址的數(shù)據(jù)傳過去，具體這些位中式什么它不管的，所以如果沒有注意到這個高低位的問題，很有可能你都不知道傳過去的是什么。對方能夠?qū)崿F(xiàn)換位功能，則只要采用4321的數(shù)據(jù)格式就行了，否則就要我們手動把需要傳輸?shù)臄?shù)據(jù)在傳輸前或者接收后進行換位操作。第一次使用沒有注意這個問題，通訊后的數(shù)據(jù)全變了，后來換位后正常了。
3、處理：
在實際測試使用過程中處理了前面說的問題后，又遇到了新的問題。實數(shù)，整數(shù)都能正確通訊，只有bool量無法通訊，只要增加bool量，則第三方系統(tǒng)報錯，通訊中斷，咨詢技術(shù)服務(wù)人員也沒有解決問題，后來我想既然整數(shù)能夠正確處理，那么我就把bool量打包成字節(jié)按整數(shù)傳輸，這樣還省了需要傳輸?shù)淖兞繑?shù)，只是雙方都需要編程，發(fā)送bool量方打包數(shù)據(jù)把8個bool量轉(zhuǎn)換成一個字節(jié)的整數(shù)，接收方再把這個整數(shù)分解成8個bool量。
通過以上的處理，終于實現(xiàn)的西門子400控制器通過modbus與和利時dcs系統(tǒng)的通訊。
（轉(zhuǎn)載）
