RE: problem using streams with asyn for Agilent E5810A Ethernet->GPIB

["Denison, PN \(Peter\)" <peter.denison@diamond.ac.uk>]

> From: Dirk Zimoch [mailto:dirk.zimoch@psi.ch] 
> 
> 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" 
> <matthew.pearson@diamond.ac.uk>
> > 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