Logging Only The Data You Need When You Need It

Do you need to log specific process data to a database or text file based on some predefined variable or condition? We typically refer to this concept as "conditional" or "condition-based" logging.  It sounds simple enough but without a plan, it can be a tricky task to implement.

In this post, I'll introduce you to the considerations involved with conditional data logging and cover how OPC Data Logger can easily be set up to log data based on a variety of conditions without a lot of headaches.

Consider the following scenario: you are tasked with collecting weight information from a production line creating blocks.

As each of these blocks is moved via a conveyor belt, it will pass over a checkweigher that sends the current weight to a PLC that is running the line, and a vision system reads the block's barcode as the block crosses the leading edge of the weigher allowing an association of the weight with the correct block.

Your task now is to record a single weight for each block, associate it with the correct serial number and log that as a row to a SQL database.  Doesn’t sound so bad right?

So how would you go about getting this set up?

There are ways to code this in the PLC, sure.  But say this is an OEM line installation where we don’t have access to the PLC code.

Well, then, we could set up the scan rate in an OPC server to poll the PLC infrequently enough to where we might (might being the key word) not get multiple weight values for a single block.  But what happens when the line is stopped?  Do you then need to resynchronize the server scan rate with the line after restarting?  What if the line speed changes?

It sounds like that would be a huge headache for someone to maintain long-term and, for those of us who already have a list of responsibilities a mile long, this would be less than ideal.

In reality, most systems I have worked with are simply logging values continuously, and have some "Macgyvered" solution that then picks the correct values from the database. While there is nothing inherently wrong with that approach, it not only uses more database space but requires significant pruning to get the data down to the values you are actually interested in.

So what is a better alternative for setting this up then? As I continue below, I'll lay out step-by-step how easy it is to handle this sort of scenario with conditional logging in OPC Data Logger.

Phase 1 – Setup a basic logging project

Despite being very familiar with the OPC Data Logger, I still use the project wizards to configure my logging projects even to this day and, in order to keep this post from completely being just a step-by-step explanation of the wizard, my example will assume that a basic project exists that uses the default settings.

To review the key components as they would exist after stepping through the wizards and keeping the defaults:

1. I have a Data Collector configured that is pointing at my OPC Server:
   
   
   
   
2. I have a single logging task configured with a single group, to which I have added the two OPC tags I am interested in logging. The current BlockWeight, and the corresponding SerialNumber:
   
   
   
   For now, we will keep the Read type of the Group as a Subscription – which is the default - but we will come back to this later.
   
   
3. The Logging Task is configured to log the data to my SQL database:
   
   

At this point, we have a working OPC Data Logger project that, if we went to runtime, would check the weight and serial number tags every 250ms, and would log both values whenever either value changed.

However this would capture all sorts of data that we are not interested in, including any weight information when a block is partially on the check weigher – weight data that is pretty much useless to us. So this is where we get to the conditional part of the equation and logging only what you need when you need it.

Phase 2 – Setting up a Monitored Item Trigger

1. Let’s start off by adding the trigger that we will be using to drive our actual logging. This will need to be a monitored item trigger:
   
   
   
   
2. This trigger will be configured to monitor a Boolean tag in our OPC Server – weighReady – which will be expected to go high when the block is fully on the checkweigher:
   
   
   
   This can be a sensor or similar peripheral that measures when the block has crossed entirely over the leading edge of the checkweigher. The key is that the Monitored Trigger is configured to fire when this Boolean tag goes high (1/True).
   
   
3. Going back to the Read tab in our Group Properties that I promised we would be revisiting, let’s change the Read type from Subscription to Asynchronous Triggered Reads:
   
   
   
   

Similarly on the Triggers Tab, we want to now add our configured Monitored Trigger, and specify that the Effect is a “One-shot Read Now” i.e. when the trigger goes high, we should read and log each tag in the group once:



So, at this point, our configuration is complete. At runtime, this OPC Data Logger project will sit idle until the WeighReady bit goes high, at which point we will retrieve the current serial number and weight from the OPC Server (which is reading the data from our PLC) and we will log a single row to our SQL Database.

As it continues to become easier and easier to get access to any data you could possibly want at a process or even an enterprise level, it becomes increasingly important to be mindful of what data we actually need for our application. Sorting through thousands of tags only to find the one or two that are statistically significant can often be less efficient than recording values manually.

For industries where milliseconds often can mean the difference between saving or losings thousands, hundreds of thousands or even millions of dollars, having the right data at the right time in the right place is critical.  You've seen how, with minimal effort, it's very easy to configure conditional logging with the OPC Data Logger to ensure you are only collecting the data you need when you need it.