发表于：2023/2/14 8:19:20
#0楼
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应用工程师， 从个人声誉的角度要争什么行业大佬资格， 从而互相碾压攻击，你们如果有那样的理想， 不如多做些基础的研究工作，提出更高的问题，为行业集体发出一些呼吁的声音，最终才能促进行业的发展。 想争第一的名份的， 先看看自己手里有多少翻车的教训，有提出过多少新的理论方法贡献给行业。
我一个人的声音显然太微弱了些。
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应用工程师， 从个人声誉的角度要争什么行业大佬资格， 从而互相碾压攻击，你们如果有那样的理想， 不如多做些基础的研究工作，提出更高的问题，为行业集体发出一些呼吁的声音，最终才能促进行业的发展。 想争第一的名份的， 先看看自己手里有多少翻车的教训，有提出过多少新的理论方法贡献给行业。
我一个人的声音显然太微弱了些。
PLC标准化编程
