電子發燒友App
0917 【萬泉河】關于PLC中UDT和FB的迷思
我在上個月寫過一篇文章《0820 【萬泉河】就是要為不用UDT而不用UDT》，文章題目看起來挺繞的，挺燒腦的吧？
嗯， 不光題目燒腦，內容對大部分同行來說也相當燒腦。
我在寫文章的時候就預料到了，會有大批的同行看不懂。但我也提醒了，暫時看不懂沒有關系，只要你持續不斷地學習，未來十幾年的時間里，定期回來重復閱讀，總有一天有可能會有理解。然后你的編程水平就會有一個大幅度的提升。
我也在其他一些場合多次提到過一條認知上的基本的道理，就是一個人，對于自己認知之外的新見到的知識和道理不要隨意妄加評判。
有人會說了， 難道討論也不行嗎？你可以去私下討論，可以請教，但不要先下結論。至少，長久以來，我自己是這樣做的。
有興趣的讀者可以在閱讀完本文后去稍微圍觀一下。但不建議閱讀本文之前先去圍觀，因為容易被帶跑偏了。
我原本就多次說了，我關于UDT的話題是超前的話題，任何人看不懂也沒有關系，也不影響你完成現在的程序設計。我只是提前把一個理論放在這里而已。然而這位寶冬網友非但要討論，而且還指責我誤導他人，而在我看來他的那些亂七八糟的說法才是恰恰起到了誤導的作用，所以為了避免這種流毒，摘一點他的核心觀點評判一下。
（注意觀察什么是正確的評判姿勢？就是你說的這些我都懂，都聽說過，但我知道它不合理，所以反對這樣的說法。而不是你說的對我全都是新的，但因為和我習慣不同，我就要按照我原有的理論框架來論證推翻它。）
寶冬的主要觀點原文中兩句話：
一個UDT應該被理解成一個接口。一個FB應該被理解成一個類。
我全文就只評價這2句話了。
首先，這是一個病句。
你首先要知道UDT和FB是所有PLC甚至計算機系統中都有的概念。而不唯獨西門子PLC，也不僅僅S7-1200中有。
你可能會辯解說， 廢話！我帖子發在S7-1200的版區，當然指的是S7-1200了。然而，即便加上S7-1200的限定語，也仍然是遠遠不夠的。你還忘記了PORTAL軟件的發展歷史， 沒有看到在PORTAL軟件從V10.0到現在V18.0不斷升級過程中UDT和FB性能的變化升級過程，更沒有想到，未來，西門子在對軟件升級過程中有可能對這兩者的性能做升級。
而我不僅僅看到了其過去的升級， 也一直在期盼未來它們在某些細節功能方面的改進。比如我講過多次，我做PLC標準化編程是從PORTAL V15開始的，就是因為它實現了我長久以來所期盼的功能升級。而我目前也仍然有期盼，如果能實現，也能幫助我們實現很多功能，效率有很多提升，細節就不提了。
所以，這個觀點中對UDT和FB的理解，都是有偏頗的。
UDT是什么？用戶自定義數據類型。所以，它更應該和系統已經內置的簡單數據類型和復雜數據類型（如DTL,LTD等）功能一樣，能實現同樣的功能。
所以如果你認為UDT是接口的話， 那么是不是一個普通的數據類型， BOOL , INT， WORD都可以理解成接口呢？
這顯然是不能的咯！所以可想而知， 本質上你還是對UDT有些恐懼，覺得它神秘莫測，所以才非要給它規劃一些特殊技能。
而叫我說的話，UDT本質上是數據類型，而FB本質上也是數據類型。
有沒有被驚訝到？
這一點， 由于PLC平臺之間變量命名空間的規劃設計不同，在PORTAL中不太容易展現。那么我先在倍福的TC2中即CODESYS中做個舉例。
比如我有一個模擬量AIW001， 我要對它做數據處理， 做個FB塊叫做FB_ANALOG，同時按照你們的習慣，還要做一個UDT，放在FB的管腳上，便于數據的交互，那么這個UDT可以起名字為UDT_ANALOG。
那么在一個模擬量的情況下，需要為上述建立3個變量標簽，分別為AIW001, AIW001_IDB, AIW001_UDT。
看到沒， 不管是FB的名字還是UDT的名字，都是列在TYPE一列的， 與INT數據類型同列。
而我們在按下shift+F2新建變量的時候，所彈出的輸入助手對話框中：
可選的類型中， User defined Types即UDT， 與User defined Function Blocks即我們制作的FB，赫然并列。
而回過頭來看PORTAL編程環境中， 就有一些不同， 當然其中主要原因是西門子傳統上有全局數據塊和背景數據塊導致的， 而其它廠家因為沒有這兩者，而一概統稱為標簽，就沒有了區別。
區別如下：
在當下所見到的PORTAL版本中，全局數據塊中可以建立UDT類型數據，但不可以建立類型為FB的數據。
在全局變量表中，只可以建立指向變量地址的基本數據類型和UDT數據類型，但不可以如CODSYS般直接建立UDT的數據變量標簽（只能在全局數據塊中）。
而在PORTAL的全局變量表中，也不可以建立FB類型的變量（即IDB）。但其實在舊的STEP7 V5.X中，是可以的。即STEP7V5中，是把IDB當作一類數據的。? PORTAL之后只不過把IDB當成文件在文件列表中顯示，而不在變量表中展示了。但其實兩者仍然共享的同一個變量命名空間。比如你如果建立了一個AIW001的INT數據類型，用于接到AI模塊的通道，就不再可以建立FB的IDB也叫做AIW001， 提示名稱沖突。
但在PORTAL中有一種命名空間可以允許上述的三者數據類型INT , UDT和FB共存，那就是IDB， 即在定義一個大的FB時，其數據的命名空間可以同時容納三種數據類型， 與演示的倍福中接近。
而且，可以看到，不僅僅在靜態變量中可以建立這些數據類型的實例，在接口的INOUT中，也同樣可以。
即，從接口的角度看，UDT可以作為接口，FB也可以作為接口，這兩者是幾乎等價的
我們再從寶冬所關心的類的角度看UDT和FB。
在任何PLC中， 如果UDT和FB都只是建立了而不使用，則二者都完全不起作用。所以必須建立以它們為類型的數據變量，即實例化。在CODESYS中這一點描述比較簡單， 就是在全局變量表中建立實例。而在PORTAL中描述稍微復雜，如前文所述。但簡單來說，就是都需要實例化。
而這兩者并沒有什么不同。
所以，站在面向對象編程的角度， UDT和FB都可以作為對象的類來使用。在一個功能不夠的使用， 祭出來另一個打輔助。而如果1個夠用的時候， 則另一個完全可以靠邊站，讓它失業都沒問題。
所以總結全文， 針對寶冬同學的觀點：
一個UDT應該被理解成一個接口。一個FB應該被理解成一個類。
我的結論是：
從接口的角度，UDT和FB同樣都可以作為接口。
而從類的角度，UDT和FB也都同樣可以作為類。
當你認為這兩者有區別的時候，原因有2個，一是系統平臺提供的功能還不夠完善，二可能是你掌握的理論基礎和編程技能還不夠全面。
當然， 目前看， 第一條， 至少SIEMENS PORTAL系統平臺在這方面是完全及格夠用的。
而第二條的話， 這也不能全怪你。PLC行業原有的編程理論原本就非常少，大多數人都還只能從廠家的手冊中學習基礎技能，而你能從網上能檢索到的理論和技能文章都非常少，除了我的專著、專欄和公眾號。
編輯：黃飛
?
工商網監
評論