I'm having strange behavior with Epics Windows Tools on 64-bit
Windows7 and was wondering if anyone had any comparable experiences,
insights, or suggestions.
I've installed EPICSWindowsTools1.41-x64.msi on 64-bit Windows7 (into
C:\Program Files\Epics Windows Tools), and am using Exceed 2008 x64,
version 13.00. Many things work fine, including the following:
caget -c PVname
caput -c PVname (and respects the -w option)
caConntest PVname 1 1
repeatedly creates / destroys connections (taking ~30ms for each
successfully connects, and reports sensible test results.
For X applications, the following appear to work fine (I'm sorry to
say I don't know how adt, alh, namecapture work):
probe successfully connects and monitors,
history gets updated, etc.
histTool a histogram is displayed and updated,
ranges can be changed and are obeyed.
medm edit mode appears to work file.
What doesn't work so well for me are:
medm in execute mode
For MEDM, I see the following behavior:
I can open and display several adl files with no PVs.
I can open one child screen with actual PVs, and these
PVs are displayed and updated on changes.
Once displayed, I cannot open any further screens, nor
close any MEDM screens (even those for editing). MEDM
appears to be hung, and has to be killed with TaskManager.
For StripTool the behavior is also strange, but perhaps informative.
I can connect to a PV that is changing rapidly (say, 10Hz) and the
stripchart for it runs and is updated, and the entire program seems
responsive. If I connect to a slower-changing PV, the entire GUI
appears to respond only on change-events to that PV. For example,
clicking on the "Controls" tab on the main window will not actually
show the Controls panel until the PV has changed.
I'm also seeing trouble with my Python library interface with the
64-bit dll that I do not see with the 32-bit Windows, or on 64-bit
linux. The basic issue here is that a connection callback run for
ca_create_channel() gets an access violation when it calls
ca_name(args.chid), though of course most other CA calls appear to
work fine. Sorry, I haven't translated that into a minimal C program
to demonstrate the problem yet. I'm willing to leave this aside for
the moment, as the Python module works fine on this machine in 32-bit
emulation mode (with the 32-bit dlls of course), but thought it might
provide a clue.
I'm sure that I'm using the 64-bit versions of the dlls and
executables, and that the dlls and executables from the distribution
folder are being used -- if I rename ca.dll, caget.exe pops up a
message saying that it cannot find ca.dll. I have also rebuilt epics
base 188.8.131.52 with EPICS_HOST_ARCH=windows-x64 and Visual Studio 10
on this machine, and see the same behaviors with the dlls (ca.dll,
Com.dll) built on this machine. I don't have the SDK for Exceed to
try rebuilding MEDM.
Finally, we have 2 64-bit Windows7 machines, and I see the same
behavior for MEDM and StripChart on both.
Any suggestions would be greatly appreciated.
--Matt Newville <newville at cars.uchicago.edu> 630-252-0431
- RE: trouble with 64-bit Window7 Mark Rivers
- Navigate by Date:
CA beacon routing error S_errno_ECONNREFUSED J. Lewis Muir
RE: CA beacon routing error S_errno_ECONNREFUSED Jeff Hill
- Navigate by Thread:
Re: CA beacon routing error S_errno_ECONNREFUSED J. Lewis Muir
RE: trouble with 64-bit Window7 Mark Rivers