有人成功通过.NET应用程序成功对话profibus吗？

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

解决方案

回答

我们已使用跳栏板将Profibus连接到我们的自动拣选系统。

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

回答

我们没有使用Profibus，但是使用了DeviceNET(另一个基于CAN的协议)，Ethernet / IP和ControlNet，它们都面临类似的挑战。

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

• 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，www.wago.com)我们通常将Beckhoff用于I / O的方法多于接口卡，但对于一家已经使用了很长时间的公司而言，我们也是这样。他们还提供了支持使用OPC进行公开的产品(另一种无需直接与硬件/设备驱动程序通信即可获取I / O信息的方式)

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

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

回答

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