我想专注于进入 Beckhoff/TwinCAT PLC 编程。
因为我比较习惯 C/C++,所以这将是一个很好的起点。与学习结构化文本相比有什么缺点吗?
我在 TwinCAT 3 上的 ST 和 C/C++ 方面都有丰富的经验。在 TC3 中,C/C++ 语言环境使操作系统意外崩溃 (BSOD) 变得容易得多,并且在您这样做时调试事情变得更加困难. 这是因为,在 TwinCAT 3 中,用户 C/C++ 代码在操作系统的驱动程序空间中运行,以实现实时性。驱动程序上下文还意味着您在代码中可以做的事情非常有限,而无需跳过箍。
C/C++ 的东西似乎旨在满足使用 TwinCAT 的 IEC 61131 PLC 不容易满足的需求,例如实现复杂的算法和与不受支持的硬件接口。这个想法是,所需的功能用 C/C++ 实现,而控制应用程序仍然用 ST 或其他 IEC 61131-3 语言实现,后者处理系统的大部分操作并提供“粘合剂”来整合将前者的功能整合到更大的系统中。
此外,虽然 TC3 上 PLC 环境的文档不是最好的,但没关系,而且比 C/C++ 环境的文档好得多。不要误会我的意思;为 TwinCAT 3 编写低级组件的能力真的很棒,经过深思熟虑,并且提供了我们经常用来为我们的控制系统制作可重用软件组件的大量功能,但这些控制系统仍然主要是用英石。
使用特定语言取决于很多因素,例如 - 目标系统是什么 - 谁是最终用户 - 面向对象和低级语言的其他典型特征 - 您计划使用哪些其他库/参考(兼容性)
原则上,您可以使用 C++ 和 ST(或其他 PLC 语言)编写代码。除了节省学习ST的时间外,没有什么特别的优势
如果它是小而简洁的应用程序,我建议使用 ST。其快速且易于调试,语法类似于 C/C++
如果您使用/曾经使用过多个符合 CodeSys 或 IEC 61131 的控制系统,ST 更便携,这是它优于 C/C++ 的另一个优势,C/C++ 不在标准中且并不总是受支持(并且当他们是,并不总是相同的方式)。
正如@JBC 上面所说,当出现问题时,ST 更容易排除故障,部分原因是它在编译时更严格,部分原因是您可以编写 IEC 检查库来检查数组越界和除以零之类的东西测试期间的错误(尽管在生产系统中启用它们通常不是一个好主意)。