此图片来源:Rother Machine
生产停滞让客户每小时损失10万美元,他们已经打电话给可编程逻辑控制器(PLC)程序员,以尽快解决问题。在查看最近的航班后,程序员启动了一个虚拟专用网络(VPN)。一个小时后,程序员看到了一个“全新”的程序(对他们来说是新的),数千行梯形图逻辑没有标记描述,命名规则不清晰,代码已经复制粘贴了上百次,而这一切都在一个庞大的例程中。这可能会导致该程序员弄不清楚,原来的编程人员究竟想做什么。
一般来说,PLC程序员倾向于用自己熟悉的方法编写代码以便立即解决当前的问题。人们很容易忽略未来必须维护这些代码的“可怜虫”。如果不注意CONTROL ENGINEERING China版权所有,屏幕前被骂的可能就是我们。以下四个建议可以帮助你避免成为抱怨对象。
01 不要复制和粘贴重复的逻辑
比方说,有两个线圈需要依次激活。一个用来打开第一个梯级,也许是一个定时器,然后是另一个梯级,用于开启下一个。除了将标签名称从“CoilOne”更改为“CoilTwo”之外,梯级内容都是相同的。我们都用使用这样的代码CONTROL ENGINEERING China版权所有,因为事情总是这样的,但那是只有几个梯级的情况。但如果你有50个线圈,看看会发生什么事情?在你开始敲击Ctrl+V之前,可以先仔细思考一下。
寻找重用代码的机会。回路是个好帮手。AOI、子例程,甚至是基本数组都可以加快开发时间,使代码更简洁,并让未来的维护更容易。如果遇到逻辑变更?您不必粘贴50个修复程序,只需对子例程进行更改,一个小时既可完成。客户想把 50 个线圈改成 100 个?如果做得对,您通常只需将 "Coil_Count "或其他类似的标签从 50 改为 100 即可。
02 切忌使用难以辨认的标签名称,且不加任何标注
“tmrdelay”–“Timer”和“delay”是多余的。该延时的功能是什么?是用它来点灯,还是等待一段安全时间后再放下重压机?
很显然,“AB_XGI:I.Data[1]”是一个用于某些连接设备的数据结构,但在主例程中如果这样引用控制工程网版权所有,代码就不清晰。“fireRobotMove”,这是指哪个机器人?哪一个动作?我需要灭火器吗?这些标签名称本身并不是无用的,但如果没有情境信息,它们就没有多大意义。
应当使用描述性标签名称。名称应该说明标签的用途。此外,还应注意格式。即使是“tmrDelay”或“tmr_delay”也许会更好。没有人需要去猜测如何分割这个词。
在标签和梯级中添加说明。一个简单的缓冲区例程或别名CONTROL ENGINEERING China版权所有,可以将“AB_XGI:I.Data[1]”转换为更有用的东西,如“partX-Pos”。“tmrdelay”可以变成“tmrDriverReady”。更好的做法,是在标签或横档上添加描述,解释它的用途。
应当使用合适的拼写。有没有试过搜索所有处理位置数据的标签,看看其中是否有一个名为“poision”的标签?
03 不要忽略程序结构
没有人愿意看到一个名为“Main”的例程有200个梯级,它涵盖了从输入/输出(I/O)到工艺流程的所有内容。
使用例程和用户自定义的数据类型(UDT)(或“结构”,具体取决于制造商)来保持代码组织有序。只需将代码分解为几个名为“Camera”、“InputBuffer”和“Faults”的例程,就会使代码更具可读性。不需要筛选50级不相关的逻辑——如果你需要Camera逻辑,请直接搜索Camera例程。
UDT非常有用。它们允许您对数据进行分组和命名,即使是在数组中也是如此。例如,如果你的视觉系统返回了很多位置数据,你可以创建一个带有“X”、“Y”和“Z”标签的“位置”UDT,来保持代码组织有序。带子标签的“point1”远远优于“point1X”、“point1Y”和“point1Z”。更容易重命名、交叉引用和填充到数组中,并进行迭代。
“通过使用数据结构、一致的命名规则和描述性注释,可以为PLC编可维护且灵活的代码。”
04 不要过于乐观
“这个项目只需要几个月的时间。客户确切地知道他们想要什么。除了我,没有人会看到这个”。或最容易出现的想法:“我会记得为什么这么做。”
▲图:通常,PLC 编程人员都倾向于为自己编写代码以获得即时解决方案,但这可能会带来长期问题。
记住墨菲定律:“任何可能出错的事情都会出错。”这一点实际上是为了强调所有其它事情的必要性。积极的态度很少是坏事,但如果没有任何问题,我们可能就没有工作了。可扩展、可读和可维护的代码是墨菲定律的致命对头。
为迎接未知的未来,我们能做的最好的事情就是注意上述PLC编程该做的事情。通过使用数据结构、一致的命名规则和描述性注释,有助于编写易于维护和灵活的代码。这样,未来每个人都可以更轻松读懂程序。
当您的客户需要添加新的按钮时,他们会向您表示感谢。你的同事会感谢你有一个易于遵循的结构。但根据我的经验,受益最多的人可能是你自己。因为说实话,当我抱怨代码时,发现50%都是我自己编写的代码。
不要只是能运行就好。花点时间把事情做好。现在越聪明地工作,以后的维护就更轻松。(作者 | Jon Breen)
关键概念:
■ PLC程序员倾向于编写代码解决眼前问题,而不是制定长期解决方案CONTROL ENGINEERING China版权所有,这对那些后来介入工作的人来说可能是个灾难。
■ PLC编程要避免的一些事情,包括复制/粘贴重复的逻辑和使用不带标签的无法识别的标签名称等。
思考一下:
您是否允许或禁止未来的PLC编程人员处理您的代码?