大家最近都在关注些什么新鲜事？

最近好像没什么新鲜事，分享一下前几天看到的一篇文章吧


PLC编程语言LAD和SCL如何选？
https://mp.weixin.qq.com/s/WtF9t1ZgieoAC9-VDubQ1w
作者：万泉河

我来捅一下马蜂窝。

关于LAD和SCL（以前是STL 语句表）的选择，是个比较敏感的话题。论坛里争论过很多次了，每次讨论都很不愉快，气氛会逐渐升级，甚至到最后，持有相反观点的两方，几乎到互相敌视的程度。

我来描述一下这里面的两方阵营的主要观点

1，  电工出身，只看得懂LAD，编程语言没学过， SCL看不懂。 所以编程只用LAD。
或者SCL能勉强看懂，但费劲。所以偏向于用LAD，不到万不得已，不去碰SCL。

2，  大学计算机专业， 编程语言学过，但没学过电工电子学， 电路图看不懂，高级语言看得舒服。所以编程只用指令，STL或SCL。
或者LAD后来逐渐能看懂了，但仍然不习惯用。思维方式还在语句指令，别人写的LAD可以勉强看看，但只要自己写的块和程序，只要有可能，还是用SCL。

这个话题的每次争论中，我基本上都是围观的角色。很少站队一方发表倾向性的意见。所以总有人来问我，想要我发表些看法。

上个月，微信群里，就又有人问起，说拿到前同事写的程序，里面LAD和SCL夹杂着写，一会儿用LAD，一会儿用SCL，问是为什么？

然后，就有一位群友回答说，大概是炫技吧！炫耀自己的技能，变着花样的炫弄。

我差点笑出声来了。

哪里有什么炫技！人家编自己的程序，实现自己要的控制目的，关他人何事。 能最高效的方法实现目的，才是人家想要的。 程序做好，调试好， 下载到系统里，不管什么语言， 能达到目的就行。 CPU又不是人，不会挑食对语言挑挑拣拣发表意见的。

我甚至都不需要看到所说的程序的样子，都大概可以猜出来。

关于编程中使用什么编程语言，我的观点是，选择最方便实现需要的控制目的的那个。

注意，这里面，是一个客观描述。没有我个人的主观偏好在里面。

准确一点说，当我们要实现一个控制目的的时候，先客观分析一下，当下可用的各种语言工具，SCL , LAD, GRAPH, CFC，。。。。综合比较它们的各自优缺点，在实现当下的任务时，哪些方面有利，哪些方面有弊。综合利弊，认定一个更优的。

然后下一步是主观选择。结合自己自身情况，比方说我明知道这个逻辑用GRAPH做起来会比较顺手，但我自己时间久了没用，用的很少，手生，还或者同事以及客户的工程师，复杂的程序给他们看不了，都还比较熟悉LAD，所以就选择LAD了。

所以，即便实际选择的是一个方案，但自己认知上需要清楚地明白，当下的任务其实用啥样的方法实现，更优秀。如果别人读到，提及的时候，要能认可。要能点头称是。

是是是！

我明知道用XXX语言做出来更好更优秀更方便，也有老师指导建议我用那个，但我当时的技能有欠缺，任务又紧急，就不得不临时先实现了。

而不是作狡辩：只要设备能运行功能完好的程序，就是好程序。每个人习惯不同，编程方法不同，我做的自然是最好的程序！

这样的，都是杠精。都不是好的学习者。

真正的学习者，每次项目做完， 都能从中总结出经验， 利弊得失，这一次项目虽是完工了， 不大有机会大改了，但自己知道自己哪里没做到最好。

可以积累经验，积蓄资源， 下一次有机会的时候， 用更好的方法实现。 甚至，即便没有新项目，也可以自己在纸面上把前面的旧项目重新以更好的方法做一遍，即便不能实际应用，也权当练练手了，提高下技能，总是可以的吧。

我来举几个实际的例子，客观比较使用SCL和LAD的利弊。

比方说对一个FB的调用，

如果用LAD, 是这样子：


而如果用SCL, 一上来这样：


