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

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玩得溜了，都一样可以实现。只不过鼠标和手指关节累一点。

没啥。