====Discrete Data in ARDI Queries====

Discrete data - such as integer and boolean (ie 'on'/'off') values are treated differently in ARDI.

It is important for ARDI to understand the status of a system at //any time//. This means that when we request history, we need values that make sense.

When requesting history, we use the [[grain|grain]] and [[gethistory_method|method]] of your request control the resolution of the data you get back. This means that - unless you specifically ask for maximum-resolution data - some points will be averaged.

But averaging //doesn't make sense// for discrete data. 

As an example, let's look at the value lookup table for the **Mode** for a **Motor** shown below...

^Code^Meaning^
|0|Offline|
|1|Waiting|
|2|Stopping|
|3|Starting|
|4|Running|
|5|Warning|
|10|Error|

If you allowed averaging and asked for this point over time, you'd get figures like '2.28' - which are **completely useless**.

===Raw Discrete Values===

This is why ARDI **always requests discrete channels as raw values**. It means that...

==Values are Always Meaningful==

If you go to any point in time using ARDI, you'll get the current state of the device(s) rather than useless averaged data.

==Analytic Accuracy==
Since the time-stamps are as precise as possible, you can accurately calculate the times spent in and out of specific states

There are some impacts of this behaviour though....

==Query Performance==
There **can be** a performance impact - but in some cases, it's actually a **positive** one. Discrete channels change //much// less often than analogue channels, which means that in many cases there are fewer samples that need to be read. \\

==Sample Spacing==
Requests for ARDI data - particularly in tables - can't guarantee evenly-spaced samples. Mixing analogue and discrete channels in the one query will make the number of samples (and the time between them) erratic.