你是否需要根据某些预定义的变量或条件将特定过程数据记录到数据库或文本文件中?我们通常将此概念称为“条件”或“基于条件”的日志记录。这听起来很简单,但如果没有计划,那么实施起来可能是一项棘手的任务。
在这篇文章中,我将向你介绍条件数据记录所涉及的注意事项,并介绍如何轻松设置 OPC DataLogger 以根据各种条件记录数据,而不会带来太多麻烦。
现在请考虑以下情形:你的任务是从生产线中创建区块来收集重量信息。
当这些区块中的每一个通过传送带移动时,它将通过检重秤,该检重秤将当前重量发送到正在运行该线的PLC,并且当块穿过秤的前缘时,视觉系统读取区块的条形码允许权重与正确的区块相关联。
你现在的任务是为每个区块记录一个权重,将其与正确的序列号相关联,并将其作为一行记录到SQL数据库中。听起来不是那么难吧?
那你怎么来设置这个呢?
当然,有可能在PLC中对此进行编码。但是,这是一个OEM线路安装,我们无法访问PLC代码。
那么,我们可以在OPC服务器中设置扫描速率,以便不经常轮询PLC,使得我们可能不能获得单个块的多个权重值。但是当线路停止时会发生什么?你是否需要在重新启动后将服务器扫描速率与线路重新同步?如果线速度改变怎么办?
听起来这对于需要长期维持的人而言会是一个巨大的麻烦,对于我们这些已经有长串责任清单的人来说,绝对是不太理想的。
实际上,我使用过的大多数系统都只是连续地记录值,并且使用一些“Macgyvered”解决方案,然后从数据库中选择正确的值。虽然这种方法没有任何内在错误,但它不仅使用了更多的数据库空间,而且还需要进行大量修剪才能将数据降低到你实际感兴趣的值。
那么什么是更好的替代方案呢?接下来,我将逐步介绍使用 OPC DataLogger 的条件记录来处理这种情况是多么容易。
尽管我非常熟悉 OPC Data Logger,但我仍然使用项目向导来配置我的日志项目,直到今天,为了使这篇文章完全只是对向导的逐步解释,我的例子将假定存在使用默认设置的基本项目。
在单步向导并保持默认值后,查看关键组件的存在:
1.我配置了一个指向我的OPC服务器的数据收集器:
2.我有一个配置了单个组的日志记录任务,已经添加了我感兴趣的两个OPC标记。当前的 BlockWeight(区块重量)和相应的 SerialNumber(序列号)如下:
现在,我们将把 Group 的 Read 类型保留为 Subscription - 这是默认的 - 但我们稍后会再回过头来看看。
3.日志记录被任务配置为将数据记录到我的SQL数据库:
此时,我们有一个工作的OPC Data Logger项目,如果我们进入运行时,将每隔250ms检查一次权重和序列号标记,并在任何一个值更改时记录这两个值。
然而,这将捕捉到我们不感兴趣的各种数据,包括区块在部分检查秤上的重量信息 - 重量数据对我们来说几乎无用。因此,这是我们得到等式的条件部分,并在你需要时仅记录你需要的部分。
1.让我们首先添加我们将用于驱动实际日志记录的触发器。这将是一个受监控的项目触发器:
2.此触发器将配置为监视我们的OPC服务器中的 Boolean tag(布尔标记) - weighReady - 当区块完全位于检重秤上时,预计会变高:
这可以是传感器或类似的外围设备,用于测量区块完全越过检重秤的前沿时的数据。关键是Monitored Trigger配置为在此Boolean tag(布尔标记)变为高(1 / True)时触发。
3.回到我承诺将要重新访问的 Group Properties 中的 Read 选项卡,让我们将 Read 类型从 Subscription 更改为 Asynchronous Triggered Reads:
类似地,在Triggers选项卡上,我们现在想要添加我们配置的Monitored Trigger,并指定Effect是“One-shot Read Now”,即当触发器变高时,我们应该读取并记录组中的每个标记一次:
此时,我们的配置已完成了。在运行时,这个OPC Data Logger项目将处于空闲状态,直到 WeighReady 位变为高为止,此时我们将从OPC服务器(从PLC读取数据)中检索当前的序列号和重量,我们将记录一个我们的SQL数据库。
随着它越来越容易获取数据,你可以更轻松地访问你在流程中,甚至是企业级别可能会需要的任何数据。我们注意到应用程序实际需要的数据变得越来越重要。整理成千上万的标签只是为了找到一个或两个具有统计意义的标签通常比手动记录的更低效。
对于毫秒通常意味着节省或损失数万,数十万甚至数百万元之间的差异的行业,在正确的时间获得正确的数据至关重要。你已经看到了如何以最小的努力,使用条件日志与 OPC Data Logger配置起来非常容易,,以确保你只需在需要时收集所需的数据。