EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  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  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: asyn R4.10, R4.11, R4.12
From: "Mark Rivers" <[email protected]>
To: "TECHTALK Tech-Talk" <[email protected]>
Cc: Eric Norum <[email protected]>
Date: Mon, 7 Dec 2009 15:54:07 -0600
Title: Re: asyn R4.10, R4.11, R4.12

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

 

Eric,

 

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?

 

Mark

 

 


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]



Attachment: asynRecord.patch
Description: asynRecord.patch


References:
RE: asyn R4.10, R4.11, R4.12 Mark Rivers

Navigate by Date:
Prev: Re: Elcomat 3000 Tim Mooney
Next: polling through the gateway Geoff Savage
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: asyn R4.10, R4.11, R4.12 Mark Rivers
Next: RE: asyn R4.10, R4.11, R4.12 Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·