• RE: Trouble communicating with DAQ6510 using TSP and PyVISA

    Hi Andrea, thank you for your reply.

    I think there were two problems at play here, one of them you identified when you said "The instrument can accept only one connection at a time," of which I was not aware.

    I was using Test Script Builder interactively to do a sanity-check of my TSP commands, but was leaving it running so that explains why I could no longer communicate after starting TSB.

    My underlying problem -- the reason why my Python script was not working in the first place, was I think due to a quirk with TSP when running over PyVISA. Please confirm my suspicion here, but I think that this line of code will not work:
     
    my_instr.query('dmm.measure.read()')

    The code above causes a timeout for me (my original problem). This however does work:
     
    my_instr.query('print(dmm.measure.read())')

    The subtle distinction being that TSP print(...) produces something on stdout which I suppose is captured and returned by the query() command, but dmm.measure.read() does not produce anything on stdout. So that I and maybe others aren't tripped up by this in the future, can you advise what TSP statements can be used with VISA query(), other than print(..) ?


    Thanks in advance,
    Richard



     
  • RE: Trouble communicating with DAQ6510 using TSP and PyVISA

    Update/clarification (editing my previous post seems to destroy the formatting):

    The VISA resource string I use in the open_resource() call is the same one reported by list_resources(). This is also the same string that I have been passing to Test Script Builder, it works there.

    Also, the DAQ6510 is configured for TSP (not SCPI) I have double-checked that.
  • Trouble communicating with DAQ6510 using TSP and PyVISA

    I am having trouble communicating with my DAQ6510 over Ethernet, using PyVISA and TSP. I'm using Python to establish a connection with the 6510 and execute one command:
     
    import pyvisa
    resource_mgr = pyvisa.ResourceManager()
    print(resource_mgr.list_resources())
    
    my_instr = resource_mgr.open_resource("TCPIP0::192.168.10.121::inst0::INSTR")
    
    # my_instr.query('dmm.measure.read()')
    my_instr.write('dmm.measure.read()')
    The open_resource() call fails with a timeout:
     
    pyvisa.errors.VisaIOError: VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.

    Pinging the 6510 works fine, and using Test Script Builder works fine as well. I can send commands with Test Script Builder interactively and also run scripts from the IDE, this all works fine.

    I don't have a lot of experience with PyVISA, I am essentially following the Tek app note titled "How to Write Scripts for Test Script Processing (TSP)". In that app note they claim to be using PyVISA in the example code but actually import "visa" (a module for the credit card institution) which has nothing to do with PyVISA so I am assuming that was a typo and "pyvisa" is the library that I should be using. 

    The 6510 is the only TSP-enabled instrument that I have available so I can't try this with anything else.

    Does anyone have any ideas what could be going wrong here?
     
  • RE: Measuring duty cycle with the DAQ6510

    Thank you Bradley for your very insightful suggestions. It had never occurred to me to take a series of measurements and then post-process to look for a trigger condition. Working with the DAQ6510, with its powerful on-instrument processing, takes some getting used to and causes us to rethink our old ways of doing things.

    I tried a solution similar to what you suggested, basically a digitized acquisition of X measurements and then analyzed them looking for positive pulses which then gave me the pulse widths I needed. I didn't use the limits/statuses as you suggested, mostly because I was not familiar with those at all, instead I just examined the reading values directly. I found the post-processing of 1M points did take some time (~7 seconds) which was longer than I'd expected but not a problem in this application because I'm just scanning temperatures.

    As a exercise I went a bit further and experimented with using the trigger model as you hinted at, but this didn't really help with the processing time as I still needed to iterate through the readings array to find the edges. (I used "LoopUntilEvent" with a rising edge condition.) Since I knew beforehand the width of the pulse(s) I could reduce the sample count to much less than 1M and this sped things up considerably, to around 25ms which makes this solution feasible for future use on scanning other signal types beyond slowly changing temperatures.

    Thank you very much for your suggestions, and if you do think of any ways to employ the trigger model I'd love to hear about them!
     

  • Measuring duty cycle with the DAQ6510

    I would like to know the best approach(es) for measuring the duty cycle of a PWM signal with the DAQ6510. I realize that the 6510 is not the ideal instrument for this task, but nonetheless I would like to better understand the programming/trigger capabilities of the 6510 and how they might be used to solve this type of problem.

    The signal in question is a 1 kHz PWM (0 -> 3.3 V), and I don’t need high accuracy, +/- 1% would be sufficient. Ideally this would be a TSP script that I can call up from the front panel of the instrument.

    Ultimately, if this is possible then my “final application” would be to use duty-cycle as a Trigger to start a scan of some rear-panel (multiplexed) input channels. For example, wait for the duty-cycle on channel 101 to be >= 80% and then initiate a scan of channels 102-105.

    Does anyone have any ideas how to go about solving this task?