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