Interface to adjust inst.query_delay in Lantz driver.

[rwalshEE]

I have left a lot of "Issues" here and in pyvisa (and pyvisa-py). Sorry about that, especially since it seems everyone here is pretty busy; I hope I don't seem unappreciative!

My latest issues is adjusting the delay between the read and write calls that query makes in the Lantz driver. Can this be "accessed" via Lantz? (In a straightforward way?) I've looked through the driver examples, and a fair amount of code here but have found nothing. I'm more of a hardware person, so that could be the reason, but I can usually figure software issues out as long as I don't have to "de-abstract" too much, and thus far my path as taken me all the way down to USBTMC piping (which is way over my level of expertise). Maybe more generally, how can pyvisa methods be extracted to be used in a Lantz driver (everything seems to rely on "query," which is instrument related, but the delay isn't...)?

Thanks again (again, again),

[PeterMintun]

I'm relatively new to using lantz, but I'll take a stab at this question...hopefully someone with some more experience can follow up on this.

First, can you give us more details about what instrument are you trying to control, and what code are you trying to use? That should give us a better idea on what sort of problems you might be having and what needs to be done to fix them.

If you're just trying to make a MessageBasedDriver (seems like what is most common), if you look at the implementation of the query method (pasted below), it simply does the read and write methods in a sequence:

def query(self, command, *, send_args=(None, None), recv_args=(None, None)):
        """Send query to the instrument and return the answer
        :param command: command to be sent to the instrument
        :type command: string
        :param send_args: (termination, encoding) to override class defaults
        :param recv_args: (termination, encoding) to override class defaults
        """

        self.write(command, *send_args)
        return self.read(*recv_args)

You can access these read and write methods separately, they are defined later on in messagebased.py

    def write(self, command, termination=None, encoding=None):
        """Send command to the instrument.
        :param command: command to be sent to the instrument.
        :type command: string.
        :param termination: termination character to override class defined
                            default.
        :param encoding: encoding to transform string to bytes to override class
                         defined default.
        :return: number of bytes sent.
        """
        self.log_debug('Writing {!r}', command)
        return self.resource.write(command, termination, encoding)

    def read(self, termination=None, encoding=None):
        """Receive string from instrument.
        :param termination: termination character (overrides class default)
        :type termination: str
        :param encoding: encoding to transform bytes to string (overrides class default)
        :return: string encoded from received bytes
        """
        ret =  self.resource.read(termination, encoding)
        self.log_debug('Read {!r}', ret)
        return ret

So if I'm understanding your question correctly, couldn't you just define your own function along these lines?

def delayed_query(self, delay_time):
    self.write('IDN?')
    sleep(delay_time)
    result = self.read()
    ...

[rwalshEE]

Thanks for the response, PeterMintun. I'm trying to remotely control a Keithley 2100 DMM; I'll post some code later if needed (see below).

I think your example would work; I'd say I'm a good "script-er", but but mediocre programmer, and forgot about inheritance. I did, at one point, try a "self.write" somewhere but it errored. I don't recall the circumstances, nor implementation, but I'll see if I can regenerate it. Before that, though, I have a question about purpose, that might answer things in a bigger picture way.

First, I know that Lantz is fairly new, so these observations might be a consequence of that. I'm also probably too inexperience to see the benefits of some things, so please replace any indications of indignation with ignorance :o)

So, I know Lantz does the code-to-GUI magic (though I didn't have any luck with it); using units is pretty cool, as are the limits, etc., and the "previous state" storage seems useful, but it seems a driver could be made with just pyVISA, though without the "@Feats," "@DictFeats," etc. I know those add the previously mentioned bells and whistles, but 95% of the objective (of controlling an instrument/getting data) wouldn't absolutely need those (or they could be coded directly). I suspect with multiple instruments these features become more useful (I'm only using one), but in that case, service requests would likely be necessary, and I have not been able to get them to work (even with just pyVISA, using both pyVISA-py and NI-VISA). Again, I suspect it's my limited understanding of how, e.g., "pipe transfers" and such work, but that brings me back around to the benefits of using Lantz. If I take the approach you suggested above, what is the benefit, versus setting "inst.query_delay" with pyVISA and calling "inst.query("blah")"? I know without my code to go off of, the example you gave is just that, an example, but in a more general sense, more variables would need to be passed in (for the string to be sent) or I would have to use ".write()" and ".read()" in all of the methods of the driver, which means ".query()" would never be used, even though read-the-docs says that's the primary way to communicate. I also see issues with variable delay_times that are solved in pyVISA by passing in an argument to override the default for that one command. So, basically, it seems using the driver is more difficult than using pyVISA directly. I'm sure I'm missing some aspect of the "big-picture" here, and want to reiterate I know Lantz is pretty young, but this seems kind of weird and counter intuitive.

I don't want to change the topic of my original post, but my real end goal is to be able to use service requests (and the query_delay issue is the first hurdle I need to overcome in order to build on a solid foundation), so if I wanted to implement that, I would need to do something similar to what you did above (accessing the MessageBasedDriver methods) but for something like "wait_for_srq()" (which doesn't yet seem implemented for USB in the pyVISA code). I'll try to keep this quick (especially since this should be in the pyVISA GIT section), but looking in pyvisa/highlevel.py, it looks like even "usb_control_in" would raise a "NotImplementedError" but in /pyvisa/resource/usb.py it looks like it IS implemented. I think there are modules calling modules calling modules and I'm a little lost...

Anyway, thank you again for the response. I can't get to testing it out today, but I think it will do what I need it to.

PS what would an alternative to the "MessageBasedDriver"? I thought that was the only way to go, but you said it was only the most popular...