我猜，有一些同行对PLC控制系统中的算法的认知，可能有一些谬误。 可能是他们在入门学习时候，经受了一些不靠谱的培训课程的误导，告诉他们算法为王，算法为王。严重夸大了算法在整个控制系统中的重要性。

比如， 我发的80模拟量标准答案的文章，就有读者在后面短短几十个字内，把算法和循环逻辑回复给我了，告诉我那是他的更优答案。

（* 工程量：=模拟量/27648*量程 *）用数组，800个模拟量也就一个for搞定。
         
FOR #ii := 1 TO 80 BY 1 DO g_rActSensorH[#ii]:=rSensorAnalogH[#ii]/27648.0 * rSetSensorRangeH[#ii];

以及那个扔了一个FC给我的家伙。

眼里面的控制任务就只有算法了，真以为算法为王， 掌握了算法就拥有了一切，就掌握了世界。

乃至于我跟那位抛答案的又回复: 就假设我们收到的80个模拟量全都直接就是浮点数的物理量，不需要你转换了。 你只做录入吧！把80个数据录入到程序中，我要的是这个程序。

80模拟量的程序，主要的目的是为了完成80个数据的信息录入， 转换工作只是其中小到忽略不计的工作量。 甚至，因为这点算法太简单， 我们通常还要顺便再加点算法，搞几个上下限的阈值， 做限制值判断，以供报警显示和程序自动逻辑用到。

这幸亏还是模拟量， 不是开关量。 如果是80个开关量信号的处理， 那更扯，更是没有算法可玩。 我们在标准化烟台方法中，对一些独立于L1设备之外的单个开关量输入信号，都又强迫给加了滤波，并默认关掉不用的。 然而等个别信号需要防抖动的时候才设置个滤波时间再打开。

我都有点后悔标准答案不应该拿模拟量做，而应该拿DI输入信号做举例了。会少掉很多误会。

而那位搞一个线性变换的FC就得意洋洋发给我秀算法的家伙，在拉黑我之后不知道啥时候又加回来，发消息要我给他做个PID的算法，我就直接没再搭理他了。

PID还需要算法吗？好多PLC控制系统里面都有现成的算法了。 比如SMART200中有向导， S7-1500里面有工艺对象，甚至都给PID设置了自动优化的功能。 你不需要懂任何算法，调试中设置跑一下优化过程， 系统的PID参数自动就得到了。

除此之外， 业界还有不下几百家专门的PID仪表的厂家，你完全也可以选择用PID表来驱动这些回路， PLC系统中只做数据显示和参数给定， 还少了很多的计算资源， 算下来成本反而可能比用高性能的CPU还低。

如果你认为对算法越精的工程师水平越高， 那么这些工程师应该只在PID表的工厂里，专心研发这些表的控制工艺和参数，就足以拿行业最高薪资了。 都没必要亲自来做项目，靠着辛辛苦苦调试每一个项目来挣钱。

与PID算法类似的还有纠偏，飞剪，卷取等等工艺，凡是这些复杂计算工艺的应用，都会有厂家打包生产专门的模块或者设备或者算法库，帮助对算法不熟练的工程师实现这些功能，而他们赚取利润。 因为已经封装作为产品出售， 赚取的是规模效益，所以单价也不会高到离谱。

所以，如果你掌握了一点三脚猫的算法，或者准确说是行业应用经验， 那也仅仅是掌握了一门得以糊口的技能而已。 护城河没多高，日常的辛苦工作仍然少不了。

人人都感慨工控行业的门槛低，哪怕学历不高，只要脑子灵活，勤学好问，肯动手，也很快能入门。 只要入得们来，稍微有些资历，工资就可以过万，这些人可以认为是不懂什么算法。 而这个行业中，能见到的顶尖的工程师，大概也就3万也就封顶了。

所以，相比于没有任何算法技能的一万元，三万元中所需要的算法技能也不会太多。 所以那些入门后以为通过再多掌握些算法，然后有可能获得高薪的，恐怕要失望了。

所以，我的观点是，所谓的算法， 在工控工程师中并不值什么钱。

还有一个佐证的例子。

有一位网友，搞农业温室的控制，疫情期间，一方面有些空闲，一方面项目中需要用到空气焓湿图的应用，然后他就自己把大学期间学的高等数学微分方程等技能再拾起来，把焓湿图的物理方程给计算解开了。

解开之后成为普通的计算方程，就可以直接在CPU中进行计算，可以自由换算焓值、含湿量、露点温度等工程中需要用到的关键物理值了。

听说我有做过暖通空调方面的项目，就跟我联系探讨这个计算方法商业应用的可行性。 并问我是否有兴趣， 如果有兴趣可以直接给我一个函数块试试看。

巧了，我在几年前的项目中确实遇到过这个问题。 然而我对空气热能方面的专业不懂，遇到这个需求的时候，先是从网上查了个简易近似方程，做了个函数，做在项目里面交工了。

但后来设备厂客户反应，我做的函数，有一些个别工况下计算出来的数值不准。 然而我因为不懂原理，所以也没办法审核求证。

然后一怒之下，直接把客户使用校对的那个数值表格要来，花了几天之间整理数据，给录入到PLC中了。 然后使用双线性插值方法，做了个查询函数。

我读硕士期间做过有限元计算方面的项目，所以工作以后虽然数学和物理方面的计算能力丢掉了，这点小数值计算还是轻车熟路的。 做好了以后替换了原来做的函数，交过去，再查，都正确了。

可不嘛， 我们查的是同一个表，当然可以保证正确了。

所以这位朋友再来问我的时候，我就确实不太有改动的意向了。因为对我来说没什么明显的收益了。

然后我们又探讨了很多回， 如何把这个成果商用。他有过想法做成标准库，提供给那些PLC厂家，集成在系统中， 每卖出一台PLC，哪怕只给一元的专利费即可。那自己也发大财了。

然而我们又认识到可行性不高，而且不太容易实现技术方法的保密保护。所以还是建议他用单片机完全封装做成单独的产品，面向市场销售。

去年年底的时候，跟我联系告知我， 产品已经做出来了。 前几天更是告诉我，已经批量生产，开始供货了。市场反应效果还不错。

也把使用说明书发给我了。

《MSK系列温湿度变送器使用说明书V1.0》

我这里附个网盘里， 有感兴趣的同行可以下载了解。有需要的可以直接联系其公司购买。

获取方法后台回复MSK，或者直接私信我。

我这里算是帮忙做个广告。

回到本期讨论的算法的话题。

前几天， AD俱乐部深圳群里有个网友宣称，所谓的PLC程序，根源算法就是个起保停。 再多的设备，无非是无数个起保停而已。

深以为然，感觉无法反驳。 我在去年写过多篇文章，探讨过起保停的话题。然而如果你认为PLC程序里面只有起保停， 这在30-40年前， PLC刚刚诞生时，刚刚取代继电器逻辑的时候，是有道理的。 然而现在， 还这样认知，恐怕就有些落伍了。

让我们再看一眼我近期反复提及的LBP例程中的电机模块的程序：

20多个段落，300多行程序，里面与起保停相关的只有一个段落，三五句程序。 而其余的大部分程序是在做数据整理，数据传输方面的工作。

起保停是算法不错，但你眼里如果还仍然只有这点三脚猫的算法， 那很显然认知上的差距很大了。

而如果你现在做项目还是在从起保停做起， 跟其他同行比起来，那效率也得是相当低了。