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

没啥。