scopes device server improve (III)

Again, new commit (r2509) to the tango-ds svn. This have some improvement more, trying to alow the user to do what they want, but with some reliability about it.

The initial design when many attributes (read_attributes([]))was requested at the same time, they was Ask() to the lower level device PyVisa, one by one. And this means one query per attribute:

On the last improvement, the device does one query to the instrument when many things are requested at the same time:

But with this, the issue is when you use a small scope (and I mean small, one with a small embedded system inside) some types of measurements block the instrument. When this multiple request is too big for this scope, a time out occurs. But for a bigger scope this can be not a problem, or the problem in a different number of multiple requests.

What has been committed today add a new attribute ('QueryWindow') to the device class to group this multiple query in smaller requests. Then configuring it, this allows to query one by one, in a really small scope; or all at the same time if the scope can support it. The image of the design can be:

Also another attribute has been introduced ('TimeStampsThreshold'). Even if the requests are grouped or not, if the client starts with many requests of the same value too often, the problem is shown again. Only requesting one attribute, but 10 times per second, depending on the scope can be an issue or not.

The solution I propose is cache values, with an attribute saying expiration time of the value. This means, when the client likes to read a value that has been never before read, this will be included in the list of attribute to read. When the answer is back, the data is saved with the time stamp of when it was read.

Some time in the future, the client can ask again for this value. This could happen 100ms after the first read, or 10minutes. The device will check the time stamps of the last read, and if it is too old, this will be read like in the case before. But if this is too short, the answer will be the previous value, and the tango attribute will have the time stamp of when this was read. This last part is really important to avoid confusion to the user: if the value is from the past, the user should be able the realize that. Also if more than one client request values to the device, this doesn't increase the number of hardware reads if they are asking the same thing.

I hope with this changes, the usage of this device class will be better. We will see if something has to be change, and I'm open to other ways to solve this.

Update (2010/12/21): commit 2510

• When a measurement is not possible, incomplete or stopped, the result is 9.99999e+37. Before this triggers an exception, but is better to returns NaN.
• Fix the dictionary set for the cache on the start up
• Add a filter for the spectrums attributes
• After a time out the PyVisa goes back to its default value, check it before ask to it.

Update (2010/12/22): commit 2511

• Bug fix in the group method. It cuts the last elements if they wasn't in the same length of the cut. ex: group([1,2,3,4],3) was excluding the last incomplete element, now it is returning [(1, 2, 3), (4,)].
• Reduce the filters to one iteration instead of one per filter.