结构化文本/HSM引擎中的干净代码PLC编程

Question

我从结构化文本中的 PLC 编程开始，特别是使用 Beckhoff Twincat 3，我拥有 C/C++ 嵌入式编程背景和一些用于跨平台开发的 C#/Python。我仍处于入门阶段，并尝试从我所读到的内容和我在使用 Twincat 3 和一些硬件时所经历的内容中理解。

我研究过我的一位同事三年前编写的一个项目，它看起来一点也不“干净的代码”。我几乎什么都听不懂。有一个功能块

FB_DriveCommands.TcPOU

，大约有 2600 行代码！！！

我的问题，一个一般性问题和一个更具体的问题：

1. 这在 PLC 世界中正常/可以接受吗？我必须习惯吗？如果不是，那是什么？您在组织内的 PLC 编程中使用“干净代码”方法有哪些经验？
2. 特别是，我发现上述项目中的状态机始终通过

   CASE ... OF

   实现，即使它们很复杂，这会导致很长很长的代码段，您必须在其中迷失方向。是否有任何库支持不同的实现，甚至可能支持分层状态机（HSM）？ （注：我已经看过 Twincat 功能“UML 状态图”，但坚持结构化文本是必须的）。

Answer 1

如果您使用结构化文本，那么代码变得丑陋混乱但“在 PLC 世界中是可接受的”并没有根本原因。 PLC 程序是软件，结构化文本与 C/Pascal 没有太大区别，还有一些基本的 OO 设施。

现在，关于状态机。在自动化领域，人们为机器编写代码，机器也有状态，对吗？那么如果将机器和状态放在一起会发生什么呢？嗯，当然是状态机。有时，我觉得这个概念在自动化领域流行的原因就是它的名字。

学习计算机科学时，状态机是您首先学到的东西之一。你会发现它们的局限性，并且你会很快转向更复杂的语法来完成你所做的大部分事情，尽管状态机有它们擅长的特定用例。

从本质上讲，物理系统及其多维读数的不断发展、不可预测的本质并不是我将其与状态机联系起来的建模挑战。事实上恰恰相反。我对机器进行编程，从不使用状态机。

混乱的状态机可能表明状态机不是正确的抽象。