0327  【萬(wàn)泉河】論算法在PLC控制系統(tǒng)中的重要性

我猜，有一些同行對(duì)PLC控制系統(tǒng)中的算法的認(rèn)知，可能有一些謬誤。 可能是他們?cè)谌腴T學(xué)習(xí)時(shí)候，經(jīng)受了一些不靠譜的培訓(xùn)課程的誤導(dǎo)，告訴他們算法為王，算法為王。嚴(yán)重夸大了算法在整個(gè)控制系統(tǒng)中的重要性。

比如， 我發(fā)的80模擬量標(biāo)準(zhǔn)答案的文章，就有讀者在后面短短幾十個(gè)字內(nèi)，把算法和循環(huán)邏輯回復(fù)給我了，告訴我那是他的更優(yōu)答案。

（* 工程量：=模擬量/27648*量程 *）用數(shù)組，800個(gè)模擬量也就一個(gè)for搞定。
FOR #ii := 1 TO 80 BY 1 DO g_rActSensorH[#ii]:=rSensorAnalogH[#ii]/27648.0 * rSetSensorRangeH[#ii];

以及那個(gè)扔了一個(gè)FC給我的家伙。

眼里面的控制任務(wù)就只有算法了，真以為算法為王， 掌握了算法就擁有了一切，就掌握了世界。

乃至于我跟那位拋答案的又回復(fù): 就假設(shè)我們收到的80個(gè)模擬量全都直接就是浮點(diǎn)數(shù)的物理量，不需要你轉(zhuǎn)換了。 你只做錄入吧！把80個(gè)數(shù)據(jù)錄入到程序中，我要的是這個(gè)程序。

80模擬量的程序，主要的目的是為了完成80個(gè)數(shù)據(jù)的信息錄入， 轉(zhuǎn)換工作只是其中小到忽略不計(jì)的工作量。 甚至，因?yàn)檫@點(diǎn)算法太簡(jiǎn)單， 我們通常還要順便再加點(diǎn)算法，搞幾個(gè)上下限的閾值， 做限制值判斷，以供報(bào)警顯示和程序自動(dòng)邏輯用到。

這幸虧還是模擬量， 不是開(kāi)關(guān)量。 如果是80個(gè)開(kāi)關(guān)量信號(hào)的處理， 那更扯，更是沒(méi)有算法可玩。 我們?cè)跇?biāo)準(zhǔn)化煙臺(tái)方法中，對(duì)一些獨(dú)立于L1設(shè)備之外的單個(gè)開(kāi)關(guān)量輸入信號(hào)，都又強(qiáng)迫給加了濾波，并默認(rèn)關(guān)掉不用的。 然而等個(gè)別信號(hào)需要防抖動(dòng)的時(shí)候才設(shè)置個(gè)濾波時(shí)間再打開(kāi)。

我都有點(diǎn)后悔標(biāo)準(zhǔn)答案不應(yīng)該拿模擬量做，而應(yīng)該拿DI輸入信號(hào)做舉例了。會(huì)少掉很多誤會(huì)。

而那位搞一個(gè)線性變換的FC就得意洋洋發(fā)給我秀算法的家伙，在拉黑我之后不知道啥時(shí)候又加回來(lái)，發(fā)消息要我給他做個(gè)PID的算法，我就直接沒(méi)再搭理他了。

PID還需要算法嗎？好多PLC控制系統(tǒng)里面都有現(xiàn)成的算法了。 比如SMART200中有向?qū)В?S7-1500里面有工藝對(duì)象，甚至都給PID設(shè)置了自動(dòng)優(yōu)化的功能。 你不需要懂任何算法，調(diào)試中設(shè)置跑一下優(yōu)化過(guò)程， 系統(tǒng)的PID參數(shù)自動(dòng)就得到了。

除此之外， 業(yè)界還有不下幾百家專門的PID儀表的廠家，你完全也可以選擇用PID表來(lái)驅(qū)動(dòng)這些回路， PLC系統(tǒng)中只做數(shù)據(jù)顯示和參數(shù)給定， 還少了很多的計(jì)算資源， 算下來(lái)成本反而可能比用高性能的CPU還低。

如果你認(rèn)為對(duì)算法越精的工程師水平越高， 那么這些工程師應(yīng)該只在PID表的工廠里，專心研發(fā)這些表的控制工藝和參數(shù)，就足以拿行業(yè)最高薪資了。 都沒(méi)必要親自來(lái)做項(xiàng)目，靠著辛辛苦苦調(diào)試每一個(gè)項(xiàng)目來(lái)掙錢。

與PID算法類似的還有糾偏，飛剪，卷取等等工藝，凡是這些復(fù)雜計(jì)算工藝的應(yīng)用，都會(huì)有廠家打包生產(chǎn)專門的模塊或者設(shè)備或者算法庫(kù)，幫助對(duì)算法不熟練的工程師實(shí)現(xiàn)這些功能，而他們賺取利潤(rùn)。 因?yàn)橐呀?jīng)封裝作為產(chǎn)品出售， 賺取的是規(guī)模效益，所以單價(jià)也不會(huì)高到離譜。

所以，如果你掌握了一點(diǎn)三腳貓的算法，或者準(zhǔn)確說(shuō)是行業(yè)應(yīng)用經(jīng)驗(yàn)， 那也僅僅是掌握了一門得以糊口的技能而已。 護(hù)城河沒(méi)多高，日常的辛苦工作仍然少不了。

人人都感慨工控行業(yè)的門檻低，哪怕學(xué)歷不高，只要腦子靈活，勤學(xué)好問(wèn)，肯動(dòng)手，也很快能入門。 只要入得們來(lái)，稍微有些資歷，工資就可以過(guò)萬(wàn)，這些人可以認(rèn)為是不懂什么算法。 而這個(gè)行業(yè)中，能見(jiàn)到的頂尖的工程師，大概也就3萬(wàn)也就封頂了。

所以，相比于沒(méi)有任何算法技能的一萬(wàn)元，三萬(wàn)元中所需要的算法技能也不會(huì)太多。 所以那些入門后以為通過(guò)再多掌握些算法，然后有可能獲得高薪的，恐怕要失望了。

所以，我的觀點(diǎn)是，所謂的算法， 在工控工程師中并不值什么錢。

還有一個(gè)佐證的例子。

有一位網(wǎng)友，搞農(nóng)業(yè)溫室的控制，疫情期間，一方面有些空閑，一方面項(xiàng)目中需要用到空氣焓濕圖的應(yīng)用，然后他就自己把大學(xué)期間學(xué)的高等數(shù)學(xué)微分方程等技能再拾起來(lái)，把焓濕圖的物理方程給計(jì)算解開(kāi)了。




解開(kāi)之后成為普通的計(jì)算方程，就可以直接在CPU中進(jìn)行計(jì)算，可以自由換算焓值、含濕量、露點(diǎn)溫度等工程中需要用到的關(guān)鍵物理值了。

聽(tīng)說(shuō)我有做過(guò)暖通空調(diào)方面的項(xiàng)目，就跟我聯(lián)系探討這個(gè)計(jì)算方法商業(yè)應(yīng)用的可行性。 并問(wèn)我是否有興趣， 如果有興趣可以直接給我一個(gè)函數(shù)塊試試看。

巧了，我在幾年前的項(xiàng)目中確實(shí)遇到過(guò)這個(gè)問(wèn)題。 然而我對(duì)空氣熱能方面的專業(yè)不懂，遇到這個(gè)需求的時(shí)候，先是從網(wǎng)上查了個(gè)簡(jiǎn)易近似方程，做了個(gè)函數(shù)，做在項(xiàng)目里面交工了。

但后來(lái)設(shè)備廠客戶反應(yīng)，我做的函數(shù)，有一些個(gè)別工況下計(jì)算出來(lái)的數(shù)值不準(zhǔn)。 然而我因?yàn)椴欢�原理，所以也沒(méi)辦法審核求證。

