Experimental Physics and Industrial Control System
|
Hi Peter,
it seems I misunderstood what the current problem was.
Indeed, stream first tries to read 1 byte with a quite long timeout (reply
timeout) and then the rest with shorter timeout (read timeout). Also any very
long message may be read in pieces from the underlying asyn driver.
Even though this should be legal according to the asyn documentation (and works
perfectly for serial and TCP), the GPIB driver did not support it, returned
"asynOverflow" and destroyed the message. I had modified StreamDevice some time
ago not to read a single byte at the beginning any more if he device is GPIB.
But still there might be a problem with very long messages.
As far as I know, the lastest version of asyn also fixes this problem and the
GPIB driver does not return "asynOverflow" any more.
Thus, either upgrading asyn or stream (or both) to the the latest version should
fix your problem. Please report if that worked.
Yours,
Dirk
Denison, PN (Peter) wrote:
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
**********************************************************
--
Dr. Dirk Zimoch
Computing and Controls
Paul Scherrer Institut
phone +41 56 310 5182
fax +41 56 310 4413
- Replies:
- RE: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Denison, PN (Peter)
- References:
- RE: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Denison, PN (Peter)
- Navigate by Date:
- Prev:
RE: Asyn Delay Mark Rivers
- Next:
waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
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 Denison, PN (Peter)
- Next:
RE: problem using streams with asyn for Agilent E5810A Ethernet->GPIB Denison, PN (Peter)
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 10 Nov 2011 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|