台式电脑

怎么样在电脑上安装松下gr7(0208 【万泉河】终于被松下PLC打败)

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

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

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

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

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

做松下PLC的标准化去了。

松下FP-XHPLC的编程软件FPWINPRO7,我以前研究过,只是确认了可行性,就没有继续再做。

所以,在培训课程的栏目里,要求的是先学习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

怎么样在电脑上安装松下gr7(0208 【万泉河】终于被松下PLC打败)

3+3+4=10

等等等等。

原本,这种方法除了浪费一点程序空间,编译代码量增大之外,别的也无所谓。然而FP-XH的PLC,SUB的编号最大只到255,即最多只能有256个函数调用。

这就难倒我了。

标准化的基础是程序功能的模块化,通过把相同的功能封装成块,通过重复调用,减少了咱们人工的重复工作量。

比如,我现在比较在意的一个数据格式是设备时间参数格式都使用以S为单位的浮点数。这样在数据交互过程中就少一个数据类型和数据转换的过程。

所以,我通常开头第一步,是对原本定时器功能做一个封装,设定值和运行值都改为浮点数,然后程序块中所有需要用到定时器的地方,统一使用自己新封装的定时器。

有人一直对烟台方法不理解,以为我在推行强制编程标准。其实如果有的话,对定时器数据格式的统一,可以算作一项,可能也是仅有的一项了。但也只是对我自己和烟台方法学员的一种倡议。

这在平常的PLC系统,原本都没有问题的。然而到了松下,问题就出来了。

我这种对定时器的封装方法,如果对应到过去传统垃圾程序的写法,一套系统用到256个定时器会把定时器资源耗光的话,我这里就是一步到位同时把子程序资源也耗光了。得,我啥子程序都不用写了。还做什么模块化,标准化!

如果我现在真的要做这样的项目,那方法就是把所有的封装全部拆掉,比如定时器,所有程序中用到的地方,再不厌其烦地前面加入REAL到TIME的转换,后端需要监测运行值ET时再做TIME到REAL的转换,程序不做嵌套,所有FB块都一气呵成,大概也能做成标准化的架构。

那对我来说就太恶心了。

原本,松下PLC还有个旧一点的软件FPWINGR7,同一款PLC也仍然可以在那个平台上编程,那个平台是和我研究过的信捷XD一样,没有现成的FB/FC功能,所谓子程序全年都靠着跳转来实现的。我如果非要自己部署规划,和当时在信捷中实现的一样的方法,也能做好。

然而也会吃和信捷同样的亏。信捷XDPLC新版软件开始具备了FB/FC功能,我做的超前研究价值被清零了,而松下这里既然已经有了高版本的软件,如果我在低版本里面做,那么只要厂家随时把PRO7的软件做个升级,改变编译方法,比如到PRO8之后这个问题就解决了,那我就又白做了。

所以,思考一个晚上后,昨天早上还是跟对方工程师联系,退款给他了。

认败,才是更好更体面的退出方式。

由此我想到了历史上曾经的WINTEL联盟,微软和英特尔两家公司互相配合互相促进和提高,互相给对方提出更高的需求,而自己提供更高级的产品,最终促进了整个IT行业的飞速发展。

而在工控行业,需要有更多和我一样的PLC应用工程师,从应用角度,对PLC厂家软硬件平台提出更贴合应用实际的需求,他们改进提高之后,也可以促进提高我们的应用水平。

由此实现相得益彰的TIKTOK滴答。

所以,总有一些同样的PLC应用工程师,从个人声誉的角度要争什么行业大佬资格,从而互相碾压攻击,你们如果有那样的理想,不如多做些基础的研究工作,提出更高的问题,为行业集体发出一些呼吁的声音,最终才能促进行业的发展。想争第一的名份的,先看看自己手里有多少翻车的教训,有提出过多少新的理论方法贡献给行业。

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

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

相关新闻

返回顶部