08/18/2016
I have a Classic OPC Client written in C++ but I only seem to get a response to my Async AdviseRaw or AdviseProcessed calls once. If I poll these calls I consistently get the correct response in my Sink callback function but I cannot call it once and periodically receive the results until the cancel is issued as I expect it should work.
Can anybody please advise on why might be happening. I have 2 threads and I am using static instances of my classes for the test. Using Alarm and Event calls in the same project works correctly with the events arriving as expected but for HDA I only get the response once after each call.
Any help would be appreciated.
08/18/2016
Thanks for the response Randy, I have read the spec and it says
The request will be for all data from the htStartTime into the future, as it is collected, reported at the rate specified by the ftUpdateInterval. Reporting will continue until the request is canceled. Caution should be used in specifying start times prior to the present, as data which is already available will be returned unthrottled, with ftUpdateInterval worth of data in each response. Once all data which has already been collected has been sent, new data will be sent for every ftUpdateInterval.
Your suggestion to use the PlayBack method is interesting. How do you provide an unspecified end time to this call ? The spec says :-
If htEndTime is not specified, the request shall be for all data from the htStartTime for the requested number of values. Then further data shall be sent according to the ftUpdateDuration and ftUpdateInterval from the time of the last value returned.
I I pass NULL or an OPCHDA_Time pointing to NULL or a zero FileTime or even specify the BString option and pass an empty string I get invalid parameter. How should this work please ? If start and end are specified it keep getting callbacks with the last value for endtime. Not very useful 🙂
08/18/2016
I can see what this is doing now. Based on the number of items passed into the call (dwNumItems) it fixes the end of the time window using the interval. Once this buffer is used up I just get the lastest value to my callback for that time repeated for ever until cancelled. Why ? Hopefully this is not standard behaviour for all OPC Servers and is a poor vendor implementation.
Has anybody got experience of using this please ?
1 Guest(s)