用户中心

资讯 > 技术文章

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

来源:控制工程网2023.09.05阅读 2870


此图片来源:Rother Machine
  
  有时为了解决眼前问题,可能需要对可编程逻辑控制器(PLC)进行编程,但从长期来讲这可能会带来问题,在原程序员不在的情况下更是如此。
  生产停滞让客户每小时损失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编程人员处理您的代码?

版权声明:版权归控制工程网所有,转载请注明出处!

频道推荐

关于我们

控制工程网 & CONTROL ENGINEERING China 全球工业控制、自动化和仪器仪表领域的先锋媒体

CE全球

联系我们

商务及广告合作
任小姐(北京)                 夏小姐(上海)
电话:010-82053688      电话:18616877918
rendongxue@cechina.cn      xiashuxian@cechina.cn
新闻投稿:王小姐

关注我们的微信

关于我们 | 网站地图 | 联系我们
© 2003-2020    经营许可编号:京ICP证120335号
公安机关备案号:110102002318  服务热线:010-82053688