恭喜,你发布的帖子
发布于 2017-08-09 20:54:59
70楼
K版又做了个很不好的示范,勾起别人的兴致,但又做不好,连个EMC都解决不了的用户怎么能解决这个通讯问题?
好多做检测设备的用户,都曾向我提出要做这个方案,都被我严厉拒绝,有不死心的自己去做,通讯好通,应用难用啊,涉及到方方面面的问题,给自己挖坑的节奏,结果惊人的一致,均以失败告终,任你是个高手,博士硕士扎堆。
用个PLC其实也没啥成本,而PC与PLC同驱动通讯的可靠性根本就不在一个数量级上,要么就用WINAC(大多数人是从内心就拒绝的),多少人是不撞南墙不回头啊。
STARTER软件,在控制面板调试时,只要一切换界面,系统就停机,为啥?问各位你们的控制软件有STARTER做得那么好吗?
还得给Zane解释一下。
第一,这种OPC的应用结构,仅仅是我们试验台产品的一个种类,它是针对某一个动力产品的行业需求而开发的测试台,并不是我们产品的全部和发展方向;
第二,在测试台行业,PLC功能是必须的。要么是硬件的,要么是软体的。这个逻辑控制和闭环调节器的工艺功能必须有。我们在汽车行业的测试台都是S7 300,在其他行业的测试台,有300也有200的PLC。视用户的需求而定,并不是一种固定的模式。每一个客户的需求都不一样,所以试验台基本都是定制的;
第三,因为亲手做的OPC的实验和测试,所以对这种结构和效果,比较感慨。假如采用S120系统,由DCC完成控制工艺,OPC与上位机连接操作系统。针对绝大多数的客户需求,也够用。这是我比较感兴趣的;
第四,在测试台产品上,安全功能是首先要考虑和保证的。因为高速旋转的运行,故障往往是非常危险的。在这方面,从传统继承上,也是要遵循专业操控习惯的。毋庸置疑。
这种OPC直接与上位机通讯的结构,不是我们国内的专利,在国外也是有这样的应用的。自动化与驱动虽然涉及的应用面很广,但每一个行业都有自己的认可习惯。所以,按照客户需求去开发定制的系统,也无可厚非。有时候我们主动推荐的东西,客户并不买账,买方总是以自己为主的。没办法。
目前,有关OPC通讯的功能测试已经完成,剩下的就是编辑VB.NET操作环境下的实验界面的监控和实验结果数据库数据处理等环节的功能(包括实验结果检索,数据图表等)。目前没有发现通讯数据卡阻,死机等现象。对这样的结构应用,还是很有信心的呦。
请填写推广理由:
分享
只看
楼主