如果你对一个FB还不够熟悉，你用LAD调用的时候，可以一眼看到所有的管脚，然后可以逐个比较，猜测，给每个管脚挂上合适的IO。

而如果用SCL，则需要对这个FB非常熟悉，需要自己码字， 输入需要的每个管脚以及绑定的变量。 如果不够熟悉， 那一上来肯定是懵逼的，根本不知道如何输入。 诚然，现在的PORTAL软件对SCL也做了很好的UI处理，可以弹出选择框提醒选择管脚， 也可以直接放开显示所有管脚任你输入：


我相信，在不熟悉的情况下，即便程序员出身，一打眼看到这一堆，也头麻。而且，输入的过程中还经常违背语法，经常出错。

所以，第一回合， LAD胜。

然后，在FB被多次调用的情况下， LAD很容易理解，就一个NW调用一次框图，替换填入正确的变量。但输入的过程需要不断用鼠标选择，键盘输入。或者好一点的情况下，可以查找替换关键字来实现。但一次只能替换一个NW。如果FB调用到100次的时候，工作量还是相当大的。最终程序占用的篇幅也比较大，都不方便截图了。

而如果先仔细研究好一个FB的调用语法，用SCL实现调用，是这样子的：


很显然，这是使用文本编辑器事先批量编辑好的。

而实际上，我以前文章也介绍过，我们在标准化编程方法中，这些都是通过EXCEL自动生成的脚本。设备的批量调用，几分钟就能完成。

所以， 我自己的项目中，即便是FB的调用，都不是统一格式的， 有时候是LAD， 有时候是SCL ，完全取决于我当时对便捷程度的判断。

而且还有另外一点，我前几天的感悟：
SCL的程序，可以轻松改为注释， 暂时不需要的代码，可以前面加上注释的符号，改为注释，继续保存在程序中。


而LAD程序，是没法改为注释的。


我一批LAD写成的程序，上一个项目中用过的功能，但当下这一个项目因为没有了，所以多出来了。我实在是舍不得删掉他们，因为再以后的项目还随时需要用到。但因为这是LAD编的，我如果留着它们，这里不存在的变量都是红色的，编译就会出错，所以只好忍痛割爱只好删掉了。

所以这一回合， LAD败。

最后再举例一个比较复杂的与或逻辑的梯形图：


在监视运行状态时，假设能流如绿色线绘出的，所有人， 1S内就可以看清楚。而这段程序的语句方法表达，我还没想清楚有多复杂。至于监控和诊断，更是复杂到家了。

谁如果和我说，他更习惯语言，而不习惯看电路图，那我建议， 回到你的初中把初二物理重新再学一遍吧！

毫无疑问，这一回合，LAD胜。

话说到这里，有可能原本激烈对峙的双方，会争先恐后来跟我求和，老万你误解我意思了，我观点和你一样！咱们没有分歧！

抱歉，你们在话语中表达出来的，给别人的感觉就是那样子的。甚至， 两方阵营的大佬， 咱们也都是非常熟悉的朋友， 我知道你们之间的争论，其实也只是朋友间的探讨，并没有上升到开火的程度，顶多是老大哥批评小弟表达方式有问题，会带歪很多初学者，给他们传递错误的信号。

我的建议是，以后表达这样的观点的时候，表达自己不熟悉的那一个侧面的时候，表现的谦卑一点，或者略微带一些自责，然后就不会引发别人的误解了。而不是一边说自己不懂的区域，一边还让别人感觉到理直气壮的样子，甚至自己不懂的知识都是自己不屑于去学习了解的，那就不太好了。

最后，我也不清楚是啥时候开始PORTAL的LAD建立的程序块中，竟然可以插入SCL和STL程序段：


这给我们的启示是，不管啥程序块， 在建立的时候，都可以先选择LAD。 然后在程序中，只要觉得需要，随时可以插入SCL。 如果需要，甚至可以全部都用SCL来写。 也毫无问题。

我在上一篇给标准化学习营的教材，演示的封装电机块的过程，其实也是LAD和SCL夹杂的。仅仅是因为便利而已。

绝不是炫技。