Experimental Physics and Industrial Control System
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
- Replies:
- Re: Strange channel access problem Maren Purves
- Re: Strange channel access problem Till Straumann
- RE: Strange channel access problem Jeff Hill
- Navigate by Date:
- Prev:
RE: nexplained hangup in semTake(), Re: channel access security deadlock from asInit() Jeff Hill
- Next:
Re: Strange channel access problem Maren Purves
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Lake Shore Temperature Controller 340 Rodney R. Porter
- Next:
Re: Strange channel access problem Maren Purves
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024