EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: problem using streams with asyn for Agilent E5810A Ethernet->GPIB
From: "Denison, PN \(Peter\)" <[email protected]>
To: "Dirk Zimoch" <[email protected]>
Cc: "tech talk" <[email protected]>
Date: Mon, 14 May 2007 17:37:09 +0100
> From: Dirk Zimoch [mailto:[email protected]] 
> 
> The %c and %s input formats work like in scanf (the 
> implementation actually use sscanf). Thus, %s stops reading
> at the first whitespace. This is probably not what you want.
> %39c only stops reading after 39 characters or at end of
> string. 
> For more information see the manual pages for scanf.
> 
> Dirk

I think that this is a bit of a digression. Notwithstanding the useful
comments about using %39c (or Eric's %39[^\r\n]), the string that is
coming back from this device does not have any spaces.
"LSCI,MODEL340,342162,042304"

What looks to be happening is that the first character ('L') comes back
OK, then an "asynOverflow" is reported.

It seems to something to do with the way streams uses asyn. First it
reads 1 character, then it tries to read a full buffer, and this 2nd
read is failing somehow.

> > On 5/11/07 10:01 AM, "Matthew Pearson" 
> <[email protected]>
> > wrote:
> >     If I process the record, then the IOC prints:
> > 
> >     ************************
> > 
> >      epics> 2007/05/11 15:55:45.125 L0 addr 12 queueRequest 
> priority 0
> >     not lockHolder
> >     2007/05/11 15:55:45.125 L0 schedule queueRequest timeout
> >     2007/05/11 15:55:45.125 L0 callback
> >     2007/05/11 15:55:45.125 L0 addr 12 queueRequest priority 0 not
> >     lockHolder
> >     2007/05/11 15:55:45.125 L0 schedule queueRequest timeout
> >     2007/05/11 15:55:45.125 L0 callback
> >     2007/05/11 15:55:45.125 L0 12 vxiWrite numchars 5
> >     2007/05/11 15:55:45.128 L0 12 vxiWrite
> >     *IDN?
> >     *IDN?
> > 
> >     2a 49 44 4e 3f
> >     2007/05/11 15:55:45.128 L0 addr 12 queueRequest priority 0 from
> >     lockHolder
> >     2007/05/11 15:55:45.128 L0 schedule queueRequest timeout
> >     2007/05/11 15:55:45.128 L0 callback
> >     2007/05/11 15:55:45.128 L0 vxiSetEos 0
> > 
> >     2007/05/11 15:55:45.140 L0 12 vxiRead
> >     L
> >     L
> > 
> >     4c
> >     2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: asynOverflow:
> >     2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: I/O error 
> from device
> >     2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: Protocol aborted
> > 
> >     *************************
> > 
> >     This is with all asyn tracing turned on.
> > 
> >     The equivalent printout for the AsynRecord, is:
> > 
> >     ****************************
> > 
> >     2007/05/11 15:57:53.682 L0 addr 12 queueRequest priority 0 not
> >     lockHolder
> >     2007/05/11 15:57:53.682 L0 schedule queueRequest timeout
> >     2007/05/11 15:57:53.682 L0 callback
> >     2007/05/11 15:57:53.682 mp49:asyn:Record: 
> asynCallbackProcess, state=3
> >     2007/05/11 15:57:53.683 mp49:asyn:Record flush
> >     2007/05/11 15:57:53.683 L0 12 vxiWrite numchars 5
> >     2007/05/11 15:57:53.685 L0 12 vxiWrite
> >     *IDN?
> >     *IDN?
> > 
> >     2a 49 44 4e 3f
> >     2007/05/11 15:57:53.685 mp49:asyn:Record: nwrite=5, 
> status=0, nawt=5
> >     *IDN?
> >     *IDN?
> > 
> >     2a 49 44 4e 3f
> >     2007/05/11 15:57:53.741 L0 12 vxiRead
> >     LSCI,MODEL340,342162,042304
> > 
> >     LSCI,MODEL340,342162,042304\r\n
> > 
> >     4c 53 43 49 2c 4d 4f 44 45 4c 33 34 30 2c 33 34 32 31 36 32
> >     2c 30 34 32 33 30 34 0d 0a
> >     2007/05/11 15:57:53.741 mp49:asyn:Record: inlen=40, 
> status=0, ninp=29
> >     LSCI,MODEL340,342162,042304
> > 
> >     LSCI,MODEL340,342162,042304\r\n
> > 
> >     4c 53 43 49 2c 4d 4f 44 45 4c 33 34 30 2c 33 34 32 31 36 32
> >     2c 30 34 32 33 30 34 0d 0a
> >     2007/05/11 15:57:53.741 mp49:asyn:Record: inlen=29,
> >     nbytesTransfered=29, ntranslate=31
> > 
> >     **********************************************************

-- 
Peter Denison, Senior Software Engineer
Diamond Light Source Ltd., Diamond House, Chilton, Didcot, Oxon
OX11 0DE   Tel: +44 1235 778511


Replies:
Re: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Dirk Zimoch
References:
Re: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Dirk Zimoch

Navigate by Date:
Prev: Re: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Eric Norum
Next: Asyn Delay Robert Emery
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Eric Norum
Next: Re: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·