在FB功能塊的不同接口處使用UDT數據類型的比較

       之前在做一個項目時用了很多FB功能塊，并且把對應的上位機監控數據放在了IN-OUT接口，結果運行時發現CPU掃描周期很大，接近100ms，控制非常吃力。后來發現是因為在FB的IN-OUT接口使用了UDT類型數據的緣故，因為在IN-OUT接口使用UDT后FB的背景數據塊就只保存訪問指針，運行時采用指針的方式直接訪問接口實參，在FB中每引用一次IN-OUT接口的UDT類型變量元素，程序的工作存儲器占用就有40多字節，而普通變量只占用不到10字節。最后沒辦法把所有IN-OUT接口的UDT拆分到IN和OUT接口，工作存儲器馬上就降下來了，掃描周期降低了很多，見下圖比較。這個問題之前也發帖討論過。

        自從發現上述問題后，我一直不敢再把UDT類型的上位接口放到IN-OUT區了，但是也帶來了一些麻煩，比如有的時候需要程序判斷上位輸入是否合理，如果不合理就通過程序糾正，如果上位接口在IN區就無法在FB內賦值糾正。為了徹底搞清楚這個問題，我最近做了一個測試比較，方法就是創建一個UDT數據類型，包括8個BOOL，2個INT和2個REAL，然后在FB中寫三行程序，分別調用三種變量。通過把UDT放到IN接口和IN-OUT接口比較FB占用的裝載存儲區和工作存儲區的大小區別，還通過增加BOOL和INT變量調用比較每增加一次調用占用的裝載存儲區和工作存儲區的大小區別。程序如下

        STEP7軟件采用5.5SP4，組態CPU為315-2PN/DP V3.2，比較結果如下：

        從以上比較可以發現，在IN接口使用UDT時，每增加一次接口元素調用工作存儲器只增加8或10字節（因指令和數據類型不同而不同）；而在IN-OUT接口UDT時，每增加一次接口元素調用工作存儲器增加了46或48字節（因指令和數據類型不同而不同），每次調用比IN接口時多了38字節，同時裝載存儲器增加的更多。所以得出的結論是在STEP7平臺下盡量不要在IN-OUT接口使用UDT數據結構，如果需要使用我最近改進的做法是先把接口數據同步到FB內部變量，在程序調用時使用內部變量替代，只在程序反寫接口變量時才使用接口變量，最大限度減少在FB程序內調用接口變量。

        目前STEP7平臺使用越來越少了，大部分程序都可以用博圖來寫，那么在博圖環境下是否有同樣的問題呢？我把上述測試方法在博圖V15環境下復制了一遍，同樣組態315-2PN/DP 的CPU，結果如下；

        通過與STEP7平臺比較發現結果差不多，每增加一次調用增加的工作存儲器大小是一樣的，也就是說對于300系列CPU來說，使用STEP7和博圖編程都有這個問題，那么應對方式也是一樣的，盡量減少調用頻次，因為工作存儲器是不可擴展的，調用多了還影響掃描周期。

        最后我又在博圖V15上組態1500系列CPU做了一次比較，結果如下：

        通過比較結果可以發現兩者已經沒有什么區別了，甚至在IN-OUT區使用時存儲器占用還少了一點，說明在1500plc上已經沒有這個問題，可以放心大但的去使用了。原來因為300的前車之鑒我在1500下也不敢在IN-OUT區使用UDT數據，下一步就準備把目前的程序塊移植到1500上優化一下測試實際結果。