我使用 Beckhoff PLC（结构化文本语言）一段时间，并尝试在所有算法中不使用 for 循环，以确保一切实时工作并且不会陷入任何循环。时间对于我正在研究的算法非常重要。代码中的任何行都会在 1 毫秒内完成。如果我在某个地方使用 for 循环，我会想，当它进入 for 循环时，每次迭代将花费 1 毫秒，因此其余软件将保持不变，直到完成循环。
因此，我没有编写任何循环，但我的一位同事用 for 循环实现了他的软件。循环从 1 开始到 100000，每 1ms，计数器增加 100000，其他计数器增加 1ms，这些计数器不在循环中。
我知道的程序是，如果PLC在处理完1ms以下的所有内容后有时间，它会关心剩下的可能是诊断检查或IO检查或其他什么。
那么当我确定周期时间为 1 毫秒时，它如何处理 100000 次迭代。如果我在程序中使用 100 万个不同的循环会怎样？它也可以处理 for 循环，因为程序很小。当软件很大时，它的行为会相同吗？我如何理解它可以完成所有循环而不导致循环时间溢出？ 我会尝试看看，但为了获得见解，我想与您讨论。
对于处理是否可以保持在您预期/要求/首选的扫描周期时间内的问题，没有通用答案。
计算能力是有限的。循环的每次迭代都需要非零计算能力，因此，当然，需要处理的循环（和/或循环迭代）数量可能会超出 PLC 的处理能力。 PLC 中没有任何魔法可以使循环变得“自由”。另一方面，一般来说，循环非常快（与循环内执行的处理相比）。
只有当循环造成浪费时，它本质上才是次优的。替换执行 N 次迭代的循环在计算上并不比在没有循环的情况下编码 N 次相同的代码差。
有迹象表明你的循环可能很浪费：
在 PLC 中，您需要确保循环执行的处理可靠地适合您的循环时间。最坏的情况是你关心的：如果你的循环在 99.9% 的情况下需要 0.01 毫秒，但最后 0.1% 需要 1 秒，那么它将不起作用。
如果循环最适合算法（就算法效率、清晰度、可维护性而言），它可能是表达解决方案的最快（或非常接近最快）的方法。只有当您编写了浪费循环的代码时，您才应该害怕循环。
最后，如果您的 PLC 功能不够强大，即使使用编码良好的解决方案也无法完成所有需要完成的工作，那么存在或不存在循环就不是问题或解决方案。但假设您的 PLC 速度很快。非常快。我运行的程序包含数十万个变量，每个周期执行许多循环，并且在 Raspberry Pi 上得到的周期时间低于 0.1 毫秒。我从不避免任何本质上“循环”的循环，但我的循环从不阻塞等待某些东西，它们从不分配内存或执行会在执行时间中引入有意义的变化的处理，并且它们做“简单”的事情（其中“简单”） “阅读时要理解当今计算机确实非常快）。
真正的问题不在于循环是好还是坏，而是您是否能够确定何时使用它们，并知道如何很好地编写它们。这与循环的好坏无关，而在于你对它们的好坏。
另外，测试一下。查看在循环时间受到影响之前可以执行多少次空循环迭代。尝试使用执行您关心的事情的非空循环。您将很快了解真正的瓶颈，并且可能不再担心循环并专注于循环内的代码。
程序的“循环器”部分按确定的时间间隔调用。它必须返回，然后再次被控制器软件调用。
您可以在循环器中使用您想要的任何内容，包括循环、函数调用、递归或其他任何内容。所有这些都将在循环器的一次迭代内运行，并且必须及时完成，不要花太长时间。如果您的程序需要很长时间才能执行，则必须将其安排在另一个速度较慢的循环器上。控制器通常提供几个，具有不同的发射率。
在我的例子中（B&R），溢出行为没有被准确记录，但我认为最好不要记录，特别是如果你进入一个根本不返回的循环。这不是它应该如何工作的。