![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
Thanks Mark. I shall investigate. John
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Friday, June 21, 2024 5:30:37 PM To: John Dobbins <john.dobbins at cornell.edu>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov> Subject: RE: mbbo fields don't match db definitions ???
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>
Mark,
Previously, 'Software' was a trigger choice. So something in the camera changed so that this is not now a choice?
John
From: Mark Rivers <rivers at cars.uchicago.edu>
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
From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of John Dobbins via Tech-talk
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
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") }
| ||||||||||||||
ANJ, 21 Jun 2024 |
![]() · Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |