Folks,
The attached patch (also below in case attachments don’t
work) fixes a problem in asynRecord.c that was introduced when the readRaw and
writeRaw functions were removed from asynOctet in R4-10. The problem
causes binary writes and reads to fail if the underlying asynOctet driver or
interpose interface does not implement both the getOutputEos or getInputEos
methods.
Mark
Index: asynRecord.c
===================================================================
RCS file:
/net/phoebus/epicsmgr/cvsroot/epics/modules/soft/asyn/asyn/asynRecord/asynRecord.c,v
retrieving revision 1.82
diff -u -r1.82 asynRecord.c
--- asynRecord.c 28
May 2008 18:58:51 -0000 1.82
+++ asynRecord.c 7 Dec
2009 17:15:08 -0000
@@ -1476,18 +1476,16 @@
status = pasynRecPvt->pasynOctet->getOutputEos(
pasynRecPvt->asynOctetPvt,pasynUser,
saveEosBuf,sizeof
saveEosBuf,&saveEosLen);
-
if (status != asynSuccess) {
-
reportError(pasynRec, status, "EOS TOO LONG");
-
return;
-
}
+
/* getOutputEos can return an error if the driver does not implement it */
+
if (status != asynSuccess) saveEosLen = 0;
if (saveEosLen)
pasynRecPvt->pasynOctet->setOutputEos(pasynRecPvt->asynOctetPvt,
-
pasynUser,NULL,0);
+
pasynUser,NULL,0);
status = pasynRecPvt->pasynOctet->write(pasynRecPvt->asynOctetPvt,
-
pasynUser, outptr, nwrite, &nbytesTransfered);
+
pasynUser, outptr, nwrite, &nbytesTransfered);
if (saveEosLen)
pasynRecPvt->pasynOctet->setOutputEos(pasynRecPvt->asynOctetPvt,
-
pasynUser,saveEosBuf,saveEosLen);
+
pasynUser,saveEosBuf,saveEosLen);
} else {
/* ASCII or Hybrid mode */
status = pasynRecPvt->pasynOctet->write(pasynRecPvt->asynOctetPvt,
@@ -1514,16 +1512,16 @@
status = pasynRecPvt->pasynOctet->getInputEos(
pasynRecPvt->asynOctetPvt,pasynUser,
saveEosBuf,sizeof saveEosBuf,&saveEosLen);
-
if (status != asynSuccess) {
-
reportError(pasynRec, status, "EOS TOO LONG");
-
return;
-
}
-
pasynRecPvt->pasynOctet->setInputEos(pasynRecPvt->asynOctetPvt,
-
pasynUser,NULL,0);
+
/* getInputEos can return an error if the driver does not implement it */
+
if (status != asynSuccess) saveEosLen = 0;
+
if (saveEosLen)
+
pasynRecPvt->pasynOctet->setInputEos(pasynRecPvt->asynOctetPvt,
+
pasynUser,NULL,0);
status = pasynRecPvt->pasynOctet->read(pasynRecPvt->asynOctetPvt,
pasynUser, inptr, nread, &nbytesTransfered,&eomReason);
-
pasynRecPvt->pasynOctet->setInputEos(pasynRecPvt->asynOctetPvt,
-
pasynUser,saveEosBuf,saveEosLen);
+
if (saveEosLen)
+
pasynRecPvt->pasynOctet->setInputEos(pasynRecPvt->asynOctetPvt,
+
pasynUser,saveEosBuf,saveEosLen);
} else {
/* ASCII or Hybrid mode */
status = pasynRecPvt->pasynOctet->read(pasynRecPvt->asynOctetPvt,
From: Mark Rivers
Sent: Sunday, December 06, 2009
5:53 PM
To: Eric Norum; Szalata, Zenon M.
Cc: TECHTALK Tech-Talk
Subject: RE: asyn R4.10, R4.11,
R4.12
I think I understand the problem.
The VXI11 driver is called by the asynGpib driver. The asynGpib
driver only implements asynOctet->set/getInputEos, not
set/getOutputEos. It thus uses the default implementation of the
set/getOutputEos functions in asynOctetBase, which return an error.
The asynRecord calls getOutputEos under some conditions. When it
is doing a binary write (OFMT==Binary) if it gets an error return from
getOutputEos it treats it as a serious error.
I can think of 2 possible solutions to the problem:
1) Make the default implementation of the getEos functions not
return an error, and just return an eoslen of 0.
2) Change the asynRecord to tolerate an error return from
getOutputEos.
My patch for Zen did 1. Perhaps 2 is better, or perhaps both 1
and 2?
From: Eric
Norum [mailto:[email protected]]
Sent: Sun 12/6/2009 4:19 PM
To: Szalata, Zenon M.
Cc: Mark Rivers; TECHTALK
Tech-Talk
Subject: Re: asyn R4.10, R4.11,
R4.12
Why does a patch to asynOctet have this effect?
The code's using VXI-11, which does provide the get/set EOS
methods. If the higher level code isn't using these is it not an
indication of a deeper problem?
On Dec 6, 2009, at 1:55 PM, Szalata, Zenon M. wrote:
> Hi Mark and Thank you,
> I applied the patch as instructed and now my IOC works with asyn R4.12.
> So, for me the problem is fixed. I will do more testing.
>
> Zen
>
> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Sunday, December 06, 2009 9:54 AM
> To: Szalata, Zenon M.; Eric Norum
> Cc: TECHTALK Tech-Talk
> Subject: RE: asyn R4.10, R4.11, R4.12
>
> Hi Zen,
>
> I think the best solution to this is for the default implementation of
> asynOctet->getInputEos and getOutputEos to return asynSuccess and
> *eoslen=0.
>
> I've attached a patch for asynOctetBase.c against the R4-12 release.
> Can you give it a try and see if it fixes the problem?
>
> Thanks,
> Mark
>
>
> ________________________________
>
> From: Szalata, Zenon M. [mailto:[email protected]]
> Sent: Sun 12/6/2009 10:51 AM
> To: Mark Rivers; Eric Norum
> Cc: TECHTALK Tech-Talk
> Subject: RE: asyn R4.10, R4.11, R4.12
>
>
>
> Hi Mark,
> Here is the result of dbpr "CAM:ASYN:IO",5:
>
> epics> dbpr "CAM:ASYN:IO",5
> ACKS: NO_ALARM ACKT:
YES ACMD:
None ADDR: 12
>
>
AINP:
AOUT:
AQR: 0
ASG:
>
> ASP: 0x00000000 AUCT: autoConnect
BAUD: Unknown BINP: 0
>
> BKPT: 0x00 BOUT:
0 CNCT:
Connect DBIT:
> Unknown
> DESC: asyn IO DISA:
0 DISP:
0 DISS:
> NO_ALARM
> DISV:
1 DPVT:
0xf0f85c09
DRVINFO:
DSET:
> 0x488a5b00
> DTYP: asynRecordDevice
ENBL: Enable EOMR: None
>
> ERRS: 0xd8fb5c09 EVNT:
0
F64INP: 0 F64IV: 0
>
> F64OUT: 0
FCTL: Unknown FLNK:DB_LINK CAM:FO:IO:DATA
>
> GPIBIV: 1
I32INP: 0 I32IV:
1 I32OUT: 0
>
>
IEOS:
IFACE: asynOctet IFMT:
Binary IMAX: 80
>
> IPTR: 0x28fb5c09 LCNT:
0 LSET:
0xd0d35d09 MCTL:
> Unknown
> MLIS: 0x000000000000000000000000
MLOK: 0xd8f85c09 NAME:
> CAM:ASYN:IO
> NAWT:
0 NORD:
0 NOWT:
6 NRRD:
0
>
> NSEV: NO_ALARM NSTA:
NO_ALARM OCTETIV:
1 OEOS:
>
> OFMT: Binary OMAX:
80 OPTIONIV:
1 OPTR:
> 0xd0fa5c09
> PACT:
0
PCNCT: Connect PHAS:
0 PINI:
NO
>
> PORT: L0
PPN: 0x00000000 PPNR: 0x00000000
PRIO: LOW
>
> PROC:
0 PRTY:
Unknown PUTF:
0 RDES:
> 0x58855909
> REASON: 0
RPRO: 0
RSET: 0x008a5b00 SBIT:
> Unknown
> SCAN: Passive
SDIS:CONSTANT SEVR:
NO_ALARM SOCK:
>
> SPR:
0
SPVT: 0x00000000 STAT: NO_ALARM
TB0: On
>
> TB1: Off
TB2: Off TB3:
Off TB4: Off
>
> TFIL: Unknown TIB0:
Off TIB1:
Off TIB2: Off
>
> TIME: 2009-12-06 08:51:04.871003000
TINP:
TIOM: 0
>
> TMOD: Write/Read TMOT:
1 TMSK:
1 TPRO:
0
>
> TSE:
0
TSEL:CONSTANT TSIZ:
80 UCMD: None
>
> UDF:
0
UI32INP: 0 UI32IV:
0 UI32MASK:
> 4294967295
> UI32OUT: 0
VAL:
> epics>
>
> Thanks,
> Zen
>
> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Saturday, December 05, 2009 9:43 PM
> To: Szalata, Zenon M.; Eric Norum
> Cc: TECHTALK Tech-Talk
> Subject: RE: asyn R4.10, R4.11, R4.12
>
> Are you using the asyn record? If so, then do a
>
> dbpr "myAsynRecord" 5
>
> to see what you have set the EOS string to.
>
> Mark
>
>
> ________________________________
>
> From: [email protected] on behalf of Szalata, Zenon M.
> Sent: Sat 12/5/2009 11:38 PM
> To: Eric Norum
> Cc: TECHTALK Tech-Talk
> Subject: RE: asyn R4.10, R4.11, R4.12
>
>
>
> I am not aware of explicitly specifying the EOS string. I thought
that
> EOS string was not used and only the EOI was. That is, the KS3988
GPIB
> CAMAC crate controller does not require nor accepts an EOS string. I
> maybe wrong on this. Perhaps, somehow unwittingly I am sending some
EOS
> string? How can I verify that?
>
> Actually, in my original message I told a lie, I am not using
> streamdevice, just asyn.
>
> Why does it work with asyn R4.9 and not with the newer versions? Is
it
> possible that starting with R4.10 default behavior changed? Could it
> be, that starting with R4.10 I have to explicitly say no EOS?
>
> Zen
>
> -----Original Message-----
> From: Eric Norum [mailto:[email protected]]
> Sent: Saturday, December 05, 2009 9:01 PM
> To: Szalata, Zenon M.
> Cc: TECHTALK Tech-Talk
> Subject: Re: asyn R4.10, R4.11, R4.12
>
> The E5810A allows only a single EOS character. Are you trying to use
a
> longer end-of-string?
>
> On Dec 5, 2009, at 8:51 PM, Szalata, Zenon M. wrote:
>
>> Hi Eric,
>> I am using Agilent E5810A.
>>
>> Here is a line from the st.cmd file:
>>
>> vxi11Configure(
"L0","134.79.64.25",0,0.0,"gpib0",0,0)
>>
>> Thank you,
>> Zen
>>
>>
>> -----Original Message-----
>> From: Eric Norum [mailto:[email protected]]
>> Sent: Saturday, December 05, 2009 8:35 PM
>> To: Szalata, Zenon M.
>> Subject: Re: asyn R4.10, R4.11, R4.12
>>
>> What GPIB controller are you using?
>>
>> On Dec 5, 2009, at 5:42 PM, Szalata, Zenon M. wrote:
>>
>>> I have a simple soft IOC which uses asyn and streamdevice.
It does
> IO
>>> with KS3988 GPIB CAMAC crate controller. The IOC works
correctly
> with
>>> asyn R4.9. I have installed asyn R4.12 and my IOC does not
work with
>
>>> asyn R4.12. I get the following message: "EOS TOO
LONG". I also
>> tried
>>> asyn R4.11 and R4.10 I see the same message with these the two
>> versions
>>> of asyn as I see with the latest.
>>>
>>> How do I overcome this difficulty? Do these newer versions
of asyn
>>> require that I make some change to my IOC? Can someone help
me with
>>> this, please?
>>>
>>> For now I am forced to stay with asyn R4.9.
>>>
>>> Thanks,
>>> Zen
>>>
>>
>> --
>> Eric Norum
>> [email protected]
>>
>>
>>
>>
>
> --
> Eric Norum
> [email protected]
>
>
>
>
>
>
>
>
>
>
--
Eric Norum
[email protected]