我正在做我的船员/ appretinceship的公司，主要是用西门子模块进行PLC编程。 事实上，大多数人都是电动人员，并转而从事工程设计。
我作为新手的问题是，当我编写PLC软件时，我不能真正高效和快速。
即使我在VS / Eclipse中编写C＃或Java
时效率很高与“真正的”编程语言相比，我无法用PLC实现高效率。
你们对PLC有什么好的经验吗？ 你是如何通过它获得高效的？
注意：这是我去公司的最后一年，这也是我想要提高工作效率的原因。
期待许多精彩的答案！
答案 0 :(得分：26)
PLC编程在几个方面与传统的程序编程不同：
1）Relay Ladder Logic是一个相当原始的语言。很难有所作为。 大多数PLC程序员不使用子程序;它几乎就像PLC世界一样 一个时间和软件工程忘了。你可以申请成功 因此，简单的软件工程方法，例如，定义接口 在代码块之间，即使是抽象的。
2）许多PLC编程都与布尔方程有关。如果你想成为好人 在PLC编程中，在处理布尔逻辑时工作 hard ：学习布尔代数， 尤其是De Morgans定理，用于在AND和OR之间分配NOT （由于PLC通常不提供NOT运算符，因此您需要更多 通常你会期待）
3）了解PLC编程是关于实时控制和反馈的。 如果有的话，大多数标准编程语言（例如Java）都很难解决这个问题。 仔细考虑PLC代码是驱动输出的逻辑这一事实， 并且被驱动的机械系统实际上是“逻辑”的 驱动PLC输入。我经常使用另一个机械系统建模 PLC，只是让我调试我的PLC程序而无需真正的工厂机器 控制。这也可以让你模拟失败;见第6点。
4）很多PLC编程都抽象地从状态转换到状态， 其中状态表示PLC了解外部世界和过渡的信息 当PLC读取外部输入并发现世界状态时发生 改变了一点。尽可能多地了解有限状态自动机 离散系统的监督控制。它会给你带来丰厚的回报。
5）PLC经常需要记住过去的事件。因此，很多PLC逻辑都是 关注设置/重置/测试布尔/数字状态变量和/或定时器。因此，虽然PLC程序的代码通常看起来像纯逻辑，但事实上它 有很多副作用，这使得对程序的推理相当困难。事实上，就像用更现代的语言（如C或Java）写作一样困难。
6）注意处理机械故障。大多数PLC程序都假定 受控制的系统如宣传的那样工作;这真的很糟糕。在现实世界中，受控制 系统只作为广告宣传，直到它中断，总是最终完成。 如果包含诊断代码以帮助确定PLC程序中的机械损坏，则需要更长时间 写它们，但用户会爱你，因为没有比这更糟的了 一台工厂机器坏了，但它不会告诉你如何。一个停止的工厂 是停止的自动取款机，工厂经理讨厌这个。
答案 1 :(得分：9)
当所谓的“真正的”程序员蔑视PLC编程时，这让我很恼火。这里的几篇帖子暗示了PLC编程本身就是一门学科的基本事实。
“了解PLC编程是关于实时控制和反馈的。大多数标准编程语言（例如Java）都解决了这个问题。”
“因此人们开始提出分析工具，用于结果和逻辑矛盾检查，单独的时间和状态建模等，实际上并没有使事情更简单，并且偏离了减少问题空间的工程原理。”
暗示梯形逻辑是“忘记纪律时间”是贬低执行它的功能的工具。毕竟，Ladder是实际代表软件中物理设备的第一种语言 - 它是面向对象编程作为范例的发源地。
此外，我们不要忘记PC和基于PC的控件完全不值得信任。它崩溃了;组件过时，不能在几年内购买，充其量;它崩溃了;它被病毒和人们把“大金刚”放在他们的工作站上而受到腐蚀;它崩溃了;无聊的操作员在第三班卸载软件;我提到了，它崩溃了吗？
在PC领域经过这么多年所谓的“进步”之后，PLC仍然存在，因为到目前为止，个人电脑仍然是添加了虫子的一次性商品。你的数百万美元的装配线不是。最后，我坚持了幽默测试 - 让我感到震惊的部分是看到IT人员试图编写PLC代码。我们似乎得到的永无止境的问题（字面上和比喻上）是，“当我跳回到程序的开头时，为什么会出现看门狗错误？”或者另一个个人喜爱的 - “如何在梯子中写下一个下一个循环？”
两者都背叛了对PLC如何工作的基本缺乏知识，并进一步说明自动化编程是一门独立的学科，需要单独的工具。
TM
答案 2 :(得分：2)
我同意你提到的3个问题。
我对CoDeSys有一些经验，我认为其中有两个问题在版本3.x中消失了。
* Is it the lack of code completion?
* Is it the lack of innovation in PLC as opposed to VS (LINQ, Dynamics, Lambda)
CoDeSys 3.x具有智能和用户友好的编辑器，它为PLC世界带来了面向对象的编程，这在我看来是一个非常好的创新。
我认为这有助于提高生产力。我不知道CoDeSys的竞争对手是否做了类似的事情，但我认为PLC编程市场上有一些有趣的事情发生。
所有技术都缺乏知识。无论开发人员的背景如何，IEC-1131都被设计为易于理解（电工用LD，自动化工程师用FBD，C / PASCAL程序员用ST ......）。所以在我看来，其他任何东西并不复杂。 VS也有它的复杂性：尝试用C ++制作自己的OPC服务器，你会很高兴看到这个功能可以在大多数SoftPLC中使用。在这种情况下，智能感知不会是一个很大的帮助。
当然，PLC编程市场的动态性低于通常的编程工具。我认为它来自工业世界，它更喜欢防止boolet技术，而不是营销性感的东西。
我希望它有所帮助
答案 3 :(得分：1)
编程语言是工具。如果您只知道一种语言，则只有一种工具。该工具可能适用于一项工作，对其他几项工作可以，对其他所有工作都没用。如果您了解更多工具，则可以完成更多工作。
您所看到的不仅仅是C＃和Java等“真实”语言之间的差异，而是PC上非实时应用程序与PLC主要用途的实时机器控制之间的差异。
优秀的程序员知道语言，优秀的程序员知道流程。他们不仅了解他们编程的语言，还了解编程的过程。如果您要编写会计软件，您需要了解会计。如果您要编写PLC代码来控制机器，您最好知道该机器的功能及其工作原理。
答案 4 :(得分：0)
看看西门子Simatic Step7的这两个产品：
简单地说，第一个实际上是Pascal，它对于制作自己的块非常有用。第二个是从左到右的易于导航的图形演示和链接，以及在线强大的在线监控。
这两个将为您提供所需的效率，因此您可以完全忘记STL / LAD / FBD（除非在分析其他人的代码时）。结合起来，它们是用于PLC编程的非常强大的RAD工具。
答案 5 :(得分：-1)
PLC软件工程有其背景：
详细说明：
作为补充组件，PLC用作序列/状态/回路控制器，保护互锁，信号调节等，具有IEC61131中规定的特征。要求在机械和机械方面得到很好的体现。电气模型，没有必要进行独立建模。
在过程异常，恢复程序，多阶段故障模式分析和后果管理的要求上增加了对PLC的依赖，开发了无意识采用模式设计技术。但是，不同行业的不同流程公司使用不同的方法。一般来说，它们建立在传统模型，功能设计规范文献，端到端原因和基础之上。效果列表，使用逻辑图的情境的条件管理。基本原则是广泛的测试，持续的应用和修正，可重用性以完善他们的设计方法。
由于缺乏PLC软件建模和IEC61158（基础现场总线分布式对象/数据/依赖建模）的失败，IEC61499于2006年推出，推荐使用UML作为设计技术。然而，趋势是并且正在驱动功能对象建模方法，导致由于时间和状态绑定导致的复杂对象依赖性，这些绑定通常在过程应用程序中固有，这在逻辑上是重的而不是像IT行业那样的数据。因此人们开始提出结果和分析工具。逻辑矛盾检查，分离时间和状态建模等，实际上并没有使事情变得简单，并且偏离了问题空间减少的工程原理。该方法也缺乏对机械，电气和过程建模文档的亲和力和连续性。
目前的情况是：
一个。 IEC61131＆amp; IEC61499是制造商标准，免费控制工程师需要处理实时操作系统问题，应该在很长一段时间内继续成为应用标准
湾UML是非常可能的设计方法
℃。 UML之上的设计模式应该确保对象模型与流程模型相似/相等/紧密相关（数据流而不是产品流，数据模型是实际对象属性），绑定模式，故障升级模式，互锁升级模式，隐含的植物和PLC的良好数据模型也是成功的UI或SCADA设计的关键。
我已成功实施系统，为水处理厂和带装卸机的工厂输送机开发了一套完全合理的设计模式。我需要环境来详细说明设计模式，过多谈论，测量/设备/子系统/过程/工厂对象的概念背景，它们最简洁的依赖关系，隐式关系，限制和管理变化传播的一些简单规则等等。