Data acquisition

Discussion in 'Python' started by spintronic, Oct 25, 2011.

  1. spintronic

    spintronic Guest

    Dear friends,

    I have a trouble with understanding the following. I have a very short
    script (shown below) which works fine if I "run" step by step (or line
    by line) in Python shell (type the first line/command -> press Enter,
    etc.). I can get all numbers (actually, there are no numbers but a
    long string, but this is not a problem) I need from a device:

    '0.3345098119,0.01069121274,0.02111624694,0.03833379529,0.02462816409,0.0774275008,0.06554297421,0.07366750919,0.08122602002,0.004018369318,0.03508462415,0.04829900696,0.06383554085, ...'

    However, when I start very the same list of commands as a script, it
    gives me the following, which is certainly wrong:

    [0.0, 0.0, 0.0, 0.0, 0.0,...]

    Any ideas? Why there is a difference when I run the script or do it
    command by command?

    ===========================
    from visa import *

    mw = instrument("GPIB0::20::INSTR", timeout = None)

    mw.write("*RST")
    mw.write("CALC1:DATA? FDATA")

    a=mw.read()

    print a
    ===========================
    (That is really all!)


    PS In this case I use Python Enthought for Windows, but I am not an
    expert in Windows (I work usually in Linux but now I need to run this
    data acquisition under Windows).
     
    spintronic, Oct 25, 2011
    #1
    1. Advertising

  2. spintronic wrote:
    > Dear friends,
    >
    > I have a trouble with understanding the following. I have a very short
    > script (shown below) which works fine if I "run" step by step (or line
    > by line) in Python shell (type the first line/command -> press Enter,
    > etc.). I can get all numbers (actually, there are no numbers but a
    > long string, but this is not a problem) I need from a device:
    >
    > '0.3345098119,0.01069121274,0.02111624694,0.03833379529,0.02462816409,0.0774275008,0.06554297421,0.07366750919,0.08122602002,0.004018369318,0.03508462415,0.04829900696,0.06383554085, ...'
    >
    > However, when I start very the same list of commands as a script, it
    > gives me the following, which is certainly wrong:
    >
    > [0.0, 0.0, 0.0, 0.0, 0.0,...]
    >
    > Any ideas? Why there is a difference when I run the script or do it
    > command by command?
    >
    > ===========================
    > from visa import *
    >
    > mw = instrument("GPIB0::20::INSTR", timeout = None)
    >
    > mw.write("*RST")
    > mw.write("CALC1:DATA? FDATA")
    >
    > a=mw.read()
    >
    > print a
    > ===========================
    > (That is really all!)
    >
    >
    > PS In this case I use Python Enthought for Windows, but I am not an
    > expert in Windows (I work usually in Linux but now I need to run this
    > data acquisition under Windows).
    >


    Just in case you have a local installation of visa and it silently fails
    on some import,

    try to add at the begining of your script:
    import sys
    sys.path.append('')

    When using the python shell cmd line, '' is added to sys.path by the
    shell, that is one difference that can make relative imports fail in
    your script.

    If it's still not working, well, it means the problem is somewhere else.

    JM
     
    Jean-Michel Pichavant, Oct 25, 2011
    #2
    1. Advertising

  3. spintronic

    Nick Dokos Guest

    spintronic <> wrote:

    > Dear friends,
    >
    > I have a trouble with understanding the following. I have a very short
    > script (shown below) which works fine if I "run" step by step (or line
    > by line) in Python shell (type the first line/command -> press Enter,
    > etc.). I can get all numbers (actually, there are no numbers but a
    > long string, but this is not a problem) I need from a device:
    >
    > '0.3345098119,0.01069121274,0.02111624694,0.03833379529,0.02462816409,0.0774275008,0.06554297421,0.07366750919,0.08122602002,0.004018369318,0.03508462415,0.04829900696,0.06383554085, ...'
    >
    > However, when I start very the same list of commands as a script, it
    > gives me the following, which is certainly wrong:
    >
    > [0.0, 0.0, 0.0, 0.0, 0.0,...]
    >
    > Any ideas? Why there is a difference when I run the script or do it
    > command by command?
    >
    > ===========================
    > from visa import *
    >
    > mw = instrument("GPIB0::20::INSTR", timeout = None)
    >
    > mw.write("*RST")
    > mw.write("CALC1:DATA? FDATA")
    >
    > a=mw.read()
    >
    > print a
    > ===========================
    > (That is really all!)
    >
    >
    > PS In this case I use Python Enthought for Windows, but I am not an
    > expert in Windows (I work usually in Linux but now I need to run this
    > data acquisition under Windows).
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >


    Shot in the dark: could it be that you have to add delays to give the
    instrument time to adjust? When you do it from the python shell, line by
    line, there is a long delay between one line and the next.

    Nick
     
    Nick Dokos, Oct 25, 2011
    #3
  4. spintronic

    John Gordon Guest

    In <> spintronic <> writes:

    > Any ideas? Why there is a difference when I run the script or do it
    > command by command?


    Are you running the same python program in both cases?

    Are you in the same directory in both cases?

    Does PYTHONPATH and/or sys.path have the same value in both cases?

    Show us an exact transscript of both executions.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Oct 25, 2011
    #4
  5. spintronic

    spintronic Guest

    On Oct 25, 6:29 pm, Nick Dokos <> wrote:
    > Shot in the dark: could it be that you have to add delays to give the
    > instrument time to adjust? When you do it from the python shell, line by
    > line, there is a long delay between one line and the next.
    >
    > Nick


    Hi, Nick!

    Thanks! You are right but it was the first thing I thought about. So I
    have tried to delay using sleep(t) from the time module (I also sent
    "*OPC?" or "*WAI" commands to a device for synchronization). However,
    it does not help ...

    Best,
    AS
     
    spintronic, Oct 25, 2011
    #5
  6. spintronic

    spintronic Guest

    On Oct 25, 6:43 pm, John Gordon <> wrote:

    Thanks, John!

    > Are you running the same python program in both cases?


    Yes, the same.

    > Are you in the same directory in both cases?
    > Does PYTHONPATH and/or sys.path have the same value in both cases?


    It looks that yes but how can it matter? All I need it is to import
    the visa module and it works well.

    > Show us an exact transscript of both executions.


    There is nothing but "numbers". Or do you mean something else? I do
    not receive any errors, only different results ...

    Best,
    AS
     
    spintronic, Oct 25, 2011
    #6
  7. spintronic

    spintronic Guest

    On Oct 25, 6:15 pm, Jean-Michel Pichavant <>
    wrote:
    > spintronic wrote:
    > > Dear friends,

    >
    > > I have a trouble with understanding the following. I have a very short
    > > script (shown below) which works fine if I "run" step by step (or line
    > > by line) in Python shell (type the first line/command -> press Enter,
    > > etc.). I can get all numbers (actually, there are no numbers but a
    > > long string, but this is not a problem) I need from a device:

    >
    > > '0.3345098119,0.01069121274,0.02111624694,0.03833379529,0.02462816409,0..0774275008,0.06554297421,0.07366750919,0.08122602002,0.004018369318,0.03508462415,0.04829900696,0.06383554085, ...'

    >
    > > However, when I start very the same list of commands as a script, it
    > > gives me the following, which is certainly wrong:

    >
    > > [0.0, 0.0, 0.0, 0.0, 0.0,...]

    >
    > > Any ideas? Why there is a difference when I run the script or do it
    > > command by command?

    >
    > > ===========================
    > > from visa import *

    >
    > > mw = instrument("GPIB0::20::INSTR", timeout = None)

    >
    > > mw.write("*RST")
    > > mw.write("CALC1:DATA? FDATA")

    >
    > > a=mw.read()

    >
    > > print a
    > > ===========================
    > > (That is really all!)

    >
    > > PS In this case I use Python Enthought for Windows, but I am not an
    > > expert in Windows (I work usually in Linux but now I need to run this
    > > data acquisition under Windows).

    >
    > Just in case you have a local installation of visa and it silently fails
    > on some import,
    >
    > try to add at the begining of your script:
    > import sys
    > sys.path.append('')
    >
    > When using the python shell cmd line, '' is added to sys.path by the
    > shell, that is one difference that can make relative imports fail in
    > your script.
    >
    > If it's still not working, well, it means the problem is somewhere else.
    >
    > JM


    Hi!

    Thanks! I have just tried. Unfortunately, it does not work ...

    Best,
    AS
     
    spintronic, Oct 25, 2011
    #7
  8. spintronic

    John Gordon Guest

    In <> spintronic <> writes:

    > > Are you in the same directory in both cases?
    > > Does PYTHONPATH and/or sys.path have the same value in both cases?


    > It looks that yes but how can it matter? All I need it is to import
    > the visa module and it works well.


    If you run the two cases from different directories, and the current
    directory is in PYTHONPATH or sys.path, and one of the directories
    contains a python file named "visa.py" and the other doesn't, that
    culd account for the difference in output.

    Do you have access to the visa.py source code? Can you add a simple
    print statement near the top of the module so that we know the same
    visa.py module is being imported in both cases?

    > > Show us an exact transscript of both executions.


    > There is nothing but "numbers". Or do you mean something else? I do
    > not receive any errors, only different results ...


    I was more interested in the exact commands you used to run both cases,
    rather than the output.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, Oct 25, 2011
    #8
  9. Am 25.10.2011 19:22, schrieb spintronic:
    > On Oct 25, 6:29 pm, Nick Dokos<> wrote:
    >> Shot in the dark: could it be that you have to add delays to give the
    >> instrument time to adjust? When you do it from the python shell, line by
    >> line, there is a long delay between one line and the next.

    > Thanks! You are right but it was the first thing I thought about. So I
    > have tried to delay using sleep(t) from the time module (I also sent
    > "*OPC?" or "*WAI" commands to a device for synchronization). However,
    > it does not help ...


    RST is resetting all data and CALC is somehow calculating and returning
    data. Without a trigger between RST and CALC, I would not expect any
    data...

    Maybe the equipment is triggering continuously e.g. every second.
    When you were using the shell, you had a good chance to see a trigger
    between RST and CALC. With a script, it's not so likely.
    OPC won't help, as it would wait for completion of a measurement, but if
    you don't trigger, it won't wait.

    What kind of instrument are you using? Check for the trigger command.
    It may be something like INIT:IMM

    Regards,

    Dietmar
     
    Dietmar Schwertberger, Oct 25, 2011
    #9
  10. spintronic

    Paul Simon Guest

    "spintronic" <> wrote in message
    news:...
    > Dear friends,
    >
    > I have a trouble with understanding the following. I have a very short
    > script (shown below) which works fine if I "run" step by step (or line
    > by line) in Python shell (type the first line/command -> press Enter,
    > etc.). I can get all numbers (actually, there are no numbers but a
    > long string, but this is not a problem) I need from a device:
    >
    > '0.3345098119,0.01069121274,0.02111624694,0.03833379529,0.02462816409,0.0774275008,0.06554297421,0.07366750919,0.08122602002,0.004018369318,0.03508462415,0.04829900696,0.06383554085,
    > ...'
    >
    > However, when I start very the same list of commands as a script, it
    > gives me the following, which is certainly wrong:
    >
    > [0.0, 0.0, 0.0, 0.0, 0.0,...]
    >
    > Any ideas? Why there is a difference when I run the script or do it
    > command by command?
    >
    > ===========================
    > from visa import *
    >
    > mw = instrument("GPIB0::20::INSTR", timeout = None)
    >
    > mw.write("*RST")
    > mw.write("CALC1:DATA? FDATA")
    >
    > a=mw.read()
    >
    > print a
    > ===========================
    > (That is really all!)
    >
    >
    > PS In this case I use Python Enthought for Windows, but I am not an
    > expert in Windows (I work usually in Linux but now I need to run this
    > data acquisition under Windows).


    I'm almost certain that there is a turnaround timing issue that is causing
    the problem. These are common problems in data aquisition systems. The
    simplest solution is to loop and wait for end of line from the sending end
    and if necessary put in a time delay. After receiving the data, check the
    received data for correct format, correct first and last characters, and if
    possible, check sum. I've worked through this problem with rs-485 data
    collection systems where there is no hand shaking and would not be surprised
    to expect the same even with rs-232.

    Paul Simon
     
    Paul Simon, Oct 25, 2011
    #10
  11. On Tue, 25 Oct 2011 08:51:27 -0700 (PDT), spintronic
    <> declaimed the following in
    gmane.comp.python.general:

    > script (shown below) which works fine if I "run" step by step (or line
    > by line) in Python shell (type the first line/command -> press Enter,
    > etc.). I can get all numbers (actually, there are no numbers but a
    > long string, but this is not a problem) I need from a device:


    <snip>

    > However, when I start very the same list of commands as a script, it
    > gives me the following, which is certainly wrong:
    >
    > [0.0, 0.0, 0.0, 0.0, 0.0,...]


    <snip>
    > mw = instrument("GPIB0::20::INSTR", timeout = None)
    >

    Does "timeout=None" mean "wait forever", or "return with whatever is
    available"?

    If the latter, it would mean the script is running too fast for the
    device to respond, and you should add some sleeps.

    >From the PyVisa documentation:


    doc> Here, my device may be a device, an interface or whatever, and its
    timeout is set to 25 seconds. Floating-point values
    doc> are allowed. If you set it to zero, all operations must succeed
    instantaneously. You must not set it to None. Instead, if
    doc> you want to remove the timeout, just say
    doc> del my_device.timeout
    doc> Now every operation of the resource takes as long as it takes, even
    indefinitely if necessary.

    Note the warning: "YOU MUST NOT SET IT TO NONE"

    > mw.write("*RST")
    > mw.write("CALC1:DATA? FDATA")
    >

    Does the write() buffer? Do you need to flush the output (something
    that may be occurring in the background with the interactive session).
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Oct 26, 2011
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jude
    Replies:
    7
    Views:
    960
    Brock Allen
    Mar 15, 2005
  2. StepH
    Replies:
    3
    Views:
    454
    Alex Verstraeten
    May 17, 2005
  3. Ulysses

    Data acquisition Card- How to use with C?

    Ulysses, Jun 20, 2007, in forum: C Programming
    Replies:
    36
    Views:
    814
    Keith Thompson
    Jun 29, 2007
  4. Replies:
    0
    Views:
    366
  5. Steven Jenkins
    Replies:
    0
    Views:
    295
    Steven Jenkins
    Jan 19, 2004
Loading...

Share This Page