有没有人从 .NET 应用程序中成功谈过profibus ？
如果您这样做了，您使用什么设备/卡来完成此操作，应用程序是什么，您是否使用了任何类型的预先存在或可用的代码？
Rich B
问问题
6490 次
3 回答
7
我们没有使用 Profibus，但使用了DeviceNET（另一种基于 CAN 的协议）、Ethernet/IP和ControlNet，它们都有类似的挑战。
自 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 连接到我们的自动拣选系统。
于 2008-09-18T22:30:12.303 回答
1
试试这个： http: //libnodave.sourceforge.net
于 2010-09-16T00:07:28.330 回答