Performance 成为一名更好/更高效的PLC程序员

我在这家公司实习/实习，主要是用西门子模块进行PLC编程。 这是因为大多数人都是电气工人，转而从事工程

作为新手，我的问题是，当我编写PLC软件时，我不能真正高效和快速

尽管我在VS/Eclipse中编写C#或Java时效率很高

与“真正的”编程语言相比，我不能真正有效地使用PLC，这真的让我很烦恼

• 是因为缺少代码完成吗
• 是因为缺乏自动化方面的全面知识吗
• 是因为PLC与VS（LINQ、Dynamics、Lambda）相比缺乏创新吗

你们有PLC方面的经验吗？ 你是如何用它来提高工作效率的

注意：这是我在公司的最后一年，这也是为什么我想非常有生产力

---

期待着许多伟大的答案

PLC编程与传统程序编程在以下几个方面不同：

1） 继电器梯形图逻辑是一种相当原始的语言。很难做到如此高效。

---

大多数PLC程序员不使用子程序；这就好像PLC的世界 一个被时间和软件工程所遗忘的。通过申请，你可以做得很好 简单的软件工程方法，例如定义接口 在代码块之间，即使是抽象的

2） 许多PLC编程都与布尔方程有关。如果你想做个好人 在PLC编程中，努力处理布尔逻辑：学习布尔代数， 特别是像De Morgans定理这样的不跨和或分布的定理 （由于PLC通常不提供NOT操作员，因此您需要更多 通常情况下，你会期望）

3） 了解PLC编程是关于实时控制和反馈的。 大多数标准编程语言（如Java）都不能很好地解决这个问题。 仔细考虑PLC代码是驱动输出的逻辑这一事实， 而且被驱动的机械系统是有效的“逻辑”，即 驱动PLC输入。我经常用另一个模型来模拟一个机械系统 PLC，只是让我调试我的PLC程序，而不需要真正的工厂机器 控制这也可以让你模拟失败；见第6点

4） 许多PLC编程抽象地是关于从状态到状态的转换， 其中，状态表示PLC对外部世界和过渡的了解 当PLC读取外部输入并发现世界状态已更改时发生 有些变化。尽可能多地学习有限状态自动机 以及离散系统的监控。它会给你丰厚的报酬

5） PLC通常需要记住过去的事件。因此，许多PLC逻辑是 与设置/重置/测试布尔/数字状态变量和/或计时器有关。因此，虽然PLC程序的代码通常看起来像纯逻辑，但实际上它 有很多副作用，这使得对程序进行推理变得相当困难。事实上，就像用更现代的语言（如C或Java）编写一样困难

6） 注意处理机械故障。大多数PLC程序假定 受控系统按照广告所宣传的那样工作；这真是糟糕的做法。在现实世界中，受控制的 这个系统只有在崩溃之前才会像广告中所说的那样工作，而最终它总是这样。 如果包括诊断代码以帮助确定PLC程序中的机械故障，则需要更长的时间 但是用户会喜欢你的，因为没有比这更糟糕的了 一台工厂机器坏了，但它不会告诉你怎么做。停产的工厂

---

是一台停止运转的自动取款机，工厂经理讨厌它。

PLC软件工程有其背景：

作为机电建模（整个工艺流程设计）解决方案空间的补充部分

增加了对PLC的依赖，使其成为更有价值的替代实现，但没有独立的建模技术

IEC61499推荐UML作为PLC编程的设计技术

详细说明：

作为补充部件，PLC用作顺序/状态/回路控制器、保护联锁、信号调节等，具有IEC61131规定的功能。需求在机械和电气模型中得到了很好的体现，不需要独立建模

在过程异常、恢复程序、多阶段故障模式分析和后果管理等方面的一系列要求中，对PLC的依赖程度越来越高，无意识地采用了模式设计技术。然而，不同的行业、不同的流程公司使用不同的方法。通常，它们建立在传统模型、功能设计规范文献、端到端因果列表、使用逻辑图的情况条件管理之上。其基本原则是广泛的测试、持续的应用和校正、可重用性，以完善其设计方法

鉴于缺乏PLC软件建模和IEC61158（基金会现场总线分布式对象/数据/依赖建模）的失败，IEC61499于2006年引入，并推荐UML作为设计技术。然而，过去和现在的趋势是驱动功能对象建模方法，由于时间和状态绑定，导致复杂的对象依赖性，这通常是流程应用程序中固有的，它是逻辑重的，而不是IT行业中的数据重的。因此，人们开始推出分析工具，用于结果和逻辑矛盾检查、分离时间和状态建模等，实际上并没有使事情变得更简单，并且偏离了问题空间缩减的工程原理。这一方法也是可行的

* Is it the lack of code completion?
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)