Janet's suggestion that the problem was with the version of Exceed was
We were running with Exceed 2008 (also called Exceed 13). It was
working fine when running medm on a remote machine and displaying
locally on the Windows 7 64-bit machine. However, it was failing when
running 64-bit medm locally.
I just installed Exceed 14, and it fixes the problem. It now runs medm
locally with no problems that I have seen.
From: Mark Rivers
Sent: Friday, May 20, 2011 2:16 PM
To: Matt Newville; EPICS Tech Talk
Subject: RE: trouble with 64-bit Window7
I have just reproduced Matt's results on another Windows 7 64-bit
machine. Here are some additional observations:
- If I run medm on a Linux machine but display it on the Windows 7
machine it works fine. This is true in both edit and execute modes.
That is a strong indication that the Exceed 2008 64-bit server is
- If I run medm locally in edit mode it works fine.
- If I run medm locally in execute mode it will display at most one
window with EPICS PVs in it. Sometimes it will not even finishing
painting one window. Invariably after closing that window or trying to
open another one medm hangs and the only way to exit is to use the Task
- There are no error messages in the medm Local Console Window.
[mailto:email@example.com] On Behalf Of Matt Newville
Sent: Friday, May 20, 2011 10:41 AM
To: EPICS Tech Talk
Subject: trouble with 64-bit Window7
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 184.108.40.206 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
- trouble with 64-bit Window7 Matt Newville
- RE: trouble with 64-bit Window7 Mark Rivers
- Navigate by Date:
EPICS 220.127.116.11 on Fedora 15 gcc 4.6 Mihaylov, Miroslav N.
RE: EPICS 18.104.22.168 on Fedora 15 gcc 4.6 Jeff Hill
- Navigate by Thread:
Re: Problem installing sscan 2-6-6 on cygwin Tim Mooney
Problem building 22.214.171.124 on cygwin-x86 Mark Rivers