.NET是否可以成功进行Profibus通信? [英] Any successful profibus communications from .NET?

问题描述

有没有人从.NET应用程序成功对话 profibus ?

Has anyone successfully talked profibus from a .NET application?

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

If you did, what device/card did you use to accomplish this, what was the application, and did you use any kind of preexisting or available code?

推荐答案

我们尚未使用Profibus，但已使用 DeviceNET (另一个基于CAN的协议)，以太网/IP 和 ControlNet 都面临类似的挑战.

We've not used Profibus, but have used DeviceNET (another CAN based protocol), Ethernet/IP and ControlNet which all have similar challenges.

自1990年代末以来，我们一直在这样做，因此主要依靠我们自己使用现成的硬件生成的代码.我记得在那段时间里表现出长寿的公司是:-

We've been doing this since the late 1990's and therefore rely mainly on our own generated code using off-the-shelf hardware. The companies that have shown longevity during that period that I remember are:-

• AnyBus(HMS， www.anybus.com )我们最近开始尽可能使用其网关产品将现场总线接口放置在靠近硬件的位置，然后通过普通以太网进行通信(通常使用Ethernet/IP www.odva.org ) .这具有仅使用网络电缆将硬件和PC分开的优点.以太网/IP .NET类是我们自己编写的，因为当时市场上还没有什么.我敢肯定，快速的Google搜索会找到合适的课程库
• SST( www.mysst.com )已有十多年的现场总线接口.我们用于DeviceNET的最后一个SST卡仍然只有VB6示例代码.现场总线支持和不同形式因素的良好选择，例如PC104，PCI，PMCIA
• Beckhoff/Wago( www.beckhoff.com ，

• AnyBus (HMS, www.anybus.com) we've recently started using their gateway products as we can place fieldbus interfaces close to the hardware and then communicate over normal Ethernet (usually using Ethernet/IP www.odva.org). This has the advantage of separating hardware and PC using only a network cable. The Ethernet/IP .NET classes were written by ourselves as nothing much was on the market at the time. I'm sure a quick google search would find suitable class libraries
• SST (www.mysst.com) have had fieldbus interfaces for more than a decade. The last SST card we used for DeviceNET still only had VB6 sample code. A good selection of fieldbus support and different form-factors e.g. PC104, PCI, PMCIA
• Beckhoff/Wago (www.beckhoff.com, www.wago.com) we typically use Beckhoff for the I/O more than the interface cards but again a company that has been around a long time. They also have products that support exposing using OPC (another way for you to get I/O information without directly communicating with the hardware/devicedrivers)

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

I suggest not using OPC interfaces to the hardware directly (it’s OK for communication using PC (.NET)->PLC->Profibus) as you need to ensure that the control system responds to loss of control from your .NET application. I’m assuming that you are needing a profibus Master here (not a slave), so as long as your control system is intrinsically fail safe, then loss of communication should mean the control system enters an "Idle" state and therefore most of the I/O will return to the fails safe state.

我们还尝试确保不在.NET中放置与安全相关的代码.我们的大多数.NET代码都是来自PLC的用户界面，但是在某些地方，我们确实直接控制现场总线，但要确保硬件互锁可以防止不安全操作，无论是使用安全开关/继电器还是使用仅具有互锁任务的小型PLC . 最重要的是，这使系统具有故障安全性！..NET代码中的com丢失会导致自动操作停止进入故障安全状态.

We also try to ensure that we do not put safety related code in .NET. Most of our .NET code is userinterface from a PLC, but in some places we do control the fieldbus directly but ensure hardware interlocks will prevent un-safe operation, either using safety switches/relays or a small PLC with the the task of interlocking only. And above all make the system fail-safe! Loss of comms from the .NET code should shutdown the automation to the fail-safe state.

这篇关于.NET是否可以成功进行Profibus通信?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！