Missing 'P' value when retrieving data via PI OPC DA Server to a 3rd party system

Does the PI point in question have "step" enabled (PI point attribute step=1)?

This means that the PI server would plot the data in the PI point as a "stepped line", or "staircase plot". It could be that this is enabled, and the users are used to seeing this representation of the data in PI.

For example, if the values are 1, 2, 3, 4, 5 then you can draw a plot where this is stepped, or simply a straight line from 1 to 5 (interpolated).

How this data is visualised depends on the client, so that may be the problem.

If not, comparing the values that PI has for this PI point in the snapshot compared to what the OPC client receives will tell you if you're missing any values. In which case, it may require an increase in the poll rate to ensure intermediate values are not missed.

Hi Mike, I appreciate your reply.

The 'step' attribute is also something I was reading up on, and it may be a good solution for this use case in particular.

As far as missing values, I have compared values in the 'local' PI Archive to what is being forwarded and stored elsewhere through the PI OPC DA Server, these 'P' values are missing. 

Think of it like a rotation (RPM) for example, it's not always on the high setting, so it idles at ~1.0 then when required the RPM jumps up to ~10.0 for a few minutes before then returning to ~1.0. And because the 'P' values are missing, the trends shows these angled interpolated lines from ~1.0 to ~10.0 and from ~10.0 to ~1.0 over the period, creating these 'VV - spikes' in the trend.

And if the 'P' values were present, there would also be a value just before the big jumps, so another around 1 at the bottom before the jump to 10 and another values around the 10 before jumping back down to 1.

As I said - I'm trying to work with them to get a better understanding of this connection in particular, I don't quite understand why these values are missing. Can only think of something in the nature of the internal PI workings does something that results in this behavior.

Okay, if the data exhibits the same behaviour in PI - i.e. you get an interpolated slope when the values jump from 1 to 10 and back - then you need to look at a few things that can result in this.

PI, by default, will interpolate between events stored in the archive. Very generally speaking, it optimises storage of events by discarding intermediate events that fall on that interpolated slope. For example, if you have the values 1, 2, 3, 4, 5 then you can recreated the same trend by only storing 1 and 5, then interpolating 2,3, and 4 along that line. (This is a simplification of what actually happens).

Therefore, if PI stores only 1 and 10 there will be an sloped line drawn from 1 to 10 over whatever period of time that the timestamps associated with 1 and 10 are. And the same from 10 to 1.

The step attribute changes how the data is reported by PI. Enabling step will mean that PI will return the previous value from the requested timestamp, not an interpolated value.

If I request data half way between a value of 1 and 10 I'd get 5 (step off) or 1 (step on). I hope this is clear. On the downward trend, if I request data half way through the time-frame from 10 to 1 then I get 5 again (step off) or 10 (step on).

Enabling step may be your resolution, but be aware this means ALL data for this point will be stepped and it will never have a sloped trend line between two data points.

The other consideration is what data is made available to PI and how it is collected. Here is where I need to make some generalisations, or assumptions without knowing the data source/data collection components/parameters. However, the key is that PI can only collect and store data that is presented to it. If the data is 1, 1, 1, 10, 10, 10, 1, 1 then this can appear like a stepped trend if the difference in time between 1 and 10, and 10 and 1 is small enough. It will still be an interpolated slope, but with a short enough time-frame the slope will be near vertical. (But not quite vertical).

We have decided to try and test the step functionality for this tag only and see if that satisfies the use case.

But just a little correction, the  source PI system handles this just fine, it is only when trying to retrieve that data out of the PI system through the PI OPC DA server and in to Ignition. 

Looking at the data in PI: 

Representing the time as spaces.

1          1  2          2  1   

So a change in value will include the latest previous '1' and the change to 1 will include the latest previous '2' 

The data received through the PI OPC DA Server looks like this:

1              2              1

I hope that makes sense.

"Looking at the data in PI" < are you looking at a trend, or at archive values? Archive values 1     2    1 with step will look like 1   12  21.

OPC DA is current values only (HDA is history), so PI would pass through the values it has in its snapshot - which may well be 1   2   1.

This is what I meant when I said that the client showing the data has a direct impact on how the data is represented in a trend.

Let me know how the test goes.

"Looking at the data in PI" < are you looking at a trend, or at archive values? Archive values 1     2    1 with step will look like 1   12  21.

OPC DA is current values only (HDA is history), so PI would pass through the values it has in its snapshot - which may well be 1   2   1.

This is what I meant when I said that the client showing the data has a direct impact on how the data is represented in a trend.

Let me know how the test goes.

"are you looking at a trend, or at archive values?"   I'm looking at archived values.

And yes, I just got a report that the step functionality will satisfy the use-case, so we will go with that for now. Obviously it would be nice to have a clear root cause of why the 'previous' values are not forwarded.

Thank you for your input Mike.