Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Tue, 15 May 2007 09:23:15 +0200

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System