EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: trouble with 64-bit Window7
From: "Mark Rivers" <[email protected]>
To: "Matt Newville" <[email protected]>, "EPICS Tech Talk" <[email protected]>
Date: Fri, 20 May 2011 14:16:02 -0500
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
working properly.

- 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
Manager.

- There are no error messages in the medm Local Console Window.

Mark


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Matt Newville
Sent: Friday, May 20, 2011 10:41 AM
To: EPICS Tech Talk
Subject: trouble with 64-bit Window7

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:
Problem installing sscan 2-6-6 on cygwin Zhan Zhang
RE: trouble with 64-bit Window7 Mark Rivers
References:
trouble with 64-bit Window7 Matt Newville

Navigate by Date:
Prev: RE: problem with gateway and softIoc running on same server Kevin Tsubota
Next: Problem installing EPICS Base 3.14.12.1 on Cygwin/Win XP (32bit) Zhan Zhang
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: trouble with 64-bit Window7 Matt Newville
Next: Problem installing sscan 2-6-6 on cygwin Zhan Zhang
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·