我正在实习/见习的公司主要使用西门子模块进行 PLC 编程。这是因为大多数人都是电工并转而从事工程工作。
作为新手，我的问题是，当我编写 PLC 软件时，我不能真正高效和快速地编写代码。
即使我在 VS/Eclipse 中编写 C# 或 Java 时效率很高
与“真正的”编程语言相比，我不能真正使用 PLC 来提高工作效率，这真的很烦人。
各位大佬有没有用过PLC的？你是如何使用它的？
注意：这是我在公司的最后一年，这也是我想要非常高效的原因。
期待许多精彩的答案！
PLC 编程在几个方面不同于传统的程序编程：
1）继电器梯形逻辑是一种相当原始的语言。很难有同样的生产力。大多数 PLC 程序员不使用子程序；就好像 PLC 世界是一个被时间和软件工程遗忘的世界。因此，您可以通过应用简单的软件工程方法做得很好，例如，定义代码块之间的接口，即使是抽象的。
2) 大部分 PLC 编程都与布尔方程有关。如果你想擅长 PLC 编程，请努力处理布尔逻辑：学习布尔代数，尤其是像德摩根定理这样的东西，用于在 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 程序中的机械故障，您将需要更长的时间来编写它们，但用户会喜欢您，因为没有什么比损坏但无法说明的工厂机器更糟糕的了你怎么。停产的工厂就是停产的提款机，工厂经理讨厌这样。
当所谓的“真正的”程序员轻蔑地看待 PLC 编程时，这让我很恼火。这里的几篇文章暗示了 PLC 编程本身就是一门学科的基本事实。
“了解 PLC 编程是关于实时控制和反馈的。大多数标准编程语言（例如 Java）都很难解决这个问题。”
“所以人们开始提出用于结果和逻辑矛盾检查、分离时间和状态建模等的分析工具，实际上并没有让事情变得更简单，并且偏离了问题空间缩减的工程原则。”
暗示梯形逻辑是“被遗忘的纪律”是贬低执行其功能的工具。毕竟，Ladder 是第一种在软件中实际表示物理设备的语言——它是面向对象编程范式的发源地。
此外，我们不要忘记 PC 和基于 PC 的控件是完全不可信的。它崩溃了；组件已过时，最多在几年内无法购买；它崩溃了；它被病毒和人们在他们的工作站上放置“大金刚”所破坏；它崩溃了；无聊的操作员在第三班卸载软件；我有没有提到，它崩溃了？
在 PC 世界中所谓的“进步”这么多年之后，PLC 仍然存在，因为直到今天，PC 仍然是充满漏洞的一次性商品。而你价值数百万美元的装配线却不是。
最后，我坚持幽默测试——让我感到震惊的部分是看到 IT 人员试图编写 PLC 代码。我们似乎得到的永无止境的问题（从字面上和比喻上）是，“为什么当我跳回到程序的开头时会出现看门狗错误？” 或者另一个个人最喜欢的 - “我如何在梯子中编写一个 for-next 循环？”
两者都暴露了对 PLC 如何工作的基本知识缺乏，并进一步说明自动化编程是一门独立的学科，需要不同的工具。
TM值
我同意你提到的 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 用于自动化工程师，ST 用于 C/PASCAL 程序员......）。所以在我看来，这并不比其他任何事情更复杂。VS 也有其复杂性：尝试使用 C++ 制作您自己的 OPC 服务器，您会很高兴看到此功能在大多数 SoftPLC 中随时可用。在这种情况下，智能感知不会有太大帮助。
可以肯定的是，PLC 编程市场不像通常的编程工具那样充满活力。我认为它来自工业世界，它更喜欢防布尔技术而不是营销性感的东西。
我希望它有帮助
编程语言是工具。如果你只懂一种语言，你就只有一种工具。该工具可能适用于一项工作，适用于其他几个工作，而对其他所有工作无用。如果你知道更多的工具，你可以做更多的工作。
您所看到的不仅是 C# 和 Java 等“真实”语言之间的区别，还包括 PC 上的非实时应用程序与 PLC 主要用途的实时机器控制之间的区别。
优秀的程序员了解语言，优秀的程序员了解流程。他们不仅了解他们正在编程的语言，还了解编程的过程。如果您要编写会计软件，您需要了解会计。如果你要编写 PLC 代码来控制一台机器，你最好知道这台机器做什么以及它是如何工作的。
看看西门子 Simatic Step7 的这两款产品：
简单地说，第一个实际上是 Pascal，它对于制作自己的块非常有用。第二个是从左到右易于导航的图形表示和这些块的链接，以及对它们的强大在线监控。
这两个将为您提供您所寻求的效率，因此您可以完全忘记 STL/LAD/FBD（分析其他人的代码时除外）。结合起来，它们是用于 PLC 编程的非常强大的 RAD 工具。
PLC软件工程有其背景：
详细说明：
作为互补组件，PLC 被用作序列/状态/回路控制器、保护联锁、信号调节等，具有 IEC61131 中规定的特性。需求在机械和电气模型中得到了很好的捕捉，不需要独立建模。
在对过程异常、恢复程序、多阶段故障模式分析和后果管理的要求上增加了对 PLC 的依赖，无意识地采用了模式设计技术。但是，不同行业不同的工艺公司采用不同的方法。通常，它们建立在传统模型、功能设计规范文献、端到端因果列表、使用逻辑图的情况条件管理之上。基本原则是广泛的测试、持续的应用和修正、可重用性以完善他们的设计方法。
由于缺乏PLC软件建模和IEC61158（基础现场总线分布式对象/数据/依赖建模）的失败，IEC61499于2006年推出，推荐UML作为设计技术。然而，这种趋势过去和现在都在推动功能对象建模方法，由于时间和状态绑定通常在流程应用程序中固有的复杂的对象依赖关系是逻辑繁重而不是 IT 行业中的数据繁重。所以人们开始提出结果和逻辑矛盾检查、分离时间和状态建模等分析工具，实际上并没有让事情变得简单，并且背离了问题空间缩减的工程原理。该方法还缺乏对机械、电气和过程建模文档的亲和力和连续性。
目前的情况是：
一种。IEC61131 和 IEC61499 是制造商标准，让控制工程师无需处理实时操作系统问题，应该会在未来很长一段时间内继续成为应用标准
湾。UML 是非常可能的设计方法
C。UML 之上的设计模式应确保对象模型与过程模型（数据流而不是产品流，数据模型是实际对象属性）、绑定模式、故障升级模式、互锁升级模式相似/相等/密切相关，隐式工厂和对象模式等。PLC 的良好数据模型也是成功的 UI 或 SCADA 设计的关键。
通过为水处理厂和带有装载/卸载机器的工厂输送机开发一套完全合理的设计模式，我成功地实施了系统。我需要环境来详细说明设计模式，太多话要说，测量/设备/子系统/过程/工厂对象的概念背景，它们的依赖关系，它们的隐含关系，一些限制和管理变化传播的简单规则， ETC。