S7-200的子程序SUB，一旦寫好，用在程序中之后， 是不可以修改其輸入輸出管腳的。 因為你一旦動了管腳接口，調用這個子程序的地方，就會報錯。

報錯以后還沒法和STEP7一樣可以通過更新只更新改動部分。正常處理的只有把原本的調用刪掉，從頭重新調用，并為每個接口逐個分配變量。

這相當討厭。

比方說我一個底層的設備，如果調試中發現需要增加些功能，實在不可避免決定要增加接口。而我主程序中已經對這個設備調用了幾十次，那就必須幾十個實例都重來一遍。

而這還不算完。

誰敢保證這一次接口的變更就是最后一次了呢？下一次如果還需要修改，就需要原樣再來一次。

估計換誰，都受不了這種折騰。

而這也是標準化編程的大忌。

貌似許多人對標準二字有誤解，看到我提出的標準化，就有些不服氣。你萬某有何德何能提出標準，俺們智力才藝都不比你差，憑什么要遵循你提出的標準，憑什么用你的標準而不是我自己的標準？我們國家歷史上因為技術標準落后一步而受制于人，吃的虧大了去了。可不能重蹈這樣的覆轍！

而另外有一些人，則強調沒有辦法做到整齊劃一的標準。理由是設備配置千差萬別，沒有一模一樣的設備，所以做不到標準化。

錯啦！都是屬于對標準化的誤解。我們追求的標準化，是把系統做成搭積木一樣的標準模塊，每個模塊自成體系，邏輯互不干擾。通過接口與其他系統模塊對接，不同的系統設計，在接口不變的情況下，只需要更換相應的模塊，即可以實現快速組裝。

而接口，也不是一塵不變的，可以根據需要隨時改進，而在接口改動的時候，也只是對接的模塊之間局部變更，不要影響到整個系統。不會因為接口的改動，而需要系統重新調試。

甚至，我現在推廣了二期標準化示例項目之后，下一步的計劃就是對接口的優化升級。過去，我在開發階段，采用的接口只是借用的別人以前做的，現在終于有精力，騰出手來，把接口改造為我滿意的樣子。

而我和我的團隊成員，絲毫不需要擔心接口的更改會導致影響到已有邏輯模塊的運行，甚至帶來bug。

這就是標準化設計的優勢。心不累。不需要和以前一樣，程序中改動一點點就緊張萬分，就擔心把整個系統原本正常運行的功能搞崩潰。

所以，我在開發SMART 200標準化架構的時候，首先就意識到子程序（庫函數）接口不能更改的這個問題很嚴重。并認為有可能是眾多人都不愿意投入精力在SMART 200系統做標準化的主要原因。

所以首當其沖必須解決這個問題。

而實現方法，其實很簡單。

即利用程序塊的導出功能，把調用被改動的子程序導出為AWL的文本文件：

然后在文本文件的調用中，修改到符合新版本的函數的語法，再重新導入即可。

這里存在的問題是，不管是導入還是導出，操作之前軟件都會自動編譯，編譯通過后才可以進行。所以導出必須在修改接口之前，而在修改接口之后，導入之前，需要把相應的SUB內發紅的段落先刪除。

因而實時的存盤備份非常重要。千萬不能上來就改接口改子程序的邏輯，改過之后發現既不能導出又不能導入，那就尷尬了。

由于AWL文件中是絕對值尋址的，所以界面非常不夠友好。我通常是在文本修改階段，只管語法正確，比如增加的數值變量，就先填上AC0，如果是離散變量，則暫時輸入L0.0，等導入成功之后，在梯形圖界面下，根據實際需求，更改為正確的變量。

當然啦，如果有可能，盡量直接用搜索替換比如把原有的”AC0”替換為“AC0,AC0”。速度會快很多。

所以，在使用標準規范中也包含了同一個類型的設備對象，盡量在同一個SUB中調用。這樣導出修改接口的時候只搞這一個文件即可。而不必在整個程序范圍去找，去把整個程序的SUB都導出來手工修改。

那樣兒，仍然會很累。