可以*應對每個應用的SIMATIC控制器

我公司的SIMATIC系列控制器解決方案可以根據用戶的需求提供*的可編程邏輯控制器。無論是控制任務，集成技術或數據存檔-此報告小規模的自動化任務到非常復雜的系統解決方案 -安全模式或標準條件下的控制器 -SIMATIC控制器代表了貴公司未來安全的投資，并允許您以迅速，靈活，成本效益的方式應對新的挑戰。

上海翰粵是西門子工控及自動化產品*分銷商咨詢！

：鄭轅鴻（銷售工程師） 

          ：

（）:   傳真（）:

:zx2013888     ：www.hanyue.cc

：

“串行通訊不通”該如何檢查

今天來和大家聊一聊串行通訊的問題。做咱們這行的，應該都使用過通訊，可能是以太網，profibus，等等，但zui基本的也是zui簡單常用的一種通訊方式就是串行通訊，西門子的PLC（S7-200/300/400）系列都支持，只不過使用的是不同的模塊，不同的接口，和不同的程序塊而已。我們的工程師對此應用都寫過相應的文檔，需要的朋友可以從下面的鏈接來下載，希望對您有幫助。

S7-200：

http://www.ad.siemens.com.cn/download/DocList.aspx?TypeId=0&CatFirst=1&CatSecond=153&CatThird=-1

文檔編號為 A0136

S7-300/400：

http://www.ad.siemens.com.cn/download/searchResult.aspx?searchText=cp340

文檔編號為A0081 和A0440

好像在給我們的文檔做廣告呢，不過對初次使用的朋友還是有幫助的，趕快進入正題吧。

昨天上午我們有一個用戶打咨詢問題：“使用CP341和多個儀表做自定義串行通訊，通過輪詢的方式讀取儀表的數據，但通訊不通”，一聽就知道用戶在現場遇到問題了，那就盡量幫助用戶解決問題吧。

先了解用戶對產品是否熟悉，上經常會遇到用戶到了現場調試，但對軟件、產品所知甚少，什么都不知道，想幫也幫不上，但有時用戶不理解，會說一些讓工程師傷心的話，巧婦也難做無米之炊呀。

還好通過和謝工（用戶姓謝）溝通，比較熟悉S7-300和Step7，只不過是CP341以前沒使用過，但在公司調試過一段時間，有基礎。

謝工描述問題很清楚（這點很重要，如果用戶描述不清也很難辦），這下心里有譜了，憑自己多年的經驗，問題肯定能解決（不好意思，過于自信^_^），那就講講如何查出問題并解決的吧（zui后問題圓滿解決）。

首先看 CP341硬件上的TxD和RxD燈的狀態，如果有規律的交替閃爍，說明硬件通訊正常，如果只有TxD有時會亮，說明硬件通訊問題或程序問題。很不幸謝工現場只是TxD不時閃一下。

接下來查硬件連接，因為有多個站需要輪詢，網絡是RS485總線結構，通訊線是謝工自己焊的，使用的是屏蔽雙絞線，CP341接口處使用的是15針接頭，2和4針腳短接，9和11針腳短接，儀表處使用的是9針接頭，使用2和3針腳，CP341上15針的4針腳連到了儀表9針接頭的2針腳，11針腳連到了3針腳。謝工說*按照手冊的接線圖焊的線，用戶經常遇到這樣的問題，手冊上是這樣畫的，但CP341上2和4針腳短接，9和11針腳短接是在內部完成了，外部不需要短接，如果使用485接口方式，只需要使用4和11針腳就可以了。說改就改，改完一試，問題依舊。有思想準備，咱們繼續查。

接下來看一下模塊信息，確認模塊有沒有問題，顯示OK。接著檢查硬件配置，傳輸波特率，數據位，停止位，校驗方式，接收完成條件，接口設置，都要和儀表方保持*，檢查發現波特率錯了，還是默認的9600bps，應該設成19200。改完一試，TxD和RxD交替閃爍，漂亮極了（當時謝工說的），沒檢查之前謝工還說過波特率沒有問題，看來zui不應該出問題的地方也zui容易忽略。

說到這里謝工的問題應該就算解決了，既然已經談到這個話題，那么我們就假設一下，如果波特率也沒有錯誤，硬件配置都正確并和儀表*，那么我們還需要檢查什么呢？

您肯定想到了，檢查程序唄，我也是這么認為的，應該檢查程序。程序涉及到的東西很多，發送的機制，如何接收數據，報文的組織與解析，FB7/8有沒有報錯信息，等等很多東西。咳，說了這么多都是廢話，沒錯，檢查所有的程序會很困難，并會受到已有思路的限制，因為肯定已經查了很多遍了，能查出來早就查出來了，那怎么辦呢？如果是自己編的程序，那就好辦，重新編一個簡單的通訊程序，可以借用原有的程序，但一定要重新編，換個思路，這樣雖然會花點時間，但能夠很快找到程序的問題，相信經驗比較多的朋友會有同感。如果重新編了，問題找到大家都高興，如果還是和通訊伙伴不能通訊，并確認程序沒有問題了，那就要考慮對方的問題了，那這時該怎么做呢?

如果對方的設備可以調試，那就要檢查對方，如果對方不能調試，那只能使用串口調試小軟件通過計算機來測試了（計算機上需要使用RS232-485轉換器），模擬一下對方的通訊，可以看到我們發出的報文是否正確，并可以使用調試軟件發數據給CP341，如果正常，說明是對方設備有問題。如果仍然不能正常通訊，我們還需要檢查什么呢？

個人認為如果上面的步驟都作過了，仍不能解決問題，就要考慮硬件是否損壞；還有就是如果使用了RS232-485轉換器，是否轉換器有問題（轉換器使用有源的）；再有就是通訊伙伴間報文間隔匹配問題，通訊電纜長度問題，通訊線質量，干擾等問題。

寫了這么多，只是談了一些自己的想法，相信您會有更多的經驗和解決問題的方法，真誠的希望您和大家分享。

?

CP341怎么收不到數據？

今天和大家聊聊CP341模塊的一個故事

這個模塊的使用問題很常見，如何接線，怎么組態，程序設置等等問題，一般按照手冊使用入門一步步組態是不會有問題的，但是還是有一些細節是需要考慮的。

客戶的問題是這樣的：

客戶：采用的是ASCII 串行通訊方式與伺服液位計通信，雙方約定波特率 1200 bps ,數據位8 位, 1位奇校驗，1位停止位,數據收不到，但是接收燈一直亮。

我：檢查診斷緩沖區（這句話經常說）

客戶：CP341報錯說緩沖區已滿。我問了一下ASCII的設置，其使用的接收條件為字符延時時間結束方法，設置的參數為100ms。

我：建議修改到40ms，問題解決。

那為什么要改成40ms呢？接收參數到底如何設置？

詳細說來接收數據的條件有三種：?

1.字符延遲時間結束(On expiry of character delay time) ?

2.接收固定長度字符(On receipt of fixed number of characters) ?

3.接收文本結束字符(On receipt of end character)

*種字符延遲時間作為結束標準，這種用的zui多，客戶使用的也是這個，定義兩個連續接收到的字符間允許的zui大間隔時間，當字符延遲時間結束時識別為消息幀結束， CPU 即可接收數據。

例如把字符延遲時間設置為400ms，

則一旦發送數據間隔大于400ms則認為*幀結束。例如如下示波器捕捉報文顯示：

這個時間怎么設置呢,這個時間是由兩個參數決定一個是發送方間隔（send interval），這個發送方控制不由CP341決定，另一個參數是通信速率（transmission rate）。它們的關系如下圖：

默認設置為傳輸4個字符需要的時間，比如通信速率是9600bps，則發送一個字符需要的時間為（1位起始位+8位數據位+1位停止位+1位校驗位或者沒有）/9600=1.04~1.1ms,默認參數為4ms。如果通信速率為9600,發送30個字節的數據根據上圖公式，發送間隔不允許小于30+4 =34ms。客戶使用的通信速率是1200bps，發送一個字符需要10ms，但是其發送間隔不確定（伺服液位計決定），由于其現象為緩沖區滿，因此可以認為報文始終沒有接收結束，字符延遲時間設置大于發送間隔，改小后可以解決，但是要注意不要過小。

第二種方式是固定幀長度作為結束標準, 顧名思義是指收到固定的字符數之后接收結束， CPU 接受 CP 所接收的數據。

如果發送的字符長度與設置不*則需要考慮字符間隔時間，當長時間沒有收到字符（大于字符間隔時間）則不足或超出的字符部分會被丟棄掉。

例如如下示波器捕捉報文顯示：

第三種方式為判斷消息幀的結束字符，必須確保用戶數據中不存在的結束字符

在的字符延遲時間內沒有收到結束字符，則被丟棄掉。以上僅是對接收參數進行的簡要描述，其他常見問題匯總 *大家有興趣的話可以看一下：

串行通信模塊常見問題集

http://www.ad.siemens.com.cn/download/searchResult.aspx?searchText=f0426

?

西門子代理商：/（鄭轅鴻）