# 8 years ago

Sandor

Hi, could you please help how to read attribute values directly from the device when polling is turned on? I've tried it in several ways for instance to use read_attribute with the green_mode=GreenMode.Synchronous argument, but didn't help. The Tango Manual (8.1) says it is possible to read directly from the device to avoid staled value coming from the polling buffer: "9.2.3 Reading data from the polling buffer For a polled command or a polled attribute, a client has three possibilities to get command result or attribute value (or the thrown exception) : • From the device itself • From the polling buffer • From the polling buffer first and from the device if data in the polling buffer are invalid or if the polling is badly configured. The choice is done during the command_inout CORBA operation by positioning one of the operation parameter." Our use case is the following: - we need polling turned on for the archiving - we execute a command which turns the device into operation mode - we try to check whether it is in operation mode reading one of its attributes - but the polling buffer stores the earlier state of the is_…_allowed call and raises an exception: It is currently not allowed to read attribute … - temporarily I changed the is_…_allowed to return always True, in this case we received the staled value - of course if we use a several second waiting before checking the attribute solves the problem, but using a synchronous command we expect a valid attribute value Thank you, Sandor

# 8 years ago

Andy

Hi Sandor, Tango devices indeed offer 3 possibilities for reading the source of data. The source is selected by setting the source using the appropriate API call : For example in Python dev.set_source(DevSource.DEV) will set the source of your values from this device as the device itself i.e. it will call the read_attribute() method to get the value(s) and ignore what has been stored in the cache as the result from the last polling request. All future calls to using that device proxy will then bypass the cache. To switch back to reading from the polling cache use: dev.set_source(DevSource.CACHE_DEV) Similar calls exist in C++ and Java and are documented in the manuals. Let me know if you need them too. Andy

# 8 years ago
Sandor	Hi Andy, thank you for your solution. It works perfectly Sandor

# 5 years ago

zreszela

Comming back to the attribute readout source. Could someone confirm my reasoning: CACHE_DEV - try to read from the polling cache and if the cache is empty e.g. no polling enabled, then fallback to read from the device CACHE - read from the polling cache and if the cache is empty then raise an exception DEV - always read from the device i.e. ignore polling cache I couldn't find it in the docs… Thanks in advance for your help!

# 5 years ago

Reynald

From what I understood, for CACHE_DEV, it will try to read it from CACHE and if this fails for a reason or another, it will then fallback to read from the device. The reason it fails could be that the cache is empty or that the value in the cache is too old (older than poll_old_factor * polling_period => API_NotUpdatedAnyMore DevFailed exception). For CACHE, I think you will get an exception as well if the last attribute value in the cache is too old too. DEV behaves as you described it. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 5 years ago
zreszela	Thanks for your answer Reynald! For those not familiar with the polling properties as poll_old_factor (as me until yesterday:) these are thorougly explained in: https://tango-controls.readthedocs.io/en/latest/development/advanced/reference.html#the-device-polling