当我教授 PLC 时，很明显学生根据手头任务的不同而对编程语言有所偏好。例如：
-
对于模拟量操作，他们倾向于使用功能块图（FBD）。
-
梯形图（LD）则更受青睐用于通用性工作。
-
有些学生偏好结构化文本（ST），因为它具有类似 C 语言的风格，与我们之前完成的微控制器工作相似。
尽管存在这些自然偏好，关键不在于使用哪种语言，而在于如何使用该语言。我们可以认为，程序组织结构超越了关于“最佳”语言的大多数考量。这一普遍性陈述同样适用于 PLC、嵌入式微控制器及其所有相关语言。我们不要忘记，PLC 的独特之处在于它能够混合搭配使用 IEC 61131-3 标准定义的各种语言。这使得学生的自然偏好可以在单个 PLC 中得以应用。
为明确起见，让我们重申这一观点："PLC 程序结构优于语言选择。”随着程序规模增大，这一点尤为正确。
请记住，我们将 PLC 编程定义为包含小型程序、函数和用户自定义功能块的程序组织单元（POU）。如图 1 所示，将大型程序拆分为较小的模块是非常可取的。我们可以采用经典的 Kernighan 和 Ritchie 定义：
K&R ：函数提供了一种便捷的方式来封装某些计算过程，之后便可无需关心其具体实现而直接使用该功能。通过合理设计的函数，可以忽略任务是如何完成的；只需知道完成了什么就足够了。
关键在于确定程序组织单元（POU）之间的边界在哪里。如果我们非常谨慎地抵制复制粘贴的诱惑，就可以利用人工智能来识别 POU 边界并测试边界情况。
本文是DigiKey工业自动化工厂指南的一部分
位置 ：教学指导 → 教育用元器件选型
难度 ：
学生 — 难度等级说明
最后更新 ：2026 年 3 月 06 日
图 1 ：展示 IEC 61131-3 软件命名空间的框图。右侧显示了三种类型的程序组织单元（POU），包括程序、函数和用户自定义功能块。
人工智能正在帮助程序员
要全面回答这个问题，我们需要认识到，计算机软件正进入一个新的循环开发领域，其中人工智能正协助开发者编写更优的 AI 提示词以生成软件。程序员不再埋头于底层细节，而是转向与人工智能协作的高层次开发模式。
人工智能能为 PLC 程序员做什么？
就我个人而言，我认为这是一个优势，因为人工智能可以帮助将程序解析为有意义的构建块。
-
人工智能有助于在接口层面定义这些模块，从而可能生成整洁、经过测试且文档完善的代码。
-
PLC 程序员现在能够在更高的抽象层级上工作，重点关注模块之间的交互。
-
这有望提高可维护性，因为作用于模块的人工智能可以快速分析边界情况条件，并防止“有帮助的”注释与实际代码之间出现偏差。
ST 语言与 AI 辅助编程高度兼容
前述评论同样直接适用于 ST 语言，因为大型语言模型能够处理这种基于文本的语言。我们也认识到，ST 是一种可移植的语言，具有跨不同 PLC 系列和厂商使用的潜力。它并不局限于特定的 PLC 或编程工具。
反对在 PLC 代码中使用人工智能的反方观点是什么？
我们认识到，人工智能对 PLC 与机器之间的交互以及过程的时序方面没有任何概念。因此，需要经验丰富的程序员来观察、解释并编写代码，以确保机器正确运行。同样，人工智能也不一定理解故障模式。需要经验丰富的程序员来编写 HMI 界面，以协助技术人员进行故障排查。
继续探索工业控制系统
如果本讨论对您有所帮助，您可能还想了解：
DigiKey 导航
- 完整目录 ：工业控制与自动化