千万别这样干了——PLC编程四大陋习

文章发布于：2023-10-13 08:32:02

此图片来源：Rother Machine

作者 | Jon Breen

有时为了解决眼前问题，可能需要对可编程逻辑控制器（PLC）进行编程，但从长期来讲这可能会带来问题，在原程序员不在的情况下更是如此。

生产停滞让客户每小时损失10万美元，他们已经打电话给可编程逻辑控制器（PLC）程序员，以尽快解决问题。在查看最近的航班后，程序员启动了一个虚拟专用网络（VPN）。一个小时后，程序员看到了一个“全新”的程序（对他们来说是新的），数千行梯形图逻辑没有标记描述，命名规则不清晰，代码已经复制粘贴了上百次，而这一切都在一个庞大的例程中。这可能会导致该程序员弄不清楚，原来的编程人员究竟想做什么。

一般来说，PLC程序员倾向于用自己熟悉的方法编写代码以便立即解决当前的问题。人们很容易忽略未来必须维护这些代码的“可怜虫”。如果不注意，屏幕前被骂的可能就是我们。以下四个建议可以帮助你避免成为抱怨对象。

不要复制和粘贴重复的逻辑

比方说，有两个线圈需要依次激活。一个用来打开第一个梯级，也许是一个定时器，然后是另一个梯级，用于开启下一个。除了将标签名称从“CoilOne”更改为“CoilTwo”之外，梯级内容都是相同的。我们都用使用这样的代码，因为事情总是这样的，但那是只有几个梯级的情况。但如果你有50个线圈，看看会发生什么事情？在你开始敲击Ctrl+V之前，可以先仔细思考一下。

寻找重用代码的机会。回路是个好帮手。AOI、子例程，甚至是基本数组都可以加快开发时间，使代码更简洁，并让未来的维护更容易。如果遇到逻辑变更？您不必粘贴50个修复程序，只需对子例程进行更改，一个小时既可完成。客户想把 50 个线圈改成 100 个？如果做得对，您通常只需将 "Coil_Count "或其他类似的标签从 50 改为 100 即可。

切忌使用难以辨认的标签名称，

且不加任何标注

“tmrdelay”–“Timer”和“delay”是多余的。该延时的功能是什么？是用它来点灯，还是等待一段安全时间后再放下重压机？

很显然，“AB_XGI:I.Data[1]”是一个用于某些连接设备的数据结构，但在主例程中如果这样引用，代码就不清晰。“fireRobotMove”，这是指哪个机器人？哪一个动作？我需要灭火器吗？这些标签名称本身并不是无用的，但如果没有情境信息，它们就没有多大意义。

应当使用描述性标签名称。名称应该说明标签的用途。此外，还应注意格式。即使是“tmrDelay”或“tmr_delay”也许会更好。没有人需要去猜测如何分割这个词。

在标签和梯级中添加说明。一个简单的缓冲区例程或别名，可以将“AB_XGI:I.Data[1]”转换为更有用的东西，如“partX-Pos”。“tmrdelay”可以变成“tmrDriverReady”。更好的做法，是在标签或横档上添加描述，解释它的用途。

应当使用合适的拼写。有没有试过搜索所有处理位置数据的标签，看看其中是否有一个名为“poision”的标签？

不要忽略程序结构

没有人愿意看到一个名为“Main”的例程有200个梯级，它涵盖了从输入/输出（I/O）到工艺流程的所有内容。

使用例程和用户自定义的数据类型（UDT）（或“结构”，具体取决于制造商）来保持代码组织有序。只需将代码分解为几个名为“Camera”、“InputBuffer”和“Faults”的例程，就会使代码更具可读性。不需要筛选50级不相关的逻辑——如果你需要Camera逻辑，请直接搜索Camera例程。

UDT非常有用。它们允许您对数据进行分组和命名，即使是在数组中也是如此。例如，如果你的视觉系统返回了很多位置数据，你可以创建一个带有“X”、“Y”和“Z”标签的“位置”UDT，来保持代码组织有序。带子标签的“point1”远远优于“point1X”、“point1Y”和“point1Z”。更容易重命名、交叉引用和填充到数组中，并进行迭代。

“通过使用数据结构、一致的命名规则和描述性注释，可以为PLC编可维护且灵活的代码。”

不要过于乐观

“这个项目只需要几个月的时间。客户确切地知道他们想要什么。除了我，没有人会看到这个”。或最容易出现的想法：“我会记得为什么这么做。”