Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Wed, 1 Apr 2015 17:36:26 +0000

Hi Jamie,

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.

This solution works with both MEDM and caQtDM.

Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

________________________________________
From: [email protected] [[email protected]] on behalf of Jameson Graef Rollins [[email protected]]
Sent: Wednesday, April 01, 2015 11:53 AM
To: EPICS tech-talk
Subject: EPICS UIs in the context of changing enum record identifiers

Hi, all.  We have an application that employs an enum record as a
control interface (for submitting a request to the program).  The
application can be manually prompted to reload it's configuration, which
can occasionally cause the elements of the control enum to change
(desired behavior).

The problem is that our operator interfaces (primarily MEDM at the
moment) do not behave well in the context of these enum change.  All
MEDM enum controller objects retrieve enum identifiers only once at
startup.  This means they become stale after the enum changes, and more
dangerously, allow the user to select one element that is actually
mapped to another.  This has created quite a few headaches for us.

I've been trying to find a way around this problem, but haven't come up
with anything.  The best solution I have so far involves creating a
screen on the fly that creates a shell command menu with a bunch of
"caput" commands for the strings of enum.  This of course doesn't get
updated on application reload either, but it at least doesn't allow for
selecting a mislabeled element.

I'm soliciting for suggestions about how to create operator interfaces
that behave better in the face of changing enum records.  All operator
interfaces that I've looked at (MEDM, EDM, QTDM) don't behave well.  Any
suggestions of what we could do that don't involve patching MEDM or
creating our own operator interface?

jamie.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System