做一个更好/更高效的PLC程序员[关闭]

PLC编程不同于传统的程序编程,有以下几种方式:

1)继电器梯形逻辑是一种相当原始的语言。很难像现在这样富有成效。 大多数PLC程序员不使用子程序;它几乎就像PLC世界一样 一次和软件工程忘记了。你可以通过申请做得很好 因此,简单的软件工程方法,例如定义接口 在代码块之间,即使是抽象的。

2)大部分PLC编程都与布尔方程有关。如果你想做个好人 在PLC编程,工作 坚硬的 在处理布尔逻辑时:学习布尔代数, 特别是像德摩根斯定理这样的东西,不分布于和或之间。 (由于PLC通常不提供非运营商,您需要更多 经常是这样)

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)在根本上解决这个问题。

因此,人们开始使用分析工具来检查结果和逻辑矛盾、分离时间和状态建模等,实际上并没有使事情简单化,并且偏离了问题空间缩减的工程原理。

暗示阶梯逻辑是“被遗忘的纪律时间”,就是贬低执行它功能的工具。毕竟,梯形图是第一种在软件中实际表示物理设备的语言——它是面向对象编程作为范例的诞生地。

另外,让我们不要忘记,PC和基于PC的控制是完全不可信的。它崩溃了;组件过时了,不能在几年内买到,充其量是;它崩溃了;它被病毒破坏了,人们把“驴子孔”放在他们的工作站上;它崩溃了;无聊的操作员在第三班不安装软件;我有没有提到,它崩溃了?

在个人电脑界经历了这么多年所谓的“进步”之后,可编程逻辑控制器依然存在,因为到今天为止,个人电脑仍然是加了窃听器的一次性商品。而你那价值数百万美元的装配线却不是。

最后,我坚持了幽默测试——让我崩溃的部分是看到那些试图编写PLC代码的人。我们似乎得到了一个永无止境的问题(字面上和比喻上),那就是:“当我跳回到程序开始时,为什么会出现看门狗错误?”或者另一个人的最爱——“我该如何在梯子上写下一个循环?”

两者都暴露了对PLC如何工作的基本知识的缺乏,进一步说明了自动化编程是一个单独的规程,需要单独的工具。

商标

我同意你提到的3个问题。

我对codesys有一些经验,我认为其中2个问题在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服务器,你会很高兴看到这个特性可以在大多数软PLC中使用。在这种情况下,智能感知并不是一个很大的帮助。

可以肯定的是,PLC编程市场没有通常的编程工具那么活跃。我认为它来自工业界,他们更喜欢防胸部技术,而不是销售性感的东西。

希望有帮助

编程语言是工具。如果你只知道一种语言,你就只有一种工具。这个工具可能对一个工作很好,对其他两个工作也不错,对其他所有工作都没用。如果你知道更多的工具,你可以做更多的工作。

你所看到的不只是C语言和Java之间的“真实”语言的区别,而是PC上的非实时应用和实时机器控制之间的差异,这是PLCs的主要用途。

好的程序员懂得语言,好的程序员懂得过程。他们不仅理解他们正在编程的语言,而且理解编程的过程。如果你要写会计软件,你需要知道会计。如果你打算写PLC代码来控制一台机器,你最好知道那台机器是做什么的以及它是如何工作的。

看看西门子Simatic Step7的这两种产品:

1. 症状自评量表 (已在Step7专业版中,也称为ST或结构化文本)
2. 氯氟烃 (单独产品)

简单地说,第一个实际上是一个帕斯卡,它可以非常有用,使您自己的块。第二个是从左到右的易于导航的图形表示和这些块的链接,以及对它们的在线强大监控。

这两种方法将为您提供所需的效率,因此您可以完全忘记stl/lad/fbd(在分析其他人的代码时除外)。结合起来,它们是非常强大的和用于PLC编程的RAD工具。

PLC软件工程有其背景:

1. 作为机电建模解决方案空间的补充部分(整个流程设计)
2. 对可编程逻辑控制器的依赖增加了,这是更值得替代的实现,但没有独立的建模技术。
3. IEC61499推荐UML作为PLC编程的设计技术。

详述:

1. 作为补充组件,PLC被用作序列/状态/回路控制器、保护联锁、信号调节等,具有IEC61131规定的功能。在机械和电气模型中很好地捕捉到了需求,无需独立建模。

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

3. 针对UIE61158(Foundation FieldBUS分布式对象/数据/依赖性建模)缺乏PLC软件建模和失败的问题,以UML为设计技术,在2006引入IEC61499。然而,这种趋势过去和现在都是DRIVNG功能对象建模方法,这导致了复杂的对象依赖性,这是由于时间和状态绑定通常是流程应用程序固有的,与IT行业一样,它的逻辑性很强,而不是数据性很强。因此,人们开始提出后果逻辑矛盾检查、分离时空建模等分析工具,实际上并没有使事情简单化,偏离了问题空间缩减的工程原理。该方法也缺乏对机械、电气和过程建模文档的亲和力和连续性。

目前情况是:

a.作为制造商标准的IEC61131和IEC61499,以及控制工程师不需要处理实时操作系统问题的自由控制工程师,应该在很长一段时间内继续作为应用标准。

B.UML是非常可能的设计方法

c.UML之上的设计模式应确保对象模型与过程模型(数据流而不是产品流、数据模型是实际的对象属性)、绑定模式、故障升级模式、互锁升级模式、隐式工厂和对象模式等类似/相等/接近。良好的PLC数据模型也是关键。成功的用户界面或监控与数据采集设计。

我通过为水处理厂和带装载/卸载机的工厂输送机开发一套完全合理的设计模式,成功地实现了系统。我需要环境来详细说明设计模式,太多的内容需要讨论,测量/设备/子系统/过程/工厂对象的概念背景,它们最精干的深度,它们的隐式关系,限制和管理变更传播的一些简单规则等。