HDA Async AdviseRaw or AdviseProcessed|Classic OPC: DA, A&E, HDA, XML-DA, etc.|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
HDA Async AdviseRaw or AdviseProcessed
Avatar
Bill Graham
Member
Members
Forum Posts: 3
Member Since:
08/18/2016
sp_UserOfflineSmall Offline
1
12/04/2019 - 07:55
sp_Permalink sp_Print

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.

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
12/05/2019 - 20:37
sp_Permalink sp_Print

You need to read the OPC Classic HDA specification.

I suspect those methods are just part of the async calling pattern which means you should never expect more than one callback.

To do what you need look for the Playback interface/methods.

Avatar
Bill Graham
Member
Members
Forum Posts: 3
Member Since:
08/18/2016
sp_UserOfflineSmall Offline
3
12/20/2019 - 01:30
sp_Permalink sp_Print

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 🙂

Avatar
Randy Armstrong
Admin
Forum Posts: 1451
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
4
12/20/2019 - 05:59
sp_Permalink sp_Print

It is possible that the servers you are trying to use do not implement the specification correctly.

A NULL value means 'unspecified'.

Avatar
Bill Graham
Member
Members
Forum Posts: 3
Member Since:
08/18/2016
sp_UserOfflineSmall Offline
5
12/20/2019 - 08:20
sp_Permalink sp_Print

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 ?

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 17
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1351
Posts: 4579