有没有人成功地从.NET应用程序中了解profibus?
如果您这样做了,您使用了什么设备/卡来完成此任务,应用程序是什么,您是否使用了任何类型的预先存在或可用的代码?
我们没有使用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是为通信OK) - > PLC-> PROFIBUS),因为你需要确保控制系统响应来自您的.NET应用程序失控.我假设你需要在这里PROFIBUS主站(不是奴隶),所以只要你的控制系统本质安全失效,那么沟通的损失应该是指控制系统进入"空闲"状态,因此大部分的I/O将返回到失败安全状态.
我们还尝试确保不将安全相关代码放在.NET中.我们的大多数.NET代码都是来自PLC的用户界面,但在某些地方我们直接控制现场总线,但确保硬件互锁将防止不安全操作,使用安全开关/继电器或只有互锁任务的小型PLC . 最重要的是使系统安全无虞! 从.NET代码中丢失通信应该将自动关闭到故障安全状态.