EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: dm and edm problems with CA gateway
From: Albert Kagarmanov <[email protected]>
To: "Kenneth Evans, Jr." <[email protected]>
Cc: "'tech_talk'" <[email protected]>
Date: Fri, 11 Mar 2005 16:02:38 +0100 (MET)
	Hi Ken,

   Here at DESY we're also having a small bug with channel access
gateway(v2.0.0b12) but in another area. It's happen with Alarm Handler
(v1.2.13) in global mode:

    For each one new IOC alarm event, alh calculates 2 alh conditions and
creates 2 lines in alarm log file. When I try to debug  alh-C-code I've
found that it's really 2 monitor procedure alCaNewEvent() invoked per one
IOC alh event.


Bug description:

1) This is happen only if alh starts in global mode.

2) This is depend from 2 variables
   LIST=EPICS_CA_ADDR_LIST
   AUTO= EPICS_CA_AUTO_ ADDR_LIST
   This error happen even if LIST contains only one hostname

3) Another application in our environment working with ca_gateway quite OK.
For example
  $> caget PV
returns one answer if  LIST not set  or if it set but AUTO=NO. If LIST is
set and AUTO=YES caget returns value and informs about "Ambiguous channel
host". We can summarize it as a table for a number of caget answers :

    LIST|Empty |"Host"|
 AUTO	|      |      |
---------------|------|
NO      | 0    |    1 |
YES    	| 1    |1+info|


4) ALH also works OK without gateway or if AUTO=YES (in this case alh creates
special warning window in start-time about "Ambiguous channel host").
   But if LIST is not empty and AUTO=NO, alh calculates 2 internal alarm
conditions per one real alarm event and add 2 lines into the alhLogFile.
We can summarize it as a table for a number of additional lines into the
alhLogFiles per 1 ioc-alarm:

  LIST  |Empty |"Host"|
 AUTO	|      |      |
--------|------|------|
NO      | 0    |   2  |
YES    	| 1    |   1  |

Number "2" in the second column is this bug.

Best regards,
Albert Kagarmanov.


On Mon, 7 Mar 2005, Kenneth Evans, Jr. wrote:
> I was able to reproduce this problem with the behavior described by
> Rolf with one combination of systems.  I set DRVH = DRVL =0.0 on a
> test PV to allow the large values.  It then happens for me from an
> MEDM on Windows going to a Gateway on Linux.  The MEDM was using a
> simple ADL file with only a slider.  It does not happen for me for any
> other combination of Solaris, Linux, or Windows MEDMs going to Linux
> or Solaris Gateways.
>
> I was also unable to reproduce the problem (mentioned by Ralph) with
> two simultaneous sliders when going to Solaris Gateways.  That worked
> all right for me.
>
> I was able to set up a test Gateway on a non-standard port on the one
> Linux box with multiple interfaces I have available.  (I cannot debug
> with our Main Gateway on the same machine even though it also
> has the described problem with the Windows MEDM.)
>
> The connection goes:
>
> MEDM -> CAS -> Gateway -> CAC -> IOC
>
> I can verify the MEDM is sending the correct values and CAS is sending
> incorrect values to the test Gateway.  When the Gateway does a CAC
> put, it does a put with callback and does not do any other puts until
> the callback happens.  Any write requests that come in while there is
> a pending write are sent back to CAS as postponed, and CAS handles them
> and resends them later.  Normally things are so fast that there are
> probably no postponements.  With sliders they can happen, and
> apparently there is a problem with the postponed I/O.
>
> I also note the postponed I/O comes back quite some time after it was
> originally sent.  Other new values come in the meantime, so the slider
> values that result in CAC puts are done out of order.  In my tests
> only about 1 in 10 writes was postponed.
>
> The fact that it only happens with Linux may be the speed of our Linux
> box, not the platform itself.  In addition, when I inserted print
> statements in MEDM to check its values, the problem stopped happening
> owing to the slowdown associated with the prints.  It seems to require
> the postponed I/O, which probably rarely happens in the APS Gateways,
> owing their being predominately read only in the first place.
>
> It looks as though it needs to be fixed in CAS.
>
>

Replies:
RE: dm and edm problems with CA gateway Kenneth Evans, Jr.
References:
RE: dm and edm problems with CA gateway Kenneth Evans, Jr.

Navigate by Date:
Prev: Upcoming Meeting Dalesio, Leo `Bob`
Next: drvEpvxi.c (epvxiResman) & 3.14... Laznovsky, Michael
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: dbpf before iocInit... Emmanuel Mayssat
Next: RE: dm and edm problems with CA gateway Kenneth Evans, Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·