6

有没有人从 .NET 应用程序中成功谈过profibus ?

如果您这样做了,您使用什么设备/卡来完成此操作,应用程序是什么,您是否使用了任何类型的预先存在或可用的代码?

4

3 回答 3

7

我们没有使用 Profibus,但使用了DeviceNET(另一种基于 CAN 的协议)、Ethernet/IPControlNet,它们都有类似的挑战。

自 1990 年代后期以来,我们一直在这样做,因此主要依靠我们自己使用现成硬件生成的代码。我记得在那个时期表现出长寿的公司是:-

  • AnyBus (HMS,www.anybus.com)我们最近开始使用他们的网关产品,因为我们可以将现场总线接口放置在靠近硬件的位置,然后通过普通以太网(通常使用以太网/IP www.odva.org)进行通信。这具有仅使用网络电缆将硬件和 PC 分开的优点。以太网/IP .NET 类是我们自己编写的,因为当时市场上没有太多东西。我相信快速谷歌搜索会找到合适的类库
  • SST ( www.mysst.com ) 拥有现场总线接口已有十多年了。我们用于 DeviceNET 的最后一张 SST 卡仍然只有 VB6 示例代码。多种现场总线支持和不同的外形尺寸,例如 PC104、PCI、PMCIA
  • Beckhoff/Wago ( www.beckhoff.com , www.wago.com ) 我们通常将 Beckhoff 用于 I/O 而不是接口卡,但同样是一家已经存在很长时间的公司。他们还有支持使用 OPC 公开的产品(另一种无需直接与硬件/设备驱动程序通信即可获取 I/O 信息的方式)

我建议不要直接使用硬件的 OPC 接口(使用 PC (.NET)->PLC->Profibus 进行通信是可以的),因为您需要确保控制系统响应您的 .NET 应用程序失去控制。我假设您在这里需要一个 profibus 主站(而不是从站),所以只要您的控制系统本质上是故障安全的,那么通信丢失应该意味着控制系统进入“空闲”状态,因此大多数I/O 将返回故障安全状态。

我们还尝试确保不会将与安全相关的代码放在 .NET 中。我们的大部分 .NET 代码是来自 PLC 的用户界面,但在某些地方,我们确实直接控制现场总线,但确保硬件联锁可以防止不安全的操作,使用安全开关/继电器或仅执行联锁任务的小型 PLC . 最重要的是使系统具有故障安全性! .NET 代码中的通信丢失应将自动化关闭到故障安全状态。

于 2008-10-02T16:51:34.897 回答
2

我们使用 Steeplechase 将我们的 profibus 连接到我们的自动拣选系统。

http://www.phoenixcontact.com/automation/32131_31909.htm

于 2008-09-18T22:30:12.303 回答
1

试试这个: http: //libnodave.sourceforge.net

于 2010-09-16T00:07:28.330 回答