恭喜,你发布的帖子
发布于 2017-08-11 11:31:26
79楼
关于OPC控制驱动的问题,看似传动方案的问题,实则是对控制系统认知的问题。
PLC为什么可靠?循环扫描,超时出错,是个实时的控制系统。
现场总线为什么可靠?因为也是个实时的通讯,并且与PLC扫描周期是同步的。
那么PLC+现场总线+驱动,就是PLC通过实时通讯方式对驱动进行实时控制,这样的控制系统才是可靠的。
我们平时接触到的各类控制包括传动控制,应该都是属于实时控制的范畴,没有什么要求高低的,更没有客户需求的,如果客户知道你系统的通讯指令存在很大的可能性是到不了驱动器的,他是绝对不会采用你的系统的,问题是绝大部分的客户根本不明白,你也未必想向你的客户说明白,不是吗?
说白了,一个控制系统,简单也好复杂也好,实时控制是个底线,这个实时包括了程序的实时扫描和实时的数据通讯,这就是我不同意K侠方案的根本原因,并非标准的高低,而是我认为只有一个标准。
举个简单的例子对比:
PLC+现场总线+驱动 当PLC将驱动启动后,总线出问题导致通讯中断,因为实时通讯的中断,驱动会自动的停机报错,PLC也会报错,而这一些都是系统内置的集成功能,不需要任何的用户程序。通讯有优先级,与扫描周期同步。
PC+OPC+驱动 当PC通过OPC将驱动启动后,OPC通讯动态链接被WINDOWS挂起,这时通讯中断,但此时无论是驱动也好,PC也好,都无法知道通讯已经中断了,谁都在傻傻地等待。通过用户程序解决问题吗?在驱动上要通过自由功能块或DCC来解决这个问题,并不简单,况且还是废止了原来系统集成的好用又及时的功能。而在PC端,就算知道通讯被挂起,怎么能把通讯恢复呢,重启应用还重启系统?内存释放了吗?溢出和泄漏怎么办?通讯没有优先级,非循环通讯。
精华帖版主置评:如何设计出一个可靠的完整的方案,需要我们站在全系统顶层去考虑问题。有时候更是面临着成本还要尽可能低这只拦路虎
请填写推广理由:
分享
只看
楼主