Re: EDM

[Zenon Szalata <zms@slac.stanford.edu>]

Hi Bruce,
Yes, they do look the same, except the fields where they should be 
different.
My first reaction was that it is something to do with the fact that the 
record is in an invalid state.  But they all are.  So I am trying to 
understand why is this one singled out.
EDM edit properties dialog shows no difference between the Text Control 
which shows correct value and the one that does not.
Thank you,
Zen

On 05/10/13 01:50, Bruce Hill wrote:
> Hi Zen,
> Are all the other PV's also UDF with SEVR Invalid?
> If not, that might explain the difference.
>
> If they're all UDF, it might be due to some setting that's different
> on that edm text control widget.
>
> Regards,
> - Bruce
>
> On 5/9/2013 10:05 PM, Zenon Szalata wrote:
> > I have a peculiar problem which I fail to understand.
> > I am using EPICS R3.14.12.2, EDM 1-12-56.
> > I have a few longout records which are created from the same template.
> > After the IOC is initialized, these longout records have non zero
> > values.  The records are controlled via EDM Text Control widgets.  At
> > this point, no user entries were made.  I could explain how these
> > records got the initial values, but that is probably not relevant.  When
> > I start an EDM screen which has the Text Controls, one of the controls
> > shows value of zero.  caget on this record shows a non zero value. I got
> > the PV name for the caget command by middle clicking on the Text
> > Control. Yet, all the other Text Controls show the correct non zero
> > values which are the values that I verified with both caget and dbpr
> > commands.   The Text Controls were created by copy and paste, all the
> > records were created from the same template.
> > Restarting EDM does not help.  Putting EDM in edit mode and back in
> > execute mode does not help; the value zero is stubbornly displayed and
> > just for this one PV.
> >
> > Here is dbpr output for the record in question:
> >
> > epics> dbpr ESA:LO:SC:2531-21:CH1:MAXV-WR:DATA,5
> > ACKS: NO_ALARM      ACKT: YES           ADEL: 0             ALST: 0
> > ASG:                ASP: (nil)          BKPT: 00            DESC:
> > MaxVelocity:
> > DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1
> > DOL:CONSTANT        DPVT: (nil)         DRVH: 0             DRVL: 0
> > DSET: 0x7f8994126760                    DTYP: Soft Channel EGU:
> > EVNT: 0             FLNK:DB_LINK ESA:LO:2531-21:CH1:MAXV-WR:REG
> > HHSV: NO_ALARM      HIGH: 0             HIHI: 0             HOPR: 0
> > HSV: NO_ALARM       HYST: 0             IVOA: Continue normally
> > IVOV: 0             LALM: 0             LCNT: 0             LLSV: NO_ALARM
> > LOLO: 0             LOPR: 0             LOW: 0              LSET: 0x136f8c0
> > LSV: NO_ALARM       MDEL: 0
> > MLIS: c0 69 02 20 89 7f 00 00 30 5e 02 20 89 7f 00 00 02 00 00 00
> > MLOK: 50 64 29 01 00 00 00 00           MLST: 0
> > NAME: ESA:LO:SC:2531-21:CH1:MAXV-WR:DATA                    NSEV: NO_ALARM
> > NSTA: NO_ALARM      OMSL: supervisory   OUT:CONSTANT        PACT: 0
> > PHAS: 0             PINI: NO            PPN: (nil)          PPNR: (nil)
> > PRIO: LOW           PROC: 0             PUTF: 0             RDES: 0x10b1220
> > RPRO: 0             RSET: 0x7f8994362180                    SCAN: Passive
> > SDIS:CONSTANT       SEVR: INVALID       SIML:CONSTANT       SIMM: NO
> > SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: (nil)         STAT: UDF
> > TIME: <undefined>   TPRO: 0             TSE: 0 TSEL:CONSTANT
> > UDF: 0              VAL: 50
> >
> > dbpr output for the other records (which don't show this problem) looks
> > identical for all practical purposes.
> > Any suggestion as to the nature of the problem and how to over come it,
> > would be much appreciated.
> > Zen