Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision 		Previous revision
samplestream:class_lagcorrectedquery [2024/04/24 01:56]
optrix created 		samplestream:class_lagcorrectedquery [2024/04/25 23:46] (current)
optrix
Line 4: Line 4:
  
 This allows you to easily create analytics that compare quality or deal with lag caused by the distance between different sensors along a line. This allows you to easily create analytics that compare quality or deal with lag caused by the distance between different sensors along a line.
 +
 +Note that this function only works with [[simple lag|simple forms of lag]].
  
 ===Functions=== ===Functions===
Line 33: Line 35:
 ===Usage=== ===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.+You build up your query out of three main parts...
  
-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.+==Source of Lag==
  
-===Example===+First, you need a number that can be used to compensate for lag. This might be a distance, a flow-rate, a speed or some other **counter** or **rate** that can be used to see how much of a //thing// (other than time) has passed. This is called the [[source|source of lag]].
  
-{{cupcakelag.png}}+==End Asset==
  
-<code python>+Next, you'll choose an [[End Asset|end asset]]. This is usually the //last// part of your system. This is because the class only searches [[building backwards|backwards through time]] rather than forwards.
  
-srv = ardiapi.Server('demo.optrix.com.au/s/pl')+==Assets and Distances==
  
-lcq = samplestream.LagCorrectedQuery(srv) +Next, identify all of the individual pieces you'll want to add to the query, and how much [[distance|distance]] there is between them.
-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) +For example, if a conveyor moves through three different temperature sensors, you'd identify them and measure how far away they are from one-another.
-endtime = datetime.datetime.utcnow()+
  
-df = lcq.Execute(starttime,endtime,samples=3600) +===Additional Parameters===
-</code>+
  
-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.+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.
  
-   lcq.RateLagQuery('Meters',"'Conveyor' ASSET 'Speed' PROPERTY VALUES")+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.
  
-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. +===Example===
- +
-   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. +
  
 +[[example|See an example]]

ARDI

Welcome Guides

User Guides

Administrative

Sever
Other

API / SDK

Scripting

Addons / Drivers

Other Media