Externally updated attributes and polling

In a device attribute that implements and its own change event pushes it seems appropriate to disable polling since clients could just subscribe to change events to get all attribute updates as they occur. E.g. the one I discussed here:
(http://www.tango-controls.org/community/forums/c/development/python/device-with-externally-updated-attributes/?page=1#post-1160,
http://stackoverflow.com/questions/35460896/pytango-device-with-externally-updated-attributes/)

However, let's say there is a requirement to have a periodic events occurring at a low rate? I thought I could handle that by also adding polling with a long period to the attribute. This has the desired result: a client can subscribe to EventType.CHANGE_EVENT to get the attribute updates as they occur, or EventType.PERIODIC_EVENT if periodic events (even the attribute value is unchanged) are desired.

The problem here is that once polling is enabled Tango seems to cache the last polled value. That means a client querying the attribute will get stale data if the value was updated since the last poll. I think this also means late joiners to the CHANGE_EVENT will receive a stale initial sample.

Is there some way the poll cache can be updated by update_loop() thread?

P.S. a nice side effect of the caching when using PyTango is that client queries are presumably kept away from the relatively slow Boost Python C++ callback mechanism. Am I correct?
Hi Nellen,
you're right, the polling mechanism has been designed in order to be the source of the cache too. This means that clients will get values from the polling buffer (the cache) as a default when polling is enabled. Clients could change this, specifying DEVICE as source, but I wouldn't recommend it as default. You can, nevertheless, mitigate the side effect using a shorter polling period for the Attribute and still specifying the desired period for the PERIODIC_EVENT.
Otherwise you should consider pushing the PERIODIC_EVENT by code too.
Hi Nellen
I was about to answer the same thing but Lorenzo was faster than me!
To complete the answer, as Lorenzo said, I suggest to do fast polling (e.g. 1 sec) to allow any client to see nearly live data by default.
If you need specifically a very low periodic event for particular use, you may fall in contradictory needs.
for instance, if you specify the periodic event to 10 sec, all you clients (ATK or Taurus) will only be refreshed once every 10 sec.
The best would be to keep fast polling and fast periodic event and to use the archive_event for your particular slow client. The archive event can be specified as periodic and will not impact other clients.
Cheers
Jean-Michel
Edited 8 years ago
Lorenzo, Jean-Michel

Thanks for the feedback.

lorenzo
Otherwise you should consider pushing the PERIODIC_EVENT by code too.

Presumably this would result in the periodic updates not really being periodic? :)

In any case, I think the solutions proposed are fine. This was more of a what-if kind of question in any case.

Best Regards
Neilen
Hello all,

I have just an additional information about Taurus. For the moment Taurus does not subscribe to events different than: CHANGE_EVENT and ATTR_CONF_EVENT. Taurus implements its own polling mechanism (by default every 3 seconds frequency) which executes the asynchronous reads of the attributes. We could also subscribe to the PERIODIC events if the Community requires that.

Cheers,
Zibi
 
Register or login to create to post a reply.