0208 【萬泉河】終于被松下PLC打敗
2月2日上周四，進行了LBP培訓課程講座的第一課，生成了課件，已經參加的學員如果在當堂沒有聽懂看懂，可以再參考課件內容，逐步自己實現。所以， 如果沒有來得及報名而想要學習LBP的同行，也仍然隨時可以報名參加。就不需要等開課時間了，直接一步到位收到課件，跟隨課件學習。
總的來說，我做LBP的培訓就是手把手帶大家演練如何實現LBP的應用。做好了一次， 以后就永遠有用。
那么一些入行還不夠深，現在還沒有認識到自己有學習使用LBP的需求的，可以在將來，比如N年之后發(fā)現了自己達到了那個層級了，想要使用LBP框架，卻發(fā)現自己掌握LBP有困難的時候，再來報名學習也不遲。
而我自己，完成第一堂課之后到現在銷聲匿跡了將近一周時間，做啥去了？
做松下PLC的標準化去了。
松下FP-XH PLC的編程軟件FPWIN PRO7，我以前研究過，只是確認了可行性，就沒有繼續(xù)再做。
所以，在培訓課程的欄目里，要求的是先學習OMRON或者三菱的標準化，然后自行研究升級到松下PLC實現。
然而我忽視了系統(tǒng)軟件平臺的性能，或者說沒能參透松下軟件開發(fā)者的腦回路，然后鬧了烏龍，翻車了。
起因是這樣，有一個同行，數次跟我聯系想學煙臺方法，然而對我提及的不管西門子還是歐姆龍，三菱都不感興趣。因為他全都沒有碰過�，F在的公司只使用松下FP-XH的PLC。所以要他先去學會其他品牌，再學透，再學會在松下PLC的應用，就有點難度太大。
于是他就提出先交一半定金，等我專門做成松下PLC的標準化程序之后，再付另一半。
也寄了一臺他手頭的PLC硬件給我，供我開發(fā)時測試用。正好，講座完成的次日，就收到了快遞，所以就開始做煙臺方法的程序遷移了。
這位朋友不會ST編程語言，只會梯形圖，為了方便他將來的學習理解，我就沒有從現成的ST程序中移植，而是從頭用LAD搭建的FB塊庫函數。當然， 參照了一部分SMART200的煙臺方法的程序，以及《三菱PLC標準化編程煙臺方法》書稿的樣例程序以及我進一兩年寫的文章中提到的一些庫函數。
差不多3天時間，底層庫函數基本完成，然后分別建立了一些實例，開始拼裝，開始準備做自動部分了。
然后就發(fā)現了問題。
編譯不通過，報錯誤為：
錯誤：PLC中沒有足夠的可用子程序數量，請刪減調用的用戶自定義的FUN和FB的數量，或改變成具體有更多子程序的PLC機型。
被這個錯誤提示直接給干懵逼了。分析了很久后找到了原因。
原來松下PRO7的平臺，在編譯我們做的FB/FC程序的時候，并不是給做成真正意義上的重復調用的函數，而是對每一次調用，都給把參數的實際變量的地址代入，做了個一次性的函數跳轉。即一個FB如果調用10次，那么就生成了10個不同編號的SUB，分次調用。
就好比，你總結了一個A+B+C=D的數學公式，但到了松下的系統(tǒng)里面，他不給你列公式，而是把可能用到的算式全部給列在里面了：
1+1+1=3
1+2+3=6
2+2+2=6
2+3+4=9
3+3+4=10
等等等等。
原本，這種方法除了浪費一點程序空間，編譯代碼量增大之外，別的也無所謂。然而FP-XH的PLC， SUB的編號最大只到255，即最多只能有256個函數調用。
這就難倒我了。
標準化的基礎是程序功能的模塊化，通過把相同的功能封裝成塊，通過重復調用，減少了咱們人工的重復工作量。
比如，我現在比較在意的一個數據格式是設備時間參數格式都使用以S為單位的浮點數。這樣在數據交互過程中就少一個數據類型和數據轉換的過程。
所以，我通常開頭第一步，是對原本定時器功能做一個封裝，設定值和運行值都改為浮點數，然后程序塊中所有需要用到定時器的地方，統(tǒng)一使用自己新封裝的定時器。
有人一直對煙臺方法不理解，以為我在推行強制編程標準。其實如果有的話，對定時器數據格式的統(tǒng)一，可以算作一項，可能也是僅有的一項了。但也只是對我自己和煙臺方法學員的一種倡議。
這在平常的PLC系統(tǒng)，原本都沒有問題的。然而到了松下，問題就出來了。
我這種對定時器的封裝方法，如果對應到過去傳統(tǒng)垃圾程序的寫法，一套系統(tǒng)用到256個定時器會把定時器資源耗光的話，我這里就是一步到位同時把子程序資源也耗光了。得，我啥子程序都不用寫了。還做什么模塊化，標準化！
如果我現在真的要做這樣的項目，那方法就是把所有的封裝全部拆掉，比如定時器，所有程序中用到的地方，再不厭其煩地前面加入REAL到TIME的轉換，后端需要監(jiān)測運行值ET時再做TIME到REAL的轉換，程序不做嵌套，所有FB塊都一氣呵成，大概也能做成標準化的架構。
那對我來說就太惡心了。
原本，松下PLC還有個舊一點的軟件FPWIN GR7，同一款PLC也仍然可以在那個平臺上編程，那個平臺是和我研究過的信捷XD一樣，沒有現成的FB/FC功能，所謂子程序全年都靠著跳轉來實現的。我如果非要自己部署規(guī)劃，和當時在信捷中實現的一樣的方法，也能做好。
然而也會吃和信捷同樣的虧。信捷XD PLC新版軟件開始具備了FB/FC功能，我做的超前研究價值被清零了，而松下這里既然已經有了高版本的軟件，如果我在低版本里面做，那么只要廠家隨時把PRO7的軟件做個升級，改變編譯方法，比如到PRO8之后這個問題就解決了，那我就又白做了。
所以，思考一個晚上后，昨天早上還是跟對方工程師聯系，退款給他了。
認敗，才是更好更體面的退出方式。
由此我想到了歷史上曾經的WINTEL聯盟，微軟和英特爾兩家公司互相配合互相促進和提高，互相給對方提出更高的需求，而自己提供更高級的產品，最終促進了整個IT行業(yè)的飛速發(fā)展。
而在工控行業(yè)，需要有更多和我一樣的PLC應用工程師，從應用角度，對PLC廠家軟硬件平臺提出更貼合應用實際的需求，他們改進提高之后，也可以促進提高我們的應用水平。
由此實現相得益彰的TIKTOK滴答。
所以，總有一些同樣的PLC應用工程師，從個人聲譽的角度要爭什么行業(yè)大佬資格，從而互相碾壓攻擊，你們如果有那樣的理想，不如多做些基礎的研究工作，提出更高的問題，為行業(yè)集體發(fā)出一些呼吁的聲音，最終才能促進行業(yè)的發(fā)展。想爭第一的名份的，先看看自己手里有多少翻車的教訓，有提出過多少新的理論方法貢獻給行業(yè)。
我一個人的聲音顯然太微弱了些。
滬公網安備31010802001143號
