Log In
Home
04/14/2020
Offline
Hello,
I am trying to clarify a point from the spec regarding Historical Access Read Raw functionality.
From OPC 10000-11 6.4.3.2 Read raw functionality:
“If a startTime, endTime and numValuesPerNode are all provided and if more than numValuesPerNode values exist within that time range for a given Node then only numValuesPerNode values per Node shall be returned along with a continuationPoint.”
Regarding the case where only startTime and numValuesPerNode are specified: I’m trying to disambiguate whether the response should contain a continuation point if more than numValuesPerNode exist past the startTime, or if returning numValuesPerNode is considered complete and no continuation point is required. My thinking is that if a client wanted to start from some point in time, and read forward indefinitely, in chunks of ‘numValuesPerNode’, they could keep calling back with the continuation point. But the spec only specifies the case above where all 3 (start, end, nuValues) are provided, implying by omission that you would not return a continuation point in the case where start and numValues are provided.
Just want to confirm I’m interpreting as intended.
04/01/2014
Offline
The expectation is that numValuesPerNode would be returned with a continuation point. A client wanting to query additional values would use the continuation point to continue to retrieve numValuesPerNode values until all existing values have been returned.
Rod Stein Manager of Technology Matrikon OPC http://www.matrikonopc.com
07/05/2017
Offline
The read raw is defined to allow for different use cases. It requires 2 of the three parameters. If you provide all three you will or could get a continuation point if more values exist between startTime and endTime then numValuesPerNode. If you provide two parameter, startTime and numValuesPerNode, then it will start at the startTime and return up to numValuesPerNode. if NumValuePerNode fits in a single response then no coninuation point. The response might not fit numValuePerNode for all nodes and thus you can get a continuation point. If you provided endTime and numValuePerNode then you get list order differently. If you provide startTime and EndTime, depending on the number of values and the size of your message buffer you might get a continuation point.
The key difference between startTime and endTime with and without numValuesPerNode is how many value end up in the return bucket. A client might say that it can only handle 5 values at a time and thus presenting a numValuesPerNode would restrict what is returned, instead of the message size being the limit.
04/14/2020
Offline
Paul, and Rod, thank you for your responses. It sounds like there is disagreement on the interpretation. I thought the spec was somewhat ambiguous on this point, which was why I was asking. It seems like it could be interpreted either way.
I was leaning toward the meaning that Paul describes, because the spec explicitly calls out the continuation point in the case that all 3 parameters are provided, but doesn’t address the others. I assumed that meant that those open-ended cases don’t get a continuation point (once the full numValuesPerNode is returned, of course, there could always be a continuationpoint returned before that point).
Although, from a client perspective, I prefer the interpretation that Rod presents as that seems more user-friendly. The client could continuously call back with a continuationPoint to keep reading forward (or backward) in time without needing to determine the new startTime. You can always just use the last value’s timestamp as the next startTime, but then you’d get back a duplicate of that value again in the next read and your client would need to account for that.
05/30/2017
Offline
ContinuationPoints are used to indicate that data that meets the criteria provided exists but could not be returned.
If only two criteria are provided then the request is fulfilled when both are met. Hence no ContinuationPoint.
If three are provided then a ContinuationPoint is returned if numValuesPerNode is met but not EndTime.
The use case where a client wants to keep reading data in numValuesPerNode blocks could be met easily by specifying an EndTime far in the future. So having no ContinuationPoint when an EndTime is not provided is not a limitation and may be useful to Clients that only want a block of data.
Created a Mantis issue:
https://apps.opcfoundation.org…..hp?id=6458
1 Guest(s)
Usage Policy