发表于:2020/7/15 16:35:41
#0楼
最近好像没什么新鲜事,分享一下前几天看到的一篇文章吧
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夹杂的。仅仅是因为便利而已。
绝不是炫技。

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夹杂的。仅仅是因为便利而已。
绝不是炫技。
[此贴子已经被作者于2020/7/16 11:16:10编辑过]
温馨提示:
电话:0755-26546361
邮箱:blog@gkong.com
微信公众号:工控论坛;微信号gkongbbs;
不定期修改账号密码;不要在多个网站用同一账号密码
可随时站内信联系,工作日可拨打电话或发邮件咨询相关问题
电话:0755-26546361
邮箱:blog@gkong.com
微信公众号:工控论坛;微信号gkongbbs;
不定期修改账号密码;不要在多个网站用同一账号密码
可随时站内信联系,工作日可拨打电话或发邮件咨询相关问题