Experimental Physics and Industrial Control System
Hi,
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 PVname
caget -c PVname
caput PVname
caput -c PVname (and respects the -w option)
cainfo PVname
camonitor PVname
In addition
caConntest PVname 1 1
repeatedly creates / destroys connections (taking ~30ms for each
connection), and
catime PVname
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
Striptool
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 3.14.12.1 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.
Thanks,
--Matt Newville <newville at cars.uchicago.edu> 630-252-0431
- Replies:
- RE: trouble with 64-bit Window7 Mark Rivers
- Navigate by Date:
- Prev:
CA beacon routing error S_errno_ECONNREFUSED J. Lewis Muir
- Next:
RE: CA beacon routing error S_errno_ECONNREFUSED Jeff Hill
- 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: CA beacon routing error S_errno_ECONNREFUSED J. Lewis Muir
- Next:
RE: trouble with 64-bit Window7 Mark Rivers
- 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