What happens if you change the value of the PV, either from a caput from the Linux shell. Does ADM then display the correct value? What if you change it from EDM itself?
Mark
________________________________________
From: [email protected] [[email protected]] on behalf of Zenon Szalata [[email protected]]
Sent: Friday, May 10, 2013 12:05 AM
To: [email protected]
Subject: EDM
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
- Replies:
- Re: EDM Zenon Szalata
- References:
- EDM Zenon Szalata
- Navigate by Date:
- Prev:
Re: epicsTimeGetEvent failed Michael Davidsaver
- Next:
EPICS baseR3.14.12 build error Lai Longwei
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EDM Zenon Szalata
- Next:
Re: EDM Zenon Szalata
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|