You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
We have already mentioned the case of write-only features for dumb instrument in the past. I just received a brand new RF signal generator which follows this paradigm even for very basic things like frequency, power, output state, etc (basically everything). Using only Action would be weird as it would mean it cannot follow the RFSigGen standard which it should follow. As I will have to interface it, I would love if we could reach a consensus about this.
The less intrusive option I can think of would be to mark the getter as being CACHE (cache being just a placeholder object) and make the Feature work as follow is the getter is CACHE :
return None if no cache value exists (it is the job of the user to be careful when using that instrument)
return the cache otherwise
The text was updated successfully, but these errors were encountered:
The way pymeasure handles this is by having 3 separate kinds of property factories, control, measurement, setting that return get/set, get-only and set-only properties, respectively.
The question popped up also because in Lantz we wanted Feature to cache their value. For the sake of uniformity and less surprise principle for the users, we wanted all Features to cache their value, always. As a consequence, we decided that things changing without any intervention on the instrument (such as measured values) would be handled through methods (wrapped in Action descriptor) (Of course here I am not considering exceptional failures such as a DC power source tripping its output).
The question then was what to do with write only parameters. I never got any answer, but I believe that the behavior I was suggesting is the one making the more sense.
Hi,
We have already mentioned the case of write-only features for dumb instrument in the past. I just received a brand new RF signal generator which follows this paradigm even for very basic things like frequency, power, output state, etc (basically everything). Using only Action would be weird as it would mean it cannot follow the RFSigGen standard which it should follow. As I will have to interface it, I would love if we could reach a consensus about this.
The less intrusive option I can think of would be to mark the getter as being CACHE (cache being just a placeholder object) and make the Feature work as follow is the getter is CACHE :
The text was updated successfully, but these errors were encountered: