当前位置:  开发笔记 > 编程语言 > 正文

来自.NET的任何成功的profibus通信?

如何解决《来自.NET的任何成功的profibus通信?》经验,为你挑选了1个好方法。

有没有人成功地从.NET应用程序中了解profibus?

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



1> Rhys..:

我们没有使用Profibus,但使用过DeviceNET(另一种基于CAN的协议),Ethernet/IPControlNet都有类似的挑战.

自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代码中丢失通信应该将自动关闭到故障安全状态.

推荐阅读
跟我搞对象吧
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有