一、技術背景
隨著西門子S7-1500/1200系列PLC及TIA PORTAL博圖軟件應用的逐步推廣，在軟硬件標準化模塊化得到深入應用的基礎上，一些高端用戶對PLC系統在柔性化應用方面有了更多的需求：
1、在有限的硬件資源前提下最大限度地去滿足設備實際運行使用中的各種需求：
比如某一中小型鍋爐控制系統，其基本控制功能涉及的控制設備(比如燃燒器，主輔循環泵，主回路閥門，溫度壓力流量傳感器等)是確定不變的，但根據客戶需求的不同有些輔助設備(補水泵，風機，補水閥，調節閥，泄壓閥，輔助電源等)是否使用及其使用數量是有變化的，由于中小型供暖鍋爐的控制系統一般據均采用小型PLC控制系統，硬件IO的擴展能力有限，控制系統的安裝空間有限，所以鍋爐制造廠家在系統標配的基礎上，希望利用系統多余的IO點，能在一定程度上靈活應對上述設備需求的變化，簡化控制系統和程序，實現標準化。
2、在一定規模的硬件資源下力求達到系統的最大靈活性：
比如某汽車總裝車間的線邊倉科的撿料防錯系統，每當車型轉換投產，線邊倉庫的部件庫位位置及數量都會有較大的變化，撿料防錯系統的指示燈傳感器也會被相應地重新部署，這樣庫位與指示燈傳感器對應關系會發生變化，不同型號的指示燈傳感器(對應不同的IO數量)使用數量也會發生變化，重新組態庫位與指示燈傳感器的對應關系，以往需要修改并更新控制系統的程序，這需要專業的工程師才能做，那么如何能實現不修改控制系統程序，僅由普通生產管理人員通過人機界面以修改參數的形式重新組態庫位呢？
我們知道，西門子的S7系統早已實現了硬件配置用戶程序再組態的功能，S7-300/400/1200/1500/均可由用戶程序實現分站一級到模塊級別硬件再配置功能，然而這是硬件層面的解決方案，并不能滿足上述兩個例子的需求，因此還要通過軟件層面的配合來最終實現設計要求。在解決上述新的應用需求的實踐過程中，黃芩提出了一種在博圖環境下通過用戶程序實現硬件IO可自由組態的基本編程方法，拋磚引玉，與大家共同探討并開拓PLC柔性化系統程序設計的方法與思路。
為了便于說明問題，我們把目標控制系統簡化成一個簡單的單純的MCC控制系統，該MCC控制系統滿足如下已知條件：
1、滿足若干個直接啟停電機的控制的硬件IO的需求；
2、每個電機包括啟動、停止、故障復位，故障反饋4個輸入信號；運行輸出，故障指示2個輸出信號；
3、電機控制功能塊是已經經過測試并封裝好的FB(功能塊)；
系統控制程序實現要求：
1、實現在設計范圍內對任意一臺電機的可靠控制；
2、電機控制程序對應的硬件IO點可通過用戶程序實現自由定義，使控制系統能按實際硬件IO接線及定義正確地完成控制任務；
3、必須使用且不能修改已封裝的FB塊；
4、不允許修改控制程序及重新下載控制程序(包括數據塊)的方式，只能通過在線修改參數方式來實現控制對象硬件IO的定義；
5、實現方法力求簡單易行，不占用過多的系統資源；
6、博圖V14版本編程環境下，S7-1200/1500程序通用。
二、方案分析與實現
圖1所示系統是一個基于S7-1200PLC的小型MCC控制系統示例，由以下元器件組成：
CPU1215C DC/DC/DC×1
EM223 16DI DC/16DO DC×3
是一個以開關量信號為主的簡單控制系統，其IO點滿足一個小型MCC控制系統的點數需求。
圖2是一個常見的啟停控制帶故障保護邏輯的電機控制功能塊，有4個bool輸入變量，2個bool輸出變量，并且封裝成一個標準的功能塊FB1，我們以此功能塊為例代表已有的成熟的控制功能，希望在不對該功能塊做任何改變的基礎上，能夠實現控制器硬件IO由用戶程序自由定義，并且控制系統能按實際硬件IO接線及定義基于該功能塊正確地完成MCC控制系統的控制任務。
圖3為示例中電機直接控制功能塊在博圖中的傳統調用方式，功能塊多次調用，生成多個對應的背景數據塊，每次調用其輸入輸出參數均為實參賦值，顯式調用，多重背景調用亦是如此。如果某一個電機控制塊的對應的硬件IO點需要修改，則需要修改程序并重新下載，系統才能按新的硬件IO對應方式進行工作。
如何可以不需要修改并重新下載程序，僅僅通過修改運行程序的數據，就能改變控制功能塊與硬件IO對應關系呢？
顯然只有通過間址尋址的方式才能實現硬件IO變址訪問的要求，博圖V14版本以上只有SCL編程語言的PEEK_BOOL/POKE_BOOL指令可以比較方便的實現對硬件IO位地址的間址尋址，即間址讀寫訪問。
圖4為通過PEEK_BOOL / POKE_BOOL 指令實現硬件IO位地址間址尋址的硬件IO地址說明表，采用UDT形式，以便后續程序中多次調用，變量具體說明如下：
Area： 16#81 代表輸入 (Input)
16#82 代表輸出 (Output)
Byte_Offset： 字節地址 >= 0
Bit_Offset： 位地址 0-7位
Value： IO位變量的值，輸入為寫操作，輸出為讀操作
Status： 16#00 代表IO未被使用 Deactivated
16#01 代表IO被使用 Activated
16#FF 代表IO說明錯誤 Fault
圖5為IO變址映射功能FC1000，SCL語言編寫，輸入輸出通用，根據硬件IO地址說明表中指定的硬件IO地址讀取輸入點的狀態或刷新輸出點的狀態，每個硬件IO位調用一次。
我們引入控制對象的概念，示例中每一個電機就是一個控制對象，每個電機控制對象包括了4個位輸入，2個位輸出，1個背景數據塊，通過控制對象硬件IO表（UDT）將每個控制對象的硬件IO關聯到一起。可以有以下兩種定義方式：
圖6所示直接根據控制對象硬件IO的名稱定義控制對象硬件IO表，這種方式后續再封裝程序的可讀性強一些，與控制功能塊的輸入輸出管腳定義是一致的，即控制對象硬件IO表與控制功能塊輸入輸出是明確指定關聯關系的。然而一個控制系統的控制對象往往是多樣化的，其硬件IO的數量和類型也會不同，這樣做的結果是不同的控制對象，就要定義一個對應的控制對象硬件IO表，導致編程過于繁瑣，另外也不利于控制功能塊多次調用后實現對硬件IO表的訪問的編程；
圖7所示采用數組形式定義控制對象硬件IO表，只要數組變量的數量滿足需求，可以事先不用確定數組變量關聯的硬件IO其類型究竟是輸入還是輸出，滿足程序標準化柔性化的要求。
圖9-12為基于原控制功能塊FB1基礎上再進行封裝的硬件IO可定義的控制功能FC100，實際上就是通過IO變址映射功能FC1000將一個未指定的控制對象硬件IO表與原控制程序FB1進行了關聯，FC100的每一次調用就代表了一個硬件IO可自由定義的控制對象。
封裝好的硬件IO可定義的控制功能塊FC100
當然硬件IO表中的元素是否一定要與原控制程序FB1關聯，也是可以自由選擇的，本例中考慮多個控制對象的故障復位命令信號可能會共用同一個變量，因此FB1的Reset參數就未與控制對象硬件IO定義表關聯，而是單獨直連FC100的同名輸入變量了。
圖13-14是一個具有10個控制對象的小型MCC控制功能塊FB100的完整示例程序，在保留原有傳統控制功能塊FB1的控制功能的基礎上，又實現了任意一個控制對象的硬件IO點可自由定義的功能，且硬件IO點的關聯與激活亦可由用戶靈活決定。
由于底層的硬件IO地址說明表采用了結構數據，中間層控制對象硬件IO表及頂層控制對象功能調用均采用了數組結構形式，因此整體控制程序結構變得極為簡單，循環調用即可，數組結構也使得每個控制對象關聯的硬件IO地址說明表很容易通過間址尋址的方式實現讀寫訪問，甚至是不同的控制對象且每個控制對象關聯著不同數量的硬件IO點。
由此可見，在博圖環境下通過上述的編程思路和方法，硬件IO可定義MCC控制功能塊的程序代碼得到了極大的精簡，且控制對象的數量多少以及每個控制對象關聯硬件IO點的多少均與程序代碼量無關。
圖15為硬件IO可定義MCC控制功能塊在OB1的調用，我們可以通過變量修改的方式修改DB100中IO_Obj數組變量關聯的硬件IO點，示例中激活了3個控制對象關聯的硬件IO點，分別位于S7-1200不同的IO擴展模塊上，地址定義如圖16-18所示：
三、應用體會
1、博圖的創新平臺，使得通過用戶程序實現硬件IO自由組態成為可能，可保留原有傳統的成熟應用的控制功能塊，無需對原有功能塊進行改造，不需要復雜的編程，在梯形圖下即可很容易地實現（示例中的硬件IO變址映射功能FC1000亦可在梯形圖環境下編程，只是在使用PEEK/POKE指令時需插入SCL語言程序段），并且實現S7-1200/1500通用化。
2、示例中是針對一個功能塊FB來實現其輸入輸出參數硬件IO地址用戶程序可組態的功能的，然而在實際編程中發現FB的多重背景應用是可以數組化的(含V14版本以上)，但參數實例只能是單個的數據塊定義而無法數組化定義的，這給編程的靈活性還是帶來了一定的影響。
因此多控制對象應用必須通過FB的多重背景才能實現，期望博圖軟件在這方面能夠更有進一步的創新，以方便用戶程序開發。
反之，這也讓我們看到了另一種可能性，即用FC加全局DB替代FB(這種方式編程在S7-300/400/1200/1500的軟件開發中不常見)，利用全局數據比較容易實現數組化的特點，同樣在原有程序基礎上實現硬件IO地址用戶程序可組態，也許這樣編程方法會更加的靈活簡單。
3、有一種情況我在前面應用背景的描述中沒有提及，即IO點如果損毀，那么我們不用修改程序就可以替換IO點了。的確是可以這么做，而且很容易實現，這是硬件IO用戶程序可組態的編程方法實現帶來的“副作用”，當然這是有益的“副作用”，但是當初的確也沒有以“損毀IO無編程替換”為目的來做這項軟件開發的，沒有引入控制對象的概念，如果這么做反而是有難度的了。
4、本文講述了在博圖環境下通過用戶程序實現硬件IO自由組態的基本方法，還是原理性質的，其真正要應用到實際的項目中去，仍舊有很多的實際的技術問題需要去解決的，比如：
①在嘗試使用精簡型面板為上述系統開發一個簡易的硬件IO地址參數設置界面時，發現在優化數據塊訪問即全符號名訪問的設置下，HMI還是只能實現一維的數組變量的變址訪問(圖21所示)，其結果如圖20所示，IO地址參數設置界面的形式就只能與具體的控制對象綁定了；因此在目前博圖的技術能力下，要實現“去控制對象化”的通用標準化的硬件參數設置界面功能，還是需要通過PLC及HMI兩者緊密的編程配合來實現。
同時，面對數量眾多的硬件IO點的地址表，通過HMI逐一手工輸入的方式并不可取，費時費力枯燥易錯，HMI只能適合少量人工輸入及修改；因此，還是要有更簡便高效的方案來實現(比如通過計算機EXCEL文件編輯硬件IO地址表，把它導出為格式文件，然后拷貝到PLC的MMC卡，再由PLC程序讀取格式文件的數據到內部數據塊的方式)。
②在實際應用中，PLC硬件的組態是變化的，實際可尋址的IO物理地址范圍也是變化的，因此，實現硬件IO地址尋址范圍的合法性判斷，從而避免程序的尋址錯誤也是很有必要的。
③本文闡述的硬件IO用戶程序可組態的編程實現方法，使得程序的硬件IO尋址由顯式尋址改為隱式尋址，因此通過程序代碼來檢查某個硬件IO是否被重復使用的可能性幾乎沒有，尤其輸出類型的硬件IO點是需要嚴格限制重復訪問的(不僅僅是輸出多線圈問題，還有多控制對象使用同一輸出點的安全性問題)，因此硬件IO點地址參數設置查重也是一個很重要的技術點，似乎每設定一個硬件IO點的地址就要比對所有已有的硬件IO地址的方法是不可取的，這個運算量不是一個普通PLC能夠勝任的。
④在實際應用中控制對象IO定義動態修改所引發的控制系統安全隱患也必須引起足夠的重視，并且要有可靠的對策；輸入點的再定義會導致控制信號產生額外的信號變化，輸出點的再定義會導致被替換輸出點的失控以及替換輸出點意外輸出或切斷，因此本實現方法實際并不適合IO定義的動態修改，比較安全的做法是在設備整體停運，主動力電源被有效切斷的前提下，IO再定義功能才能被激活使用，并且應配合HMI的權限管理功能。
⑤PLC如何永久保存已經設置好的硬件IO點的地址參數，在經歷了PLC長時間斷電，斷電重啟，數據區總清復位后，系統如何能夠依舊正常地工作。西門子S7系統事實上也已經提供了很好的解決方案，示例中如圖16-18所示的背景數據塊DB100中Ctrl_Object_DB.IO_Obj的數組結構是存儲硬件IO點的地址參數的數據區，我們可以通過WRIT_DBL指令將該數組結構的內容拷貝到CPU具有“僅存儲在裝載內存中”屬性的數據塊中，起到永久保存設置參數的作用；等到系統重新上電初始化時，我們通過OB100觸發READ_DBL指令，將備份的數據又拷貝到CPU工作內存中的DB100 Ctrl_Object_DB.IO_Obj的數組結構中去，恢復因斷電或總清而被清除的設置參數。
博圖下通過用戶程序實現硬件IO自由組態的基本方法，為各類自動化控制系統實現軟硬件層面的模塊化，標準化，柔 性化設計提供了又一種切實可行的方案，也體現了博圖平臺與S7-1200/1500系列PLC的卓越性能，相信隨著博圖平臺的不 斷完善，一定能助力西門子自動化用戶實現更多更好的創新應用，創造出更大的價值！
