前言
最近西門子PLC價格大幅上調，在工控界引起了不小的風波，不僅漲價，甚至還缺貨，導致很多人不得不更改方案。聽說最近已經完成了芯片替換，希望不久能夠恢復供貨，並把價格回調。
通過這件事，從側面可以看出，西門子在工控領域的市場佔有率很大，那麼對於上位機開發人員來說，使用西門子PLC作爲下位機，我們應該如何與之進行通信呢？
上位機和西門子PLC支持很多種通信協議，主要分爲兩種，一種是串口通信，一種是以太網通信，同時也可以通過OPC實現數據通信。
串口通信
西門子PLC支持串口通信，在S7-200和S7-200Smart中，都直接集成了串口，但是從S7-1200到S7-1500，慢慢都取消掉了，如果需要，可以通過擴展模塊的方式來增加，出現這種現象的原因，其實也是工業發展的必然結果。串口通信的優勢在於簡單、成本低，但是劣勢也非常明顯，就是傳輸效率低。西門子早期的串口通信主要是Profibus DP通信，但是上位機是無法直接與西門子PLC走Profibus DP通信的，因此，上位機中西門子PLC常用的串口通信方案如下所示：
PPI通信：PPI通信只針對S7-200和S7-200 Smart系列PLC，其他型號不支持。領資料+V：thingerzj
ModbusRTU主站：西門子PLC對Modbus協議支持還是比較不錯的，這裏是指PLC做Slave（即從站），上位機做Master（即主站）。
ModbusRTU從站：這裏是指PLC做Master（即主站），上位機做Slave（即從站）。
以太網通信
上位機和西門子PLC通信還是以太網通信爲主，我們常說的西門子通信協議分別是S7協議和Profinet協議，但是Profinet是一種總線協議，目前，C#是無法直接與西門子PLC走Profinet通信的。因此，西門子PLC常用的以太網通信方案如下所示：
S7通信：基本上從S7-200到S7-1500均可以實現，這裏有很多可以選擇的開源或商業庫，包括http://s7.net、pronodave、libnodave、sharp7，也可以自己封裝通信庫。
ModbusTCP Server：這裏是指PLC做Server（即服務器），上位機做Client（即客戶端）。
ModbusTCP Client：這裏是指PLC做Client（即客戶端），上位機做Server（即服務器）。
OpenProtocol Server：這裏是指開放式TCP通信，PLC做TCPServer（即服務器），上位機做TCPClient（即客戶端）。
OpenProtocol Client：這裏是指PLC做TCPClient（即客戶端），上位機做TCPServer（即服務器）。
OPC通信
OPC通信是工業控制中常用的一種通信方式，主要在於OPC軟件的選擇以及OPCDA、OPCUA的選擇，因此，上位機和西門子PLC常用的OPC通信方案如下所示：
PC Access系列：西門子針對S7-200開發PC-Access軟件，針對S7-200 Smart又提供了PC-Access Smart軟件，可以直接通過這些軟件實現OPCDA通信。
Simatic Net 系列OPCDA：Simatic Net是西門子主推的OPC軟件，支持西門子全系列，這裏主要是OPCDA通信方式。
Simatic Net 系列OPCUA：新版的Simatic Net也開始支持OPCUA，這裏主要是OPCUA通信方式。
KepServer 系列OPCDA：KepServer同樣作爲一款商業OPC軟件，在國內使用率非常高，同樣也支持西門子全系列，這裏主要是OPCDA通信方式。
Simatic Net 系列OPCUA：新版的KepServer也開始支持OPCUA，這裏主要是OPCUA通信方式。
S7通信協議
在以上衆多的通信方式和通信協議中，就目前而言，上位機使用S7通信是最方便，也是應該最廣泛的，那麼S7協議相對於其他協議來說，有哪些優勢呢？
使用S7通信協議最大的優勢在於不需要編寫PLC程序，而且S7協議在底層做了很強的封裝，在上位機通信應用中相比其他通信協議來說，也有很大的優勢。
雖然不需要編寫PLC程序，但仍然需要做一些簡單的配置：
開啓Put/Get
PLC側需要設置勾選允許來自遠程對象的Put/Get通信訪問 對於西門子1200/1500系列，必須要勾選允許Put/Get訪問，對於200Smart/300/400，則不需要。
DB塊去除優化訪問
對於基於博圖開發S7-1200/1500的項目，如果要與DB塊數據通信，需要要去除DB的優化的塊訪問，對於200Smart/300/400，則不需要。如果希望通過標籤通信，可以採用OPCUA。
務必保證通信地址是有效地址
因爲PLC大多數是基於存儲區的，每個地址肯定是隸屬於某個存儲區，大家都知道西門子PLC自帶的存儲區有I區、Q區、M區、T區、C區，但是對於常用的DB存儲區是沒有的，需要自己去創建，也就意味着，如果你要讀取DB地址，必須要提前創建好DB存儲區，除此以外，DB存儲區創建之後，默認是沒有字節的，需要自己一個個添加變量，才能形成有效存儲區，因此一個DB存儲區的範圍是有限並且可見的（可以通過偏移量看出來）。領資料+V：thingerzj
S7協議之布爾操作
對於布爾操作，很多協議都有，但是這裏的布爾操作是指寄存器布爾，比如DB100.DBX0.0，很多時候，我們都是通過先讀取DB100.DBB0的值，再通過位運算結果，寫入到DB100.DBB0中，實現DB100.DBX0.0的操作，但是這種方式有弊端，
第一：每次操作一個布爾值都需要與PLC進行兩次數據交互。
第二：安全性和穩定性無法保障，你不知道在你讀取和寫入之間，這個字節的值是否已經發生了改變。
這樣的問題也存在於Modbus協議的寄存器位操作，如40001.05，三菱、歐姆龍的寄存器位操作，如D100.06、W12.04，給上位機開發者帶來很多苦惱。
但是S7協議支持直接位操作，有專門的報文指令實現這樣的功能。
S7協議之PDU讀取
大部分人都知道S7協議一次性讀取有限制，但是具體是多少？怎麼計算出來的？
S7協議的一次性讀取長度是根據PDU計算出來的，這個PDU的值是來自於PLC本身，不同型號的CPU，它的PDU是不一樣的，可以參考下面兩張圖：
西門子PLC的PDU大小是和CPU息息相關的，一般會有240、480、960三個檔次，知道PDU之後，那麼一次性讀取的字節長度，就是在PDU的基礎上減去18，這個18是指包頭包尾會有18個字節，這樣我們就知道了一般的PLC，一次性能讀取222個字節（240-18=222），但是對於S7-1516這樣的PLC，我們一次性是可以讀取942個字節的（960-18=942），這個一次性能讀取的字節越長，越能提高上位機的通信效率。
剛剛的方式是通過KepServer測試的，實際開發過程中，該怎麼獲取CPU的PDU呢，實際上在建立連接的第二次握手時，返回的報文中就包含PDU的值。
第二次握手返回的報文長度是27個字節，最後兩個字節就是PDU的值，上圖展示的是S7-1200PLC返回的報文，0和240的組合即爲240。
對於S7-1500，我這裏也做了一下測試，結果如下，返回結果爲3和192，3和192的組合恰好是960（960=3*256+192）。
雖然PDU是由硬件做了限制，但是我們可以通過軟件的方式，實現大量數據的讀取，只需要在底層做一些封裝即可。做了一下測試，針對S7-1200和S7-1500同時讀取M區的8000個字節的耗時比較，S7-1200耗時800多ms，S7-1500耗時僅需200ms，由此可見，硬件對通信的重要性。
S7協議之多組讀取
對於很多其他的通信協議，當我們遇到數據變量比較零散，同時讀取多個存儲區或者一個存儲區多個不同部分的時候，我們只能針對每個存儲區或者每塊區域做一個數據請求，但是西門子S7協議可以解決這樣的問題。
西門子S7協議有一個非常強大的一個地方，可以同時讀取很多個不同的存儲區，最大支持19種，總共讀取長度仍然受PDU的限制。
這裏我們仍然以實驗測試爲例，體驗多組讀取帶來的美妙體驗。
假設我們的通信組配置如下：
通信組01：讀取I區從0開始的1個字節
通信組02：讀取Q區從0開始的1個字節
通信組03：讀取M區從0開始的200個字節
通信組04：讀取M區從500開始的50個字節
通信組05：讀取M區從1000開始的60個字節
通信組06：讀取DB100從0開始的20個字節
通信組07：讀取DB100從20開始的20個字節
通信組08：讀取DB100從40開始的20個字節
通信組09：讀取DB100從60開始的20個字節
我們採用常用S7-1200PLC，通過配置軟件實現配置以上9個通信組，開始通信測試，首先我們選擇的是單組讀取的方式，就是針對每個組，依次進行讀取，結果如下，耗時大約200ms，這個時間應該相對來說還是比較正常的。
接着，將讀取方式改成了多組讀取，再進行測試發現結果如下：
通過結果發現，多組讀取對於存儲區較爲零散的項目來說，有着非常重要的作用，可以大大提高通信效率。
總結
通過上面一系列的分享，相信大家對上位機和西門子PLC通信有了更加深入的瞭解，希望大家可以多多實踐。
每種通信方式都有自己的優缺點，對各種通信方式和協議瞭解之後，你才能夠在不同的場合選擇適合的通信方式，給出最合理的解決方案。
寫在後面
伴隨着物聯網及智能製造的普及，越來越多的自動化及PLC工程師，開始尋求新的學習機會來升職加薪。電氣工程師轉上位機開發，也是必然的趨勢。想學習的朋友可以關注我，給大家分享更多的上位機開發技術。