Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting a set-only parameter #46

Closed
AdriaanRol opened this issue Feb 25, 2016 · 8 comments
Closed

getting a set-only parameter #46

AdriaanRol opened this issue Feb 25, 2016 · 8 comments

Comments

@AdriaanRol
Copy link
Contributor

Even though it is something we absolutely want to avoid there sometimes are instruments that only have set-commands, in this case I want the get command to return the value that was last set.

It is now already possible to extract the last set value by using the snapshot, however that does not make the interface the same when using it like any other parameter in some higher level script.

To give an example I have added a screenshot below of me running into this problem when developing a driver for an instrument where get-functionality has not yet been implemented.
image

The syntax I would propose would be something along the lines of

self.add_parameter('name', set_cmd='set_string{}', get_cmd=soft_get 

where soft get is either a reserved keyword (bad idea IMO), an importable function or code or some other object.

For now I'll just settle for the dirty hack of adding it in by hand.
EDIT: making get return _last_value explicitly

@alexcjohnson
Copy link
Contributor

My main concern here is that users know when they're asking for a soft_get instead of a real reading, even if they're not the driver authors.

When do you think this functionality will be useful?

  • just as a one-off "remind me what I set this to"
    • then we could make a method like .latest() or something, that as you say just returns self._last_value
  • or can you see cases for using this in a Loop? I guess here's one: if you've got some other high-level parameter that includes a feedback loop, and elsewhere in the loop you want to store the feedback setting...
    • we can make a really simple object that wraps any parameter, just overriding get, so that it can be used in a Loop.

Actually, I bet the only thing a user has to see is .latest, used as a function as in the first case, or without calling it you have an object that can be a Loop action:

class StandardParameter(...):
    def __init__(self):
        ...
        self.latest = GetLatest(self)
        ...

class GetLatest(DelegateAttributes):
    delegate_attr_objects = ['parameter']

    def __init__(self, parameter):
        self.parameter = parameter

    def get(self):
        return self.parameter._last_value

    def __call__(self):
        return self.get()

Seem reasonable? Any other ideas what to call this thing?

@alexcjohnson
Copy link
Contributor

Small change, if I first standardize the names of stored values between StandardParameter and ManualParameter as discussed in #38 and #41 then we can plug this into Parameter rather than StandardParameter - of course in ManualParameter you wouldn't need this (it wouldn't hurt, it's doing exactly what .get() does there anyway...) but it would be nice to allow in other Parameter subclasses people might make.

@AdriaanRol
Copy link
Contributor Author

@alexcjohnson .

I definately like the idea of .latest() or .get_latest(). I think that would be a good addition.

However having .latest does not solve the problem I am having which relates to instruments that have a lacking communications protocol (and there are surprisingly many of them) In that case I would like it to be able to use the standard .get() function.

For the specific problem I am having now it is a VISA instrument so I would like my parameter to still be a visa instrument and just rerout parameter.get() to the proposed parameter.latest().

If we add this feature we should add a note on when to and when not to use this feature in the docstring that explains it, unless you see a better solution. (Maybe .latest() for every parameter?)

@alexcjohnson alexcjohnson mentioned this issue Feb 29, 2016
@alexcjohnson
Copy link
Contributor

However having .latest does not solve the problem I am having which relates to instruments that have a lacking communications protocol on (and there are surprisingly many of them) In that case I would like it to be able to use the standard .get() function.

I'm still not sure I get your point - you want to be able to use .get() exactly, or you just want to make sure there's always something available?

Maybe .latest() for every parameter?

That's what I was proposing above - if you just want to read this value out, you do:

myparam.latest()

and to put this as data into a loop:

Loop(...).each(myparam.latest)

@AdriaanRol
Copy link
Contributor Author

I'm still not sure I get your point - you want to be able to use .get() exactly, or you just want to make sure there's always something available?

Yes, I want to rerout .get() to .latest() in some very specific cased (i.e. if the hardware does not support get-functionality). In all other cases I am very happy with the addition of the .latest() method.

@AdriaanRol
Copy link
Contributor Author

@alexcjohnson
Actually on second thought, let's stick with having only the .latest() and no .get() in the case of soft-parameters. The only addition I propose is to have the NotImplementedError in the .get() refer to the .latest() explicitly so that the user will know immediately how to solve this.

@alexcjohnson
Copy link
Contributor

The only addition I propose is to have the NotImplementedError in the .get() refer to the .latest() explicitly so that the user will know immediately how to solve this.

Haha I was about to propose exactly that. Sold, I'll add it to #48

@alexcjohnson
Copy link
Contributor

closed by #48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants