0.1 標準化功能

所謂PLC的標準化功能，就是一些常見的可以供所有人重復使用的函數或者實例化功能，比如一個電動機的控制功能、西門子的Epos的功能塊（Function Block，FB）：FB284/FB285。

但談論標準化功能的時候也要分情況探討，看這些標準化功能的作用范疇。

1.產品供應商或者獨立的組織

比如西門子這樣的供應商，其提供的庫或者功能一定要讓所有的人都能使用，比如Epos的功能塊、基本運動控制庫LAxisCtrl及其他很多類似的庫，由于這些標準化功能要供各個行業使用，所以它們不能有很多局限性的東西，比如里面應用到M寄存器等類似的變量（因為這些變量開發者可能會用到）。因此，這些標準化功能一般都是需要實例化的功能塊或者一些函數，并且里面的程序變量一般都是靜態變量或臨時變量。

由于潛在使用者是各個行業，所以這樣的功能塊或者函數的功能一定是針對產品的功能，不會涉及具體工藝（飛鋸控制庫屬于工藝標準庫，不是功能庫），這樣用戶只要參照文檔即可像使用PLC自帶的指令一樣方便，并不會對自己的程序帶有任何負面的影響。

還有一些獨立的組織，常見的比如PLCopen組織，他們定義了一整套運動控制的相關指令和方法，這些指令就是各個PLC廠商都在應用的MC指令。用過不同品牌PLC的人肯定會發現，其運動控制指令從名稱到實現方式都很相似，不同的只是依據各個品牌的特點做了一些相關的改進。

2.設備開發商或者系統集成商

這類開發者開發的標準化功能都是只有在自己公司的項目上才有使用價值，對于第三方用戶來說，只有思路的參考價值，并不能直接使用。

比如電動機控制，若要將電動機所有存在的可能性功能做在一個標準功能塊，電動機是工頻控制還是變頻控制，有沒有多段速控制，有沒有方向的切換，遠程起動還是本地起動，不同控制方式的錯誤診斷等，把這些功能全部實現的話，那這個功能塊的引腳會非常多，使用起來會非常復雜（在PCS7中經?？吹胶芏嘁_）。

對于一個設備開發商或者系統集成商來說，僅用于匹配他們的電動機控制需求可能沒有那么多，同時對于一些工藝設備來說，往往簡單的一個電動機功能塊也只是工藝設備需要的底層功能塊（因為電動機的控制需要結合工藝需求實現不同時序要求，Epos也可能是工藝設備的底層塊）。這個時候，這個標準功能就沒有必要大而全，也沒有給第三方使用的必要。反而，這樣的標準功能塊的效率會更高，對于和工藝的匹配最精確。

由于不需要考慮第三方的使用需求，這個時候該模塊可以結合自身程序架構編程。有的程序架構中可能會使用一些M寄存器的變量，這些變量都是自身程序架構中已經定義好了的，即使有需要使用的時候也會有一些預留區域，在設計標準功能塊的時候就需要結合自身程序架構理念，實現工藝和程序架構的無縫匹配。

這也是很多國外以前的程序中M變量頻繁出現的原因，因為這些程序和自己設備工藝以及程序架構是無縫匹配的，同時也不需要像西門子一樣提供給可能存在的所有從業者使用。

這樣的功能塊對于其他人來說不是標準功能塊，但對于該設備開發商或者系統集成商來說，這就是他們的標準化程序，是他們效率和質量的倍增器（3～4個工程師一年可以做2～3個投資過億元的大型項目，這是筆者的實際經歷，這就是倍增器的加持效果）。

在Portal優化使用的時代，不建議使用M寄存器。

3.設備編程原則

具體到一個設備或者對象，在編程的時候怎么去開發標準的程序呢？答案就是遵循事物本來的面貌去（面向對象）做一個系統的開發和應用。

如圖0-1所示，有個工件需要從設備1傳送到設備2上。為保證工件能完全到達設備2，更多的人都是在設備1末端光電器件被觸發后，延時足夠的時間來確保工件能完全傳送到設備2上。

以上思路并沒有問題，但實際調試發現針對不同的傳送速度（工件不變），這個延時時間還得慢慢調整，否則要么工件還沒有完全到達設備2，要么就是延時太長降低了設備的工作效率。

但我們的程序是工件實際軌跡或者說本來面貌的完全體現嗎？

顯然不是，時間只是工件傳輸過程的一個表象，工件傳輸的實質是位移，即工件在離開光電器件后還需要向設備2的方向再移動一個距離L（跟設備1和2的速度以及時間相關）。

這才是這個工件傳輸過程中的本來的面貌，本書內容要強調的是，所謂的編程，是現實的實際內容在程序世界的再現或者重構，這樣的程序才能更加靈活，適用性更強。后續章節中，也會有這個相關內容的介紹。