Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 20 Apr 2007 22:56:14 -0500

Chris and all,

I've succeeded in building the EPICS Extensions ezca, EzcaScan, and ezcaIDL for win32-x86 with EPICS 3.14.8.2 using Visual Studio .NET 2003.

Base was built with SHARED_LIBRARIES=NO and STATIC_BUILD=YES.  I've copied all of the resulting executables (base/bin/win32-x86/*) into a directory I called EPICS_WIN32_binaries.  

I also added to that directory the following files:

ezca.dll and ezca.lib       
     The ezca library as a DLL that can be called, for example, from Visual Basic.  
     Since this was built with a statically built version of EPICS base it does not need ca.dll or Com.dll.

ezca.bas
     A Visual Basic module that contains the needed definitions to call ezca from your VB program

EzcaScan.dll and EzcaScan.lib  
     Libraries for the EzcaScan.  These will probably be rarely needed.  

ezcaIDL.dll and ezcaIDL.lib  
   The DLL that IDL can call.  It was built as follows:
   - Non-DLL versions of ezca and EzcaScan were first built
   - ezcaIDL was built against those .lib files.
   - Thus, ezcaIDL.dll is standalone, it does not need ezca.dll, EzcaScan.dll, ca.dll, or Com.dll.
     This is a nice improvement over previous versions of ezcaIDL.dll, which required those DLLs in your PATH.

ezcaIDL.pro and ezcaIDLWidgets.pro.
     IDL procedures to call ezcaIDL.dll

To use ezcaIDL.dll with IDL you must define the environment variable EZCA_IDL_SHARE to point to the file, e.g.
C:\EPICS_WIN32_binaries\eczaIDL.dll

It is no longer necessary to put that directory in your PATH, since the DLL is now standalone.

I have made a zip file of that directory at:

http://cars.uchicago.edu/software/pub/EPICS_WIN32_binaries.zip

This zip file may be useful for people who want to use EPICS Channel Access on Windows, but don't want to go through the hassle of setting up a build environment.

I hope that this new DLL fixes the problem at the Australian Synchrotron, but I'm not making any bets :-)

Cheers,

Mark

PS It is important to note that all of my experience with IDL has been with the old DLLs built with 3.13.  I have verified that this new ezcaIDL.dll does work, but since it's only about an hour old, it obviously has not been tested much.

________________________________

From: Mark Rivers
Sent: Thu 4/19/2007 2:45 PM
To: '[email protected]'; '[email protected]'
Subject: Strange channel access problem

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System