EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: ASYN: slow GPIB
From: Mark Rivers <[email protected]>
To: Michael Ritzert <[email protected]>, "[email protected]" <[email protected]>
Date: Sat, 4 Jan 2014 22:11:06 +0000
Hi Michael,

I think it would be a good idea to see if you get the problem with only asyn, without streamDevice.

I suggest loading an asynRecord and using the asynOctet.adl medm screen (or equivalent for your favorite GUI) to send the commands to your device and see if you also get errors and long delays.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Michael Ritzert [[email protected]]
Sent: Thursday, January 02, 2014 7:17 AM
To: [email protected]
Subject: ASYN: slow GPIB

Hi all!

I'm interfacing to a Keithley 2602 SMU with ASYN+linux-gpib. The
communication is working is principle, but it's awfully slow. I set the
record to scan every 2 seconds, and this is what I get from asynTrace:

2014/01/02 14:04:14.246 L0 addr 3 gpibPortWrite
print(smua.measure.i())\n
InternalReceiveSetup: command failed
2014/01/02 14:04:25.202 L0 addr 3 : EDVR 0: OS error.
2014/01/02 14:04:25.202293 L0 iocgpib:currentStep: asynError in read: L0 readGpib failed EDVR 0: OS error
2014/01/02 14:04:25.202360 L0 iocgpib:currentStep: I/O error after reading 0 bytes: ""
2014/01/02 14:04:25.202391 L0 iocgpib:currentStep: Protocol aborted
2014/01/02 14:04:43.033 L0 addr 3 gpibPortWrite
print(smua.measure.i())\n
2014/01/02 14:04:52.270 L0 addr 3 gpibPortRead
1.78814e-12\n
2014/01/02 14:05:45.841 L0 addr 3 gpibPortWrite
print(smua.measure.i())\n
2014/01/02 14:06:26.754 L0 addr 3 gpibPortRead
-3.36170e-12\n
2014/01/02 14:06:34.490 L0 addr 3 gpibPortWrite
print(smua.measure.i())\n
2014/01/02 14:06:53.271 L0 addr 3 : device timed out.
2014/01/02 14:06:53.270555 L0 iocgpib:currentStep: No reply from device within 1000 ms
2014/01/02 14:07:21.524 L0 addr 3 gpibPortWrite
print(smua.measure.i())\n
2014/01/02 14:08:59.935 L0 addr 3 gpibPortRead
4.32730e-12\n

Note the time of up to 40 seconds between read and write. The result is
correct in the end, but it's not reliable as you can see from the error
messages.

I'm using a NI USB HS GPIB adapter. Using ibtest to access the device works
as expected, i.e. with the response immediately available.

Does anybody know this problem (and a fix), or what can I do to debug
further?

Regards,
Michael

PS: more on the configuration: gpib.conf:
interface {
        minor = 0       /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
        board_type = "ni_usb_b" /* type of interface board being used */
        name = "L0"     /* optional name, allows you to get a board descriptor using ibfind() */
        pad = 0 /* primary address of interface             */
        sad = 0 /* secondary address of interface           */
        timeout = T3s   /* timeout for commands */

        master = yes    /* interface board is system controller */
        eos = 0x0a      /* EOS Byte, 0xa is newline and 0xd is carriage return */
        set-reos = yes  /* Terminate read if EOS */
        set-bin = no    /* Compare EOS 8-bit */
        set-xeos = no   /* Assert EOI whenever EOS byte is sent */
        set-eot = yes   /* Assert EOI with last byte on writes */
}


yourdev.proto (I started with the example on the web):
Terminator = LF;

getCurrentStep {
        out "print(smua.measure.i())";
        in "%f";
}

DB file:
record (ai, "$(P)currentStep")
{
   field (SCAN, "2 second")
   field (DTYP, "stream")
   field (INP,  "@yourdev.proto getCurrentStep $(PORT) $(ADDR)")
}

call to GPIB init in st.cmd:
GpibBoardDriverConfig("L0", "1", "0" "3", "0")
--
Michael Ritzert                       Tel: +49 621 181 2883
Schaltungstechnik und Simulation      Fax: +49 621 181 2734
Technische Informatik, Uni Heidelberg [email protected]
68131 Mannheim, Germany               http://sus.ziti.uni-heidelberg.de


References:
ASYN: slow GPIB Michael Ritzert

Navigate by Date:
Prev: Happy 2014! Andrew Johnson
Next: SNS Linux System Administrator Hartman, Steven M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: ASYN: slow GPIB Michael Ritzert
Next: streamdevice timerExpired() unexpected ioAction None Zhang, Dehong
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·