0208 【万泉河】终于被松下PLC打败

2月2日上周四，进行了LBP培训课程讲座的第一课，生成了课件，已经参加的学员如果在当堂没有听懂看懂，可以再参考课件内容，逐步自己实现。所以， 如果没有来得及报名而想要学习LBP的同行，也仍然随时可以报名参加。就不需要等开课时间了，直接一步到位收到课件，跟随课件学习。

         

总的来说，我做LBP的培训就是手把手带大家演练如何实现LBP的应用。做好了一次， 以后就永远有用。

         

那么一些入行还不够深， 现在还没有认识到自己有学习使用LBP的需求的，可以在将来，比如N年之后发现了自己达到了那个层级了，想要使用LBP框架，却发现自己掌握LBP有困难的时候，再来报名学习也不迟。

         

而我自己， 完成第一堂课之后到现在销声匿迹了将近一周时间，做啥去了？

         

做松下PLC的标准化去了。

         

松下FP-XH PLC的编程软件FPWIN PRO7，我以前研究过，只是确认了可行性，就没有继续再做。

         

所以，在培训课程的栏目里， 要求的是先学习OMRON或者三菱的标准化， 然后自行研究升级到松下PLC实现。

         

然而我忽视了系统软件平台的性能，或者说没能参透松下软件开发者的脑回路，然后闹了乌龙，翻车了。

         

起因是这样， 有一个同行，数次跟我联系想学烟台方法， 然而对我提及的不管西门子还是欧姆龙，三菱都不感兴趣。因为他全都没有碰过。现在的公司只使用松下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应用工程师， 从个人声誉的角度要争什么行业大佬资格， 从而互相碾压攻击，你们如果有那样的理想， 不如多做些基础的研究工作，提出更高的问题，为行业集体发出一些呼吁的声音，最终才能促进行业的发展。想争第一的名份的， 先看看自己手里有多少翻车的教训，有提出过多少新的理论方法贡献给行业。

         

我一个人的声音显然太微弱了些。