EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Strange channel access problem
From: Maren Purves <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected], [email protected]
Date: Thu, 19 Apr 2007 10:47:07 -1000
Mark,

I may be way off here, but this reminds me of a problem we sometimes had
(and probably will sometimes have again) that we haven't been able to
resolve other than by what Craig Walther calls a horrible hack:
getting your arp cache overwritten.
The output on the IOC's serial console when this happens looks
like this:
0x87fb27e0 (tNetTask): arp info overwritten for 80ab5b08 by 00:04:23:68:23:1c


and it only happens for machines that actually exist (in our case
mostly on the same network). This was investigated by network sniffing
and found to not originate on the network but come out of the same IOC.
The 'horrible hack' consists of re-overwriting the arp addresses with
the correct ones every 1/2 second.

Aloha,
Maren

Mark Rivers wrote:
Folks,

I am trying to help diagnose a very puzzling channel access problem that
is happening on Windows machines from IDL at the Australian Synchrotron.

Background:

IDL uses the following DLLs to do channel access:

   - ezcaIDL.dll  A thin wrapper on top of ezca.dll and ezcaScan.dll to
convert IDL call_external argument passing parameters to those used by
ezca and ezcaScan.

   - ezca.dll and ezcaScan.dll.  These libraries on top of ca.dll and
com.dll that take care of looking up PVs by name, handling callbacks,
etc.

- ca.dll, com.dll. The standard CA libraries from EPICS base.

I built these DLLs in 2001 with EPICS 3.13.  I've used the same DLLs
since then with all versions of IDL (up to 6.3, the current version) and
with all versions of Windows (NT, 2000, XP).  I've never had any
problems, and it is probably running on over 100 machines at APS and
NSLS, and other sites.

At the Australian Synchrotron, however, they have run into a strange
problem.  They are using the exact same DLLs that we are, standard XP
Professional SP1, and IDL 6.3.  It has the following behavior:

- ezca.dll is being called OK, because functions like caGetTimeout and
caGetRetryCount that return values from ezca are working fine.

- EPICS channel access is always failing to find PVs, returning failure
after the expected timeout interval.


This failure happens despite the following:


- The command line "caget" program works OK (except see note below).

- All Windows firewalls are turned off.

- The failure happens for PVs on the network, as well as for PVs on the
same PC running a soft IOC.

There is some behavior on the "caget" command line program that
indicates something is not quite right:

Sometimes, but not always, they get the following error with caget:

C:\RSI\IDL63\misc_dlls>caget epics:calcExample
Unexpected UDP failure WIN32 Socket Library Error 10054
epics:calcExample             9

Even when the UDP failure message appears caget still "works"

Sometimes this error does not occur:

C:\RSI\IDL63\misc_dlls>caget epics:calcExample
epics:calcExample             0

Another thing that they have seen is that caget to local PVs on the PC
return instantly, while caget to PVs on the network do not return until
after a 4 second delay.

In principle we should be able to turn on the rich debugging in ezca
(Trace and Debug flags).  However, that debugging output goes to stdout,
which does not exist in the Windows version of IDL, because it is a
"Windowing" application, not a console application, and hence has no
place for stdout to go.  We could rewrite ezca to send the output to a
file, but that is more work than I'm in the mood for right now :-)

Anyone have any idea what could be wrong?

Thanks,
Mark


References:
Strange channel access problem Mark Rivers

Navigate by Date:
Prev: Strange channel access problem Mark Rivers
Next: Re: Strange channel access problem Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Strange channel access problem Mark Rivers
Next: Re: Strange channel access problem Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·