有没有人聊成功了profibus http://www.profibus.com/来自 .NET 应用程序？
如果您这样做了，您使用什么设备/卡来完成此操作，应用程序是什么，以及您是否使用任何类型的预先存在或可用的代码？
我们没有使用过Profibus，但是使用过设备网（另一个基于 CAN 的协议），以太网/IP and 控制网它们都面临着类似的挑战。
我们自 20 世纪 90 年代末以来一直在这样做，因此主要依赖于我们自己使用现成硬件生成的代码。我记得在那段时期表现出长寿的公司是：-
- AnyBus（HMS，www.anybus.com http://www.anybus.com）我们最近开始使用他们的网关产品，因为我们可以将现场总线接口放置在靠近硬件的位置，然后通过普通以太网进行通信（通常使用以太网/IPwww.odva.org http://www.odva.org）。这样做的优点是仅使用一根网线即可将硬件和 PC 分开。以太网/IP .NET 类是我们自己编写的，因为当时市场上还没有什么东西。我确信快速谷歌搜索会找到合适的类库
- SST (www.mysst.com http://www.mysst.com）现场总线接口已经存在十多年了。我们用于 DeviceNET 的最后一个 SST 卡仍然只有 VB6 示例代码。现场总线支持和不同外形尺寸的良好选择，例如PC104、PCI、PMCIA
- 倍福/瓦戈（www.beckhoff.com http://www.beckhoff.com, www.wago.com http://www.beckhoff.com）我们通常在 I/O 方面使用倍福（Beckhoff），而不是接口卡，但同样是一家历史悠久的公司。他们还有支持使用 OPC 公开的产品（另一种无需直接与硬件/设备驱动程序通信即可获取 I/O 信息的方法）
我建议不要直接使用 OPC 接口连接硬件（使用 PC (.NET)->PLC->Profibus 进行通信是可以的），因为您需要确保控制系统对 .NET 应用程序失去控制做出响应。我假设您在这里需要一个profibus主站（而不是从站），因此只要您的控制系统本质上是故障安全的，那么失去通信就意味着控制系统进入“空闲”状态，因此大多数I/O 将返回到故障安全状态。
我们还尝试确保不会将安全相关代码放入 .NET 中。我们的大多数 .NET 代码都是来自 PLC 的用户界面，但在某些地方，我们确实直接控制现场总线，但确保硬件互锁将防止不安全的操作，无论是使用安全开关/继电器还是仅执行互锁任务的小型 PLC 。最重要的是确保系统故障安全！.NET 代码中的通信丢失应将自动化关闭至故障安全状态。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
