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 and 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.