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  2011  2012  2013  2014  <20152016  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  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: EPICS UIs in the context of changing enum record identifiers
From: Jameson Graef Rollins <[email protected]>
To: "Mooney\, Tim M." <[email protected]>, EPICS tech-talk <[email protected]>
Date: Wed, 01 Apr 2015 11:39:04 -0700
On Wed, Apr 01 2015, "Mooney, Tim M." <[email protected]> wrote:
> I have this problem in several databases, and ran into it again in the development of caputRecorder.  I'm not ready to jump into MEDM source code to fix this either.
>
> The best solution I've been able to come up with is to make two nearly identical MEDM displays, and put a related display button - labelled "Refresh Menus", with "Remove Parent Display" checked - on each of them, to bring up the other one.  This gets the enum menus updated.
>
> The next problem is how to tell the user when the "Refresh Menus" button needs to be pressed.  I have the application that writes to the enum PVs set a PV that results in the flashing message "Press Refresh", on the MEDM display near the "Refresh Menus" button.  (It might be better to have the database itself detect writes to the enum strings.  My application doesn't need this, so I didn't bother with it.)
>
> The next problem is how to detect that the user pressed "Refresh Menus", and to rescind the flashing-message PV value.  I did this with a subroutine record, with a subroutine that looks at the first five elements of the MLIS field, and clears the flashing-message PV when any element changes.  A PV from the subroutine record is displayed on both MEDM displays, so MEDM will be in the record's monitor list.  This solution works well for a single display.
>
> The solution doesn't work well for multiple displays, though, because when ANY display that monitors the subroutine record is closed or opened, the monitor list changes, and the flashing message goes away on ALL such displays.  This is good enough for caputRecorder, because there is an additional line of defense: the menu selection is displayed in a PV, and actually acting on the menu selection requires a separate caput.

Thanks so much for the detailed suggestion, Tim.  We have thought about
solutions exactly like this as well.  The problem is that we tend to
have many client applications open simultaneously, so unfortunately this
won't work for the reasons you describe above.

jamie.

Attachment: signature.asc
Description: PGP signature


References:
EPICS UIs in the context of changing enum record identifiers Jameson Graef Rollins
RE: EPICS UIs in the context of changing enum record identifiers Mooney, Tim M.

Navigate by Date:
Prev: RE: EPICS UIs in the context of changing enum record identifiers Jameson Graef Rollins
Next: Re: EPICS UIs in the context of changing enum record identifiers Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: EPICS UIs in the context of changing enum record identifiers Mooney, Tim M.
Next: data of modbus write function didn't updated automatically JaeRyong Seo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·