【问题标题】:Very Slow PLC Programming and Fault Finding非常慢的 PLC 编程和故障查找
【发布时间】:2015-10-09 09:55:35
【问题描述】:

我在一个完整的生产环境中工作,我们的生产工厂周围有一系列 PLC,这些 PLC 中的每一个都通过“DataHighway +”网络与我们 LAN 网络上称为 MicroLinks PC 的特殊 PC 进行对话。上面有 ROCKWELL OPC RSLinx Classic 服务器软件。

所以,最近我使用 OPC .NET API 用 OPC .NET API 将一个 .NET 软件放在一起,以读取 Microlinks PC 上的 ROCKWELL OPC 服务器,并将数据同步回我们位于 WINDOWS R2 服务器上的 MYSQL 数据库电脑

自从打开 .net 软件后,现场工程师在开发新的 PLC 脚本和查找故障方面经历了巨大的缓慢。

有些报告甚至滞后 10 秒。

因此,我们不得不关闭 .NET 软件来同步数据,以便工程师能够快速完成工作而不会出现问题。

所以我正在寻找一些关于我应该在哪里或什么寻找的建议,任何可以阅读此类问题的资源等。由于 PLC 和网络超出了我的深度,我只是一个 .NET 程序员。

这是我们网络的结构:

【问题讨论】:

    标签: c# .net plc opc


    【解决方案1】:

    我不确定您使用的是哪种类型的罗克韦尔 PLC。我对 ControlLogix 平台最熟悉,所以我会谈谈它。

    1. controllogix PLC 中的以太网卡以 100Mb/s 的速度连接,但该卡实际上无法连续处理 100Mb/s。 1756-ENBt 卡每秒可以处理大约 5000 个数据包,EN2T 大约是其两倍。罗克韦尔文档中的公式解释了如何计算每秒数据包,但是当您有一个正在运行的系统时,另一个选择是连接 RS Logix 附带的“Logix5000 任务监视器”并验证 CPU 使用率以太网卡 我认为 Rockwell 建议您将其保持在 60% 以下。如果你请求的数据包太多,那么这个 CPU 就跟不上

    2. PLC 本身会导致通讯中断。 Controllogix 有一个“开销时间片”设置,它是 PLC 用于服务通信任务而不是运行自己的逻辑的时间百分比。增加这个百分比可以稍微改善通信。

    听起来您的程序给 PLC 带来了很大的负担。如果您放慢应用程序的速度以使其无法以同样快的速度提取数据,它会变得更好吗?

    在不降低更新速率的情况下减少检索数据块所需的数据包数量的一种简单方法是将所有数据放入一个数组中。然后,RSLinx 将能够优化请求,而不是提取单个标签

    【讨论】:

      【解决方案2】:

      我在本地 PC 上使用 Rockwell RSLinx 时遇到了很多麻烦,试图找到直接插入我的以太网端口的 PLC 的 IP 地址。使用“自动浏览”选项,它会完全锁定我的 PC,试图扫描目标的端口和 IP 地址。

      可能只是优化不佳的 Rockwell 软件导致问题。您还可能正在交换大量数据,而您的服务器 PC 正在努力跟上。

      我会联系 Rockwell/Allen Bradley 支持部门寻求帮助。他们可能需要一些现金来帮助您。

      【讨论】:

        【解决方案3】:

        您几乎肯定会过度轮询 PLC。尝试越来越少地轮询,直到找到一个不会降低网络速度的值 例如,如果您现在每 100 毫秒请求一次数据,则每秒更改一次。然后每分钟一次。然后每15分钟一次。在每一步检查编程终端的通讯速度。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2011-05-28
          • 1970-01-01
          • 2013-10-16
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多