Hello,
We are using at ESRF, some macro servers and since then we have observed that the implementation of the DevString Spectrum attributes of the Door device(s) are not clean. It is the same case for the attributes : output, error, debug, critical, info, warning.
The problem is that the door device pushes for these attributes only the last line of the String Spectrum where the attribute value is in fact the whole spectrum which can be several lines. This manner of doing leads to the problem that if one client reads and refreshes the attribute by synchronous reads (for example test device) it will display a string spectrum which is longer and longer. But if another client is getting refreshed by events it will only receive the last line (one single string) at each refresh step.
I understand it is done to simulate a sort of streaming on the output of the door device. But I think that it is not correct that we can get two completely different values for the SAME tango attribute depending on the connection mode event or synchronous reads. The value of one tango attribute should not be different depending on the manner we get it. It is even worse if one tries to turn on the tango polling for one or more of these attributes. For example if we turn on the polling for output attribute inside atkpanel we will see the value of the attribute switching from the whole spectrum to the last line and then back to whole spectrum ...etc. This is because the Tango generates the change / periodic events automatically when the polling is on so the client gets the tango automatic events and also the Macro Server pushed events ....
I suggest that in order to implement the "Streaming" for each door attribut, implement the corresponding door attrubute last line in a separate attribute and so double the number of door attributes : output, output-last-line, error, error-last-line, debug, debug-last-line ....etc
The first ones are spectrums (output, error, debug, ...etc) and the second ones are String (output-last-line, error-last-line, debug-last-line, ...etc). This way we keep the coherence of the value of the attributes no matter how they are read (synchonous or events).
Hi Faranguiss,
Many thanks for this complete report. In the near feature we will plan on how to introduce the changes that you propose. How urgent is this request for you?
Just to complete this, I explain other aspects of these attributes.
Cheers!
Last edit: Zbigniew Reszela 2016-01-26