0327 【萬泉河】論算法在PLC控制系統(tǒng)中的重要性
我猜，有一些同行對PLC控制系統(tǒng)中的算法的認(rèn)知，可能有一些謬誤。 可能是他們在入門學(xué)習(xí)時候，經(jīng)受了一些不靠譜的培訓(xùn)課程的誤導(dǎo)，告訴他們算法為王，算法為王。嚴(yán)重夸大了算法在整個控制系統(tǒng)中的重要性。
比如， 我發(fā)的80模擬量標(biāo)準(zhǔn)答案的文章，就有讀者在后面短短幾十個字內(nèi)，把算法和循環(huán)邏輯回復(fù)給我了，告訴我那是他的更優(yōu)答案。
（* 工程量：=模擬量/27648*量程 *）用數(shù)組，800個模擬量也就一個for搞定。
FOR #ii := 1 TO 80 BY 1 DO g_rActSensorH[#ii]:=rSensorAnalogH[#ii]/27648.0 * rSetSensorRangeH[#ii];
以及那個扔了一個FC給我的家伙。
眼里面的控制任務(wù)就只有算法了，真以為算法為王， 掌握了算法就擁有了一切，就掌握了世界。
乃至于我跟那位拋答案的又回復(fù): 就假設(shè)我們收到的80個模擬量全都直接就是浮點數(shù)的物理量，不需要你轉(zhuǎn)換了。 你只做錄入吧！把80個數(shù)據(jù)錄入到程序中，我要的是這個程序。
80模擬量的程序，主要的目的是為了完成80個數(shù)據(jù)的信息錄入， 轉(zhuǎn)換工作只是其中小到忽略不計的工作量。 甚至，因為這點算法太簡單， 我們通常還要順便再加點算法，搞幾個上下限的閾值， 做限制值判斷，以供報警顯示和程序自動邏輯用到。
這幸虧還是模擬量， 不是開關(guān)量。 如果是80個開關(guān)量信號的處理， 那更扯，更是沒有算法可玩。 我們在標(biāo)準(zhǔn)化煙臺方法中，對一些獨立于L1設(shè)備之外的單個開關(guān)量輸入信號，都又強(qiáng)迫給加了濾波，并默認(rèn)關(guān)掉不用的。 然而等個別信號需要防抖動的時候才設(shè)置個濾波時間再打開。
我都有點后悔標(biāo)準(zhǔn)答案不應(yīng)該拿模擬量做，而應(yīng)該拿DI輸入信號做舉例了。會少掉很多誤會。
而那位搞一個線性變換的FC就得意洋洋發(fā)給我秀算法的家伙，在拉黑我之后不知道啥時候又加回來，發(fā)消息要我給他做個PID的算法，我就直接沒再搭理他了。
PID還需要算法嗎？好多PLC控制系統(tǒng)里面都有現(xiàn)成的算法了。 比如SMART200中有向?qū)В?S7-1500里面有工藝對象，甚至都給PID設(shè)置了自動優(yōu)化的功能。 你不需要懂任何算法，調(diào)試中設(shè)置跑一下優(yōu)化過程， 系統(tǒng)的PID參數(shù)自動就得到了。
除此之外， 業(yè)界還有不下幾百家專門的PID儀表的廠家，你完全也可以選擇用PID表來驅(qū)動這些回路， PLC系統(tǒng)中只做數(shù)據(jù)顯示和參數(shù)給定， 還少了很多的計算資源， 算下來成本反而可能比用高性能的CPU還低。
如果你認(rèn)為對算法越精的工程師水平越高， 那么這些工程師應(yīng)該只在PID表的工廠里，專心研發(fā)這些表的控制工藝和參數(shù)，就足以拿行業(yè)最高薪資了。 都沒必要親自來做項目，靠著辛辛苦苦調(diào)試每一個項目來掙錢。
與PID算法類似的還有糾偏，飛剪，卷取等等工藝，凡是這些復(fù)雜計算工藝的應(yīng)用，都會有廠家打包生產(chǎn)專門的模塊或者設(shè)備或者算法庫，幫助對算法不熟練的工程師實現(xiàn)這些功能，而他們賺取利潤。 因為已經(jīng)封裝作為產(chǎn)品出售， 賺取的是規(guī)模效益，所以單價也不會高到離譜。
所以，如果你掌握了一點三腳貓的算法，或者準(zhǔn)確說是行業(yè)應(yīng)用經(jīng)驗， 那也僅僅是掌握了一門得以糊口的技能而已。 護(hù)城河沒多高，日常的辛苦工作仍然少不了。
人人都感慨工控行業(yè)的門檻低，哪怕學(xué)歷不高，只要腦子靈活，勤學(xué)好問，肯動手，也很快能入門。 只要入得們來，稍微有些資歷，工資就可以過萬，這些人可以認(rèn)為是不懂什么算法。 而這個行業(yè)中，能見到的頂尖的工程師，大概也就3萬也就封頂了。
所以，相比于沒有任何算法技能的一萬元，三萬元中所需要的算法技能也不會太多。 所以那些入門后以為通過再多掌握些算法，然后有可能獲得高薪的，恐怕要失望了。
所以，我的觀點是，所謂的算法， 在工控工程師中并不值什么錢。
還有一個佐證的例子。
有一位網(wǎng)友，搞農(nóng)業(yè)溫室的控制，疫情期間，一方面有些空閑，一方面項目中需要用到空氣焓濕圖的應(yīng)用，然后他就自己把大學(xué)期間學(xué)的高等數(shù)學(xué)微分方程等技能再拾起來，把焓濕圖的物理方程給計算解開了。
解開之后成為普通的計算方程，就可以直接在CPU中進(jìn)行計算，可以自由換算焓值、含濕量、露點溫度等工程中需要用到的關(guān)鍵物理值了。
聽說我有做過暖通空調(diào)方面的項目，就跟我聯(lián)系探討這個計算方法商業(yè)應(yīng)用的可行性。 并問我是否有興趣， 如果有興趣可以直接給我一個函數(shù)塊試試看。
巧了，我在幾年前的項目中確實遇到過這個問題。 然而我對空氣熱能方面的專業(yè)不懂，遇到這個需求的時候，先是從網(wǎng)上查了個簡易近似方程，做了個函數(shù)，做在項目里面交工了。
但后來設(shè)備廠客戶反應(yīng)，我做的函數(shù)，有一些個別工況下計算出來的數(shù)值不準(zhǔn)。 然而我因為不懂原理，所以也沒辦法審核求證。
然后一怒之下，直接把客戶使用校對的那個數(shù)值表格要來，花了幾天之間整理數(shù)據(jù)，給錄入到PLC中了。 然后使用雙線性插值方法，做了個查詢函數(shù)。
我讀碩士期間做過有限元計算方面的項目，所以工作以后雖然數(shù)學(xué)和物理方面的計算能力丟掉了，這點小數(shù)值計算還是輕車熟路的。 做好了以后替換了原來做的函數(shù)，交過去，再查，都正確了。
可不嘛， 我們查的是同一個表，當(dāng)然可以保證正確了。
所以這位朋友再來問我的時候，我就確實不太有改動的意向了。因為對我來說沒什么明顯的收益了。
然后我們又探討了很多回， 如何把這個成果商用。他有過想法做成標(biāo)準(zhǔn)庫，提供給那些PLC廠家，集成在系統(tǒng)中， 每賣出一臺PLC，哪怕只給一元的專利費即可。那自己也發(fā)大財了。
然而我們又認(rèn)識到可行性不高，而且不太容易實現(xiàn)技術(shù)方法的保密保護(hù)。所以還是建議他用單片機(jī)完全封裝做成單獨的產(chǎn)品，面向市場銷售。
去年年底的時候，跟我聯(lián)系告知我， 產(chǎn)品已經(jīng)做出來了。 前幾天更是告訴我，已經(jīng)批量生產(chǎn)，開始供貨了。市場反應(yīng)效果還不錯。
也把使用說明書發(fā)給我了。
《MSK系列溫濕度變送器使用說明書V1.0》
我這里附個網(wǎng)盤里， 有感興趣的同行可以下載了解。有需要的可以直接聯(lián)系其公司購買。
獲取方法后臺回復(fù)MSK，或者直接私信我。
我這里算是幫忙做個廣告。
回到本期討論的算法的話題。
前幾天， AD俱樂部深圳群里有個網(wǎng)友宣稱，所謂的PLC程序，根源算法就是個起保停。 再多的設(shè)備，無非是無數(shù)個起保停而已。
深以為然，感覺無法反駁。 我在去年寫過多篇文章，探討過起保停的話題。然而如果你認(rèn)為PLC程序里面只有起保停， 這在30-40年前， PLC剛剛誕生時，剛剛?cè)〈^電器邏輯的時候，是有道理的。 然而現(xiàn)在， 還這樣認(rèn)知，恐怕就有些落伍了。
讓我們再看一眼我近期反復(fù)提及的LBP例程中的電機(jī)模塊的程序：
20多個段落，300多行程序，里面與起保停相關(guān)的只有一個段落，三五句程序。 而其余的大部分程序是在做數(shù)據(jù)整理，數(shù)據(jù)傳輸方面的工作。
起保停是算法不錯，但你眼里如果還仍然只有這點三腳貓的算法， 那很顯然認(rèn)知上的差距很大了。
而如果你現(xiàn)在做項目還是在從起保停做起， 跟其他同行比起來，那效率也得是相當(dāng)?shù)土恕?
工資么，不說了。
我現(xiàn)在的微信號：ZHO6371995
以前有我微信的看一看還對不對。
滬公網(wǎng)安備31010802001143號
