6ES75347QE000AB0西門子S7-1500模擬量模塊

6ES7534-7QE00-0AB0 SIMATIC S7-1500， 模擬輸入/輸出模塊 AI 4x U/I/R/RTD/TC ST； 4 條通道，每組 4 條； 過程報警；診斷 AQ 2x U/I ST； 2 條通道，每組 2 條； 替換值；診斷 COMMON 模式電壓大約 10V 16 Bit；精度 0.3% 包括 Push-In 式前面板連接器， 饋電元素，屏蔽支架， 屏蔽端子

SIEMENS西門子

*，質量保證，保修一年

專業銷售及維修西門子各類工控自動化配件;

：S7-200CN、S7-200SMART、S7-300、S7-400、 S7-1200、S7-1500、ET200、LOGO邏西門子可編程控制器輯控制模塊

西門子HMI人機界面：觸摸屏

西門子變頻器：MM420、MM430、MM440、G110、G120、6SE70

西門子工業以太網：通訊網卡、通訊電纜、通訊接頭、總線連接器 工控機、交換機、自動化軟件等系型號齊全，快速報價，買我們的產品無憂所值，我們的產品都承諾質保一年，讓您買的省心舒心，用的放心！

人們都說書中自有黃金屋，書中有女顏如玉。沒聽說書中還有漩渦的。確實，要不是我調試中的那個暈延續至今，現在還有點暈，或許就沒有了這詞不達意的題。其中緣由，看官請瞧下文分解。

        連鑄火焰切割機S5改造升級S7的項目，上位機ABB的DCS古董級AC400通過串口下轄文物級115U+CP524。上位機維持不變，PLC升級為315-dp+CP341。串口RS232C運行的3964R+RK512。

        串口通訊，咱是老手。雖然不敢自夸業精，好歹232、422、485、modbus、自定義協也練過了。CP341也是快長胡子了的老產品，資料多多。問題不大?？蓙淼膯栴}確實不大，但很暈。

        從客戶存檔資料了解到，AC400的串口通過fetch和send兩條指令下發指令和獲取數據。Fetch的原理和編程方法在CP341手冊里說明清晰，CP341還有示例，通訊實驗很順，一蹴而就。

        接續就是Send通訊實驗，照理順利是自然的事了。可是，云彩（暈菜）來了。暈暈乎乎的… …

        手冊里的指示，發送端要求是，

 接收端的狀態要求是：

        可見紅寶書清晰指明，在前進路上發送端FB P_SND_RK只需要搞定發生數據源的DB_NO和DBB_NO，接收端搞定接收目的地DB_NO和DBB_NO，就應該是數據過來，萬事大吉。邏輯上和常理上，參數填寫不就應該如此嗎？！可是實驗臺上的CP341就是冷冰冰的不通不順，致我的一臉茫然不顧。

        碰釘子了，就想辦法吧。估計是我理解文檔不到位，繼續研讀……1遍，2遍，都五遍了，測試依然不通。見鬼了！

        鬼在哪里？中文翻譯不準？可能，…，找來2006,2002的文檔，解釋與前文2011版的*一樣。敢問路在何方？

        對了，上“Industry Online Support”在線提交問題尋求幫助。… …

        在線回復來了：“... cp341模塊僅調用FB7/8即可。 如果您采用RK512的FETCH/SEND方式，您側是被動站，僅需要調用FB7即可（FB7僅需要填寫EN_R=true，LADDR填寫），對方直接對本測的M或DB操作（這些具體在主站側）。 順祝商祺！…”?；貜突臼鞘謨缘目谖牵词謨陨系闹甘咀?，手冊要求主站側該做的都做了呀。只是回復中“對方直接對本測的M或DB操作（這些具體在主站側）”，好像與手冊某個地方的強調說明相悖，可怎么理解？怎么做？惜字如金，不得要領。

        在沒有清晰明確的理解，也就沒有激發出試機實驗的舉動。再進“Industry Online Support”溜達，查關鍵字“CP341”。東東太多，暈，沒新發現。轉到咱們熟悉的中文下載中心，翻來翻去，找到《SIMATIC S7-300 CP 341點到點通訊、安裝和參數分配點到點通訊、安裝和參數分配設備手冊》，主題貼近，直奔主題。查得：

        這段文字，我如獲至寶，終于找到了救命仙草。同時我又有冬日被靜電電擊的詫異感覺和難受，怎么會有黑白不同的說法呢？先不管這些疑問，咱不是搞學問的，搞定應用要緊。上機測試，一切如《SIMATIC S7-300 CP 341點到點通訊、安裝和參數分配點到點通訊、安裝和參數分配設備手冊》所說，通訊發出的源數據悅目地展現在我眼簾，順利通關。

        通關測試后的輕松，首先讓我感激西門子中國CS工程師的工作。是他們讓我走出了漩渦和迷茫。同時，我又掉進另一個漩渦。那就是西門子的嚴謹，產品技術狀態不應該是這樣的結果。產品使用手冊里強調的內容怎么會有錯呢，而且是*相反的狀態？！發送端定義數據源，接收端定義目的地，這是一種常態呀，我相信很多工程師與我有這一樣的直觀感覺。是不是那個地方的參數或狀態我還沒有捋順。到現在，我依然有這么一種心有不甘的情結。暈！希望能有人給我這暈車的解藥。

        臨近收筆，靜思而言，雖說這種情結多少有點是對自己調試期間盲目執著的懊悔?？蓮漠a品的用戶友好性而言，個人認為產品說明書里描述的狀態更友好。因為通訊中發送方定義數據源地址，收取方定義接收數據的存儲地址，更符合應用工程師的基于通訊原理的直觀理解。FETCH通訊方式的所有參數由fetch的發起方單方面定義，從通訊的原理機制上理解是合理的。Send方式如果在讓發送端包攬發和收的數據地址定義則有越俎代庖的味道。這只是一管之見，僅著眼于產品使用的友好性而言。至于根據3964R通訊機制，在send側定義收和發雙向的數據地址，是否會帶來糾錯性能的提高，是否能有更高的海明距離（Hamming distance）？這要做更進一步的研究才知曉，這里不敢妄言。

6ES75347QE000AB0西門子S7-1500模擬量模塊