Re: EPICS UIs in the context of changing enum record identifiers

[Pete Jemian <jemian@anl.gov>]

We encountered this same situation when building controls for the XIA 
PF4 filter (attenuator) box.  The PF4 allows one to place 4 separate 
foils into the beam.  The X-ray attenuation of the PF4 is based on the 
combination of foils in the beam.  Attenuation varies by X-ray 
wavelength, thus the nice text on the MBBO button labels would change, 
ideally, when the X-ray wavelength is changed.  (A SNL program computes 
the values.)

Our work around was to place the changeable text in stringout labels 
next to each mbbo radiobutton value.  Not our first choice for controls 
but acceptable to the users.

see the example "pf4Bankmore.adl" screen in the synApps optics module:

https://subversion.xray.aps.anl.gov/synApps/optics/trunk/opticsApp/op/adl/pf4Bankmore.adl

Pete


On 4/1/2015 11:53 AM, Jameson Graef Rollins wrote:
> 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.

--
----------------------------------------------------------
Pete R. Jemian, Ph.D.                <jemian@anl.gov>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source,   Argonne National Laboratory
Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
   Education is the one thing for which people
      are willing to pay yet not receive.
-----------------------------------------------------------