然后一怒之下，直接把客戶使用校對(duì)的那個(gè)數(shù)值表格要來(lái)，花了幾天之間整理數(shù)據(jù)，給錄入到PLC中了。 然后使用雙線性插值方法，做了個(gè)查詢函數(shù)。


我讀碩士期間做過(guò)有限元計(jì)算方面的項(xiàng)目，所以工作以后雖然數(shù)學(xué)和物理方面的計(jì)算能力丟掉了，這點(diǎn)小數(shù)值計(jì)算還是輕車熟路的。 做好了以后替換了原來(lái)做的函數(shù)，交過(guò)去，再查，都正確了。

可不嘛， 我們查的是同一個(gè)表，當(dāng)然可以保證正確了。

所以這位朋友再來(lái)問(wèn)我的時(shí)候，我就確實(shí)不太有改動(dòng)的意向了。因?yàn)閷?duì)我來(lái)說(shuō)沒(méi)什么明顯的收益了。

然后我們又探討了很多回， 如何把這個(gè)成果商用。他有過(guò)想法做成標(biāo)準(zhǔn)庫(kù)，提供給那些PLC廠家，集成在系統(tǒng)中， 每賣出一臺(tái)PLC，哪怕只給一元的專利費(fèi)即可。那自己也發(fā)大財(cái)了。

然而我們又認(rèn)識(shí)到可行性不高，而且不太容易實(shí)現(xiàn)技術(shù)方法的保密保護(hù)。所以還是建議他用單片機(jī)完全封裝做成單獨(dú)的產(chǎn)品，面向市場(chǎng)銷售。

去年年底的時(shí)候，跟我聯(lián)系告知我， 產(chǎn)品已經(jīng)做出來(lái)了。 前幾天更是告訴我，已經(jīng)批量生產(chǎn)，開(kāi)始供貨了。市場(chǎng)反應(yīng)效果還不錯(cuò)。
也把使用說(shuō)明書發(fā)給我了。
《MSK系列溫濕度變送器使用說(shuō)明書V1.0》
我這里附個(gè)網(wǎng)盤里， 有感興趣的同行可以下載了解。有需要的可以直接聯(lián)系其公司購(gòu)買。

獲取方法后臺(tái)回復(fù)MSK，或者直接私信我。

我這里算是幫忙做個(gè)廣告。

回到本期討論的算法的話題。

前幾天， AD俱樂(lè)部深圳群里有個(gè)網(wǎng)友宣稱，所謂的PLC程序，根源算法就是個(gè)起保停。 再多的設(shè)備，無(wú)非是無(wú)數(shù)個(gè)起保停而已。

深以為然，感覺(jué)無(wú)法反駁。 我在去年寫過(guò)多篇文章，探討過(guò)起保停的話題。然而如果你認(rèn)為PLC程序里面只有起保停， 這在30-40年前， PLC剛剛誕生時(shí)，剛剛?cè)〈�繼電器邏輯的時(shí)候，是有道理的。 然而現(xiàn)在， 還這樣認(rèn)知，恐怕就有些落伍了。

讓我們?cè)倏匆谎畚医�期反�?fù)提及的LBP例程中的電機(jī)模塊的程序：



20多個(gè)段落，300多行程序，里面與起保停相關(guān)的只有一個(gè)段落，三五句程序。 而其余的大部分程序是在做數(shù)據(jù)整理，數(shù)據(jù)傳輸方面的工作。

起保停是算法不錯(cuò)，但你眼里如果還仍然只有這點(diǎn)三腳貓的算法， 那很顯然認(rèn)知上的差距很大了。

而如果你現(xiàn)在做項(xiàng)目還是在從起保停做起， 跟其他同行比起來(lái)，那效率也得是相當(dāng)?shù)土恕?

工資么，不說(shuō)了。

我現(xiàn)在的微信號(hào)：ZHO6371995

以前有我微信的看一看還對(duì)不對(duì)。

有道理。