采用opc server 监控300PLC数据，漏点。
郑志武
发布于2012-11-29 18:42
2
0
标签：
试验内容如下：
300plc发出1hz的触发信号，维持500ms高电平，500ms低电平，矩形触发信号。
基于s7，采用opcserver通讯。
采用订阅方式监控变量。
plc端opcservers7的扫描时间100ms
opcserver的刷新频率250ms
通过试验以及日志记录发现，存在漏点的现象。
即下面的触发信号变化了，上位机没有捕捉到。
哪儿位大侠知道什么原因？
如果不希望漏点，有什么更好的通讯办法
问题补充：
可能是有些偏执吧
在进行的数据试验中，单次读数据量为3k，此外，还额外附加了3~6k的监控数据。测试这种通过中断完成高速数据采集程序的可靠性。plc端用中断完成高速数据采集（这可以做日志，也可以做黑匣子，故障追溯等等等等）
触发信号只是告诉上位机去读数据
如果丢失触发信号，就漏了数据报。
在24小时试验中，丢失了一个触发信号，1s钟的数据。
我又采用fb12做了send/receive的试验，提高中断程序频率，做了加速试验。这种方式，在频率苛刻的情况下，也会漏掉触发信号。
又试验了直接把包数据完整send，上位机读一个dt信号，dt信号变化同步读cache，这种方式在1hz的频率下表现还算稳定。
但所有漏点的发生有随机性，可能还是工业以太网通讯的实时性不强引起的。
下一步，计划上位机和plc直接采用tcp通讯，传送触发信号，保障触发信号不漏。只要触发被捕捉，再常规的异步读操作即可。
如果触发的频率在1hz以上，采取合理的参数设置，漏点的几率还是非常低的，1/100000。
网络负荷比较平稳的情况下，效果更好。
毕竟我在试验中额外增加了不少网络负荷。
佳答案
读数据稍微有点迟缓不要太放心上，也未必是漏洞。可能它扫描是按成千上万个标签来的吧，可能还要处理扫描不成功的信号处理，如果过于强调读数据的实时性可能要大大加重opc运行负荷了。但写入数据得立即响应，要是写入不能立即响应那得小心了。
