- Previously, 'Software' was a trigger choice. So something in the camera changed so that this is not now a choice?
Yes, I think some other parameter in the camera has changed so that software is no longer a valid choice.
Note that at run-time you actually have 2 fewer choices than in the template file. The template file has 15 choices, i.e. TTxx (13) and FTxx (14) are valid. But at run-time TTxx and FTxx are not valid.
It appears that the missing (invalid) entries are Software and Line1.
Mark
From: John Dobbins <john.dobbins at cornell.edu>
Sent: Friday, June 21, 2024 4:21 PM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk at aps.anl.gov
Subject: Re: mbbo fields don't match db definitions ???
Previously, 'Software' was a trigger choice. So something in the camera changed so that this is not now a choice?
John,
What you are seeing is completely normal.
The template file is created by the Python script using the camera’s XML file. That XML file contains all possible choices for each enum. However, not all of those choices are necessarily available at run time, depending
on the camera state. The enum choices in the record at run-time are dynamic, based on which choices are actually available for the current camera configuration.
Note that with older OPIs like medm you will need to close and re-open the window to see the new enum choices. On newer OPIs like Phoebus the enum choices update in the display when they are changed without needing to close
and re-open the window.
Mark
All,
I am using a FLIR camera with base-7.0.6, areaDetector-R3-13, ADGeniCam-R1-9, ADSpinnake-R3-5 on Alma 9.
This IOC has been running normally but after a restart of the IOC I am seeing a strange problem I have not encountered before. On start-up the IOC loads an mmbo record from FLIR_BFS_U3_161S7M.template
but the fields in the instantiated record don't match the database file. [ this doesn't appear to be the only affected record ]
The instantiated record has 13 states where I expect 14. The first state has been lost and all the others are shifted down one with respect to the definition in the template file.
I could imagine the record being over-written later by another db file. I don't see how that would come about when it was ok previously. Is there a way to tell if this is happening?
Any thoughts,
John Dobbins
Research Support Specialist
Cornell High Energy Synchrotron Source
Cornell University
www.chess.cornell.edu
dbLoadRecords("/nfs/chess/epics/det/support_flir/areaDetector-R3-13/ADGenICam/db/FLIR_BFS_U3_161S7M.template", "P=BFS1:,R=cam1:,PORT=SP1")
epics> dbpr BFS1:cam1:GC_TriggerSource 4 [0/376]
ACKS: NO_ALARM ACKT: YES AMSG: ASG :
ASP : PTR (nil) BKLNK: ELL 0 [(nil) .. (nil)] BKPT: 00
COSV: NO_ALARM DESC: DISA: 0 DISP: 0
DISS: NO_ALARM DISV: 1 DOL : CONSTANT 31 DPVT: PTR 0x53c4dc0
DSET: PTR 0x7f9ca58af220 DTYP: asynInt32 EIST: Counter1Start
EISV: NO_ALARM EIVL: 0xd ELST: LogicBlock0 ELSV: NO_ALARM
ELVL: 0x14 EVNT: FFST: FFSV: NO_ALARM
FFVL: 0x0 FLNK: CONSTANT FRST: UserOutput1 FRSV: NO_ALARM
FRVL: 0x5 FTST: FTSV: NO_ALARM FTVL: 0x0
FVST: UserOutput2 FVSV: NO_ALARM FVVL: 0x6
IVOA: Continue normally IVOV: 0 LALM: 0
LCNT: 0 LSET: PTR 0x45da5d0 MASK: 4294967295
MLIS: ELL 0 [(nil) .. (nil)] MLOK: a0 51 71 04 00 00 00 00
MLST: 0 NAME: BFS1:cam1:GC_TriggerSource NAMSG:
NIST: Counter0End NISV: NO_ALARM NIVL: 0x10 NOBT: 0
NSEV: NO_ALARM NSTA: NO_ALARM OLDSIMM: NO OMSL: supervisory
ONST: Line2 ONSV: NO_ALARM ONVL: 0x2 ORAW: 0
ORBV: 0 OUT : INST_IO @asyn(SP1,0,1)GC_E_TriggerSource
PACT: 0 PHAS: 0 PINI: NO PPN : PTR (nil)
PPNR: PTR (nil) PRIO: LOW PROC: 0 PUTF: 0
RBV : 0 RDES: PTR 0x22fcdb0 RPRO: 0
RSET: PTR 0x7f9ca571d260 RVAL: 0 SCAN: Passive
SDEF: 1 SDIS: CONSTANT SDLY: -1 SEVR: NO_ALARM
SHFT: 0 SIML: CONSTANT SIMM: NO SIMPVT: PTR (nil)
SIMS: NO_ALARM SIOL: CONSTANT SPVT: PTR (nil) SSCN: <nil>
STAT: NO_ALARM SVST: Counter0Start SVSV: NO_ALARM SVVL: 0xc
SXST: UserOutput3 SXSV: NO_ALARM SXVL: 0x7 TEST: Counter1End
TESV: NO_ALARM TEVL: 0x11 THST: UserOutput0 THSV: NO_ALARM
THVL: 0x4 TIME: 2024-06-21 15:16:03.150013012 TPRO: 0
TSE : 0 TSEL: CONSTANT TTST: TTSV: NO_ALARM
TTVL: 0x0 TVST: LogicBlock1 TVSV: NO_ALARM TVVL: 0x15
TWST: Line3 TWSV: NO_ALARM TWVL: 0x3 UDF : 0
UDFS: INVALID UNSV: NO_ALARM UTAG: 0 VAL : 0
ZRST: Line0 ZRSV: NO_ALARM ZRVL: 0x0
record(mbbo, "$(P)$(R)GC_TriggerSource") {
field(DTYP, "asynInt32")
field(OUT, "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))GC_E_TriggerSource")
field(DOL, "31")
field(ZRST, "Software")
field(ZRVL, "31")
field(ONST, "Line0")
field(ONVL, "0")
field(TWST, "Line1")
field(TWVL, "1")
field(THST, "Line2")
field(THVL, "2")
field(FRST, "Line3")
field(FRVL, "3")
field(FVST, "UserOutput0")
field(FVVL, "4")
field(SXST, "UserOutput1")
field(SXVL, "5")
field(SVST, "UserOutput2")
field(SVVL, "6")
field(EIST, "UserOutput3")
field(EIVL, "7")
field(NIST, "Counter0Start")
field(NIVL, "12")
field(TEST, "Counter1Start")
field(TEVL, "13")
field(ELST, "Counter0End")
field(ELVL, "16")
field(TVST, "Counter1End")
field(TVVL, "17")
field(TTST, "LogicBlock0")
field(TTVL, "20")
field(FTST, "LogicBlock1")
field(FTVL, "21")
field(DISA, "0")
}