This is an old revision of the document!
LagCorrectedQuery Class
The LagCorrectedQuery class uses a samplestream to search backwards in time to produce a single data-frame that includes lag-corrected values.
This allows you to easily create analytics that compare quality or deal with lag caused by the distance between different sensors along a line.
Functions
The class has the following functions…
Setup
Adding Subqueries
Running
Variables
The following member variables are available
| Name | Type | Usage |
|---|---|---|
| expected | int | Normal length of the lag when running (seconds) |
| maxtime | int | Maximum length of the search (seconds) |
| multiplier | float | Multiplier to be applied to the value in data-frame index |
| shavems | bool | When True, times are rounded to the nearest second |
Usage
The multiplier is usually used to convert the time-base of a rate. The class expects your rate to be per second, so if you wanted to use a per minute input time, you can set the multiplier to 0.016666.
The shavems option is useful if you want to simplify the data you're getting by eliminating sub-second results. This will effectively 'round up' your results so you have no more than one point per second.
Example
srv = ardiapi.Server('demo.optrix.com.au/s/pl') lcq = samplestream.LagCorrectedQuery(srv) lcq.RateLagQuery('Strip Meters',"'Paint Line' ASSET 'Speed - Actual' PROPERTY VALUES") lcq.AddQuery("'Finish Oven Zone 1' ASSET 'Temperature - Oven' PROPERTY VALUES") lcq.AddQuery("'Prime Oven Zone 1' ASSET 'Temperature - Oven' PROPERTY VALUES",lag=50) lcq.multiplier = 0.0166 lcq.shavems = True starttime = datetime.datetime.utcnow()-datetime.timedelta(seconds=60*60) endtime = datetime.datetime.utcnow() df = lcq.Execute(starttime,endtime,samples=3600)
In this case, we're going to ask for both the oven temperature and final colour on a cupcake-making machine. These two pieces of equipment are 50m apart from one-another (see the image later below). We want the values synchronised with the conveyor system, compensating for the lag between the two components.
lcq.RateLagQuery('Meters',"'Conveyor' ASSET 'Speed' PROPERTY VALUES")
This line tells the class that we are going to correct for lag based on the Speed property from our Conveyor. This is a rate of change, so we'll use the RateLagQuery function.
lcq.AddQuery("'Inspection Station' ASSET 'Darkness' PROPERTY VALUES")
This line adds a query for the 'darkness' of our cupcakes, measured at the Inspection Station. This station is at the end of our process, so we won't include a lag for it.
lcq.AddQuery("'Oven' ASSET 'Temperature' PROPERTY VALUES",lag=50)
This line adds another query, this time for the Oven. In this case, we've added a lag of '50' - the distance in meters between the the inspection station and the ovens.
We then send a request for the last hour of data.
In our results, we get the following…
| Meters | Inspection Darkness | Oven Temp |
|---|---|---|
| 0.0 | 60% | 132.1 |
| 1.2 | 62% | 132.0 |
| 2.4 | 61% | 131.9 |
| 3.6 | 55% | 120.2 |
| 4.8 | 60% | 131.7 |
| 6.0 | 62% | 131.6 |
You'll notice that you don't have a time index anymore in the resulting dataframe. Instead, you've got a total amount of whatever you're measuring as a rate or total (in this case, it's meters).
What It Means
Each of the values are synchronised - so when meters is 0, we're seeing the darkness and the oven temperature for Cupcake #1, even though those two points were measured minutes apart.
Looking at the data, you'll see a drop at 3.6m into our data. Both the darkness and oven temperature decreased.
If this was a normal query or trend, these two events would appear 5 minutes apart, making it awkward to clearly display that the issues are related.
But by compensating for the lag between components, our dataframe shows an extremely clear link between the drop in temperature and the quality of our cupcake.