[汇川] 1030 【万泉河】LAD是不是被SCL/ST全面碾压了?

[复制链接]
查看9022 | 回复0 | 2024-11-13 22:33:50 | 显示全部楼层 |阅读模式
1030 【万泉河】LAD是不是被SCL/ST全面碾压了?

LAD即梯形图。

SCL和ST即IEC 61131规定的结构化文本编程语言,在西门子中称为SCL,而在其他品牌,CODESYS, 三菱,OMRON等称之为ST。

前段时间, 有一个加入了烟台方法学习的学员,在看了几天分享给他的标准化架构的程序资料之后,给我提了这样的问题。

而其实我自己还真没仔细想过。

被他这么疑问, 想了一下, 好像确实有这么个趋势。所以,用语音给他讲解了一下。今天再把这个道理文字形式阐述发表出来。与大家探讨。

我们在做程序的时候要讲究高内聚低耦合。即内聚的环节难度高, 耦合的环节难度要相对低。

然而不管两者之间具体做到了多高和多低, 首先一点, 要做到内聚和耦合严格分开,即程序中一眼望去,可以非常清楚地分出来。

对于烟台方法来说,其实更重要的贡献是实现了这一点。所有学员拿到烟台方法的资料程序, 最被惊艳到,也是第一次开眼见到的就是内聚和耦合的严格分开,且耦合部分的难度低到了令人发指之低。

低到了有很多人产生了幻觉,以为我不如他会写程序。以为我不会做循环语法。仍然有这种认知的同行建议去了解下GML ,MODBUS优雅库。看看自己能不能做到一样的优雅。



附图是烟台方法移植到三菱之后的程序, 手动部分和自动部分,加起来是整个的耦合部分, 全部都是程序块(FB)的调用和挂实参。没有任何逻辑。

而耦合部分则全部在程序块的文件夹中, 那里面定义了程序中所有需要用到的功能块和库函数。然而没有使用全局变量, 也没有访问任何外部IO变量,所以程序块可以跨项目自由拷贝,而绝不会变量冲突,也当然不需要进行任何检查修改。

那么, 回答这个学员的问题,分为两部分:

1,内聚部分,如果答案:是。

2,耦合部分,如果答案:是。

则1+2加起来,答案就是:是的。

1,内聚。

读过我较多文章的读者都知道,我第一版的烟台方法的程序, 是在S7-1500中实现的, 库函数大量借用了西门子的BST库函数。然后在其基础上,又自己开发了工艺函数。

而不管是BST库函数, 还是我近来一直在大力宣传介绍的BPL/LBP, 他们的库函数原本都是用SCL语言写成的。那么我在移植到其他的PLC平台之后,也只不过将SCL的语法适应到了ST。

而我自己为行业和项目开发的库函数,就有些混杂了。大部分是随性而为。看具体的功能需求,在陈述性语句比较多,以及有循环和条件判断的时候就顺手用SCL。而如果是顺序控制等需要比较多调试的时候,就尽量还是多用LAD。因为对于在线调试来说,我认为LAD还是强于SCL的。

但当我从西门子移植到CODESYS ,三菱, OMRON , B&R等的时候, LAD就逐渐掉队了。

我表述过我的观点,即,如果可以电脑两个屏幕平铺,同时打开两个PLC平台的LAD编辑器,可以照着一套的LAD程序, 不需要动脑,简单在后一套中画出其LAD程序,我们也认为这可以符合移植条件。

然而,在实际操作中,还是有一些狗血的。主要是,西门子的LAD语法比其他品牌要复杂得多。原本在西门子LAD中随性画出来的梯形图,到了倍福或者三菱中,好多画法不支持。在西门子中的一个NETWORK,到对方有时候需要分割到多个网络中才可以。甚至有时候还需要添加内部变量来承接。

这当然不是难度方面的障碍。其实主要还是我有些懒,也是因为没有被逼到份上。真要给我个设备需求让我实打实上电调试实现,我花个个把小时完成他们,也就OK了。

当然,也还有一个问题,是我对好些品牌的LAD的操作不熟悉,指令用法不习惯。画起来别扭得很。

所以,在移植的时候, 有的程序块我甚至左边是LAD,右边我硬生生按ST给抄下来了。我也有文章写过两者之间的转换方法。

然后,最终的三菱中的程序,就大部分是ST了, 而LAD就很少了。也有三菱标准化的学员来问我:万老师, 为啥我发现有的FB,你只定义了接口,而实际程序逻辑全是空的呢?

我就赶紧道歉,不好意思, 是因为我懒惰了,抄LAD的时候懒得抄了。不过这里的逻辑本身不是学习烟台方法的重点,对每个已经入门的工程师,简单的很。所以就没做。

所以可以看到,在整个内聚部分, 不管是抄袭来的程序还是移植来的程序,都还是ST的实现比较简单,也逐渐越来越多,LAD被挤压到越来越少了。

当然, 如果我新调试一个系统功能块,在没有移植需求的情况下,我还是会尽量选择LAD, 被碾压了也选。

2,耦合 。

耦合就是程序的调用。

程序调用的特点在于难度低, 而重复的工作量大。大家有看过我80系列的例子, 不管是80工位还是80模拟量, 那种大工作量的重复程序,并没有什么语法,也自然不需要什么调试,那么即便教给一个新手来帮忙干具体的工作,需要教给他的编程知识都很少。

只需要在文本编辑中不断的照猫画虎就可以了。

所以,其实我们主要是在Excel中写耦合程序。如文章《0628 【万泉河】优雅的PLC程序一定是用EXCEL写出来的》中所述。

因为选择了SCL,所以可以用EXCEL拖一下直接生成。而如果选择LAD,则需要用OPENNESS配合EXCEL编程实现。

后者需要的技能比较高,看起来可能会令人觉得比较眼花缭乱, 心生敬畏。

然而代价是,只有做编程的工程师自己能做。其他人很难上手,也更难于标准化。

而我们的目标是能尽量地把自己解放,而不是把自己一辈子套牢。

所以,宁肯选一个低难度的EXCEL解决方案, 也不去学OPENNESS的花拳绣腿。

在做80系列例子的时候, 有一些厂家平台如汇川的H5U,只支持LAD, 而不支持文本语言, 甚至导入导出到文本的功能都没有。那么我也只好老老实实用LAD来逐个画出来。画的过程中摸索能更高效实现的技巧。

然而最近听说的是,汇川的新版的AUTOSHOP编程软件,已经支持ST了。

我当然很欣慰。

1+2

综上所述,确实, LAD被SCL/ST全面碾压了。

这是个客观问题客观答案, 不包含主观倾向。

那么如果只会LAD的工程师,看到LAD如此被碾压,应该怎么做?当然是可以开始学习SCL编程了。

其实这反而是个好消息,说明发现了提高技能的方向。而网上有大量资料,让你学这个品牌那个品牌产品的应用知识,那些只能算是简单累加,并算不上什么技能的提升。对技能和身价的提高,并不会有什么显著的价值。

然后,如果有人坚持说,我这辈子不打算再学语言了,就打算LAD干到底了。是不是烟台方法的架构就学不了,不能实现了呢?

根本没有多大关系。那些底层的库函数,我愿意抄和借用现成的库,也还是出于我想省些力气的原因。我辅导的工程师,有的人就把BST函数直接扔掉了,自己用LAD重新写了替换掉,当然主要目的是简化功能,讨厌其中没用的复杂功能。我自己也一直在筹划找机会重新做一套模块,把它们替换掉。

而SMART 200等的标准化程序,我也是全盘用LAD写的。因为,没得小抄可以抄。

而信捷等小型PLC,只支持LAD语言,我不也照样写文章宣布可以做标准化的嘛!真的把LAD玩得溜了,都一样可以实现。只不过鼠标和手指关节累一点。

没啥。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?注册哦

x
您需要登录后才可以回帖 登录 | 注册哦

本版积分规则