Experimental Physics and
| |||||||||||||||||
|
Hi Michael, No, this is all on a stand-alone system with a
private network. As Mark suggested, I shut down the IOC, and
caget times out, so there is only one IOC running. "dbl" only
shows one instance of det1. I have been misled by the
limitations of iocsh to list arrays. It only lists the first 200
values, and doesn't accept the [] element filter, so I take back
the statement that the data is different inside and out; sorry
for wasting your time. To test Michael's idea of a global db_post, I
inserted that statement at the end of the "special" switch
statement, so any time special() was invoked it should be
executed. Changing almost any parameter causes that to be
executed, since most of the PVs in the record are handled there.
I have attached the result of "dbpr det1 4" so maybe you can
spot a misconfiguration. All of the PVs which are single valued get posted properly. It is only the arrays which fail to be updated. I have only focused on three array variables in these discussions: MCA, SPCT and TDC, since they are the ones I want to watch on a display. Pete.
On 3/19/20 11:35 AM, Michael Davidsaver
wrote:
On 3/19/20 7:51 AM, D. Peter Siddons wrote:Hi Michael, I tried that and it didn't change anything. However, I discovered that accessing some variables from the iocsh gave different results from caget, so I must have some name confusion in my code. Thanks for your help, at least I discovered this!You don't by chance have more than one instance of this IOC running? Or otherwise have two IOC instances serving the same record names?Pete. On 3/18/20 6:25 PM, Michael Davidsaver wrote:FYI. passing NULL instead of a field address to db_post_events() will post to every subscription on the record regardless of field. Trying this should give a clear indication if the only problem is the wrong field address. I guess the other variable is event mask. SOdb_post_events(pscal,NULL,0xf);should post to every subscriber to this record regardless of field or mask. On 3/18/20 12:02 PM, Mark Rivers wrote:Could this be a problem with EPICS_CA_MAX_ARRAY_BYTES? What if you do: camonitor -#20 det1.SPCT ________________________________ From: Siddons, David <siddons at bnl.gov> Sent: Wednesday, March 18, 2020 1:51 PM To: Mark Rivers; Michael Davidsaver Cc: EPICS Tech-Talk Subject: Re: monitors on array variables Hi Mark, Yes, I did that. THis is essentially an expanded scaler record. In updateCounts I have: Debug(5, "updateCounts: posting scaler values %d\n",0); /* copy and post spectrum values */ for (i=0; i<4096; i++) { if (mca[4096*pscal->monch+i] != spct[i]) { spct[i]=mca[4096*pscal->monch+i]; } } db_post_events(pscal,&pscal->mca,DBE_VALUE); db_post_events(pscal,&pscal->tdc,DBE_VALUE); db_post_events(pscal,&pscal->spct,DBE_VALUE); etc, It gives this output: ../zDDMRecord.c(818):updateCounts: called by process() ../zDDMRecord.c(830):updateCounts: got counts[] 0 ../zDDMRecord.c(838):updateCounts: posting scaler values 0 ../zDDMRecord.c(866):updateCounts: exit 0 Running camonitor on det1.SPCT reads the initial values and waits. Triggering a change (by changing monch) results in nothing. It just sits there. I can verify that the values have changed by doing a caget, or a dbgf on the console: peter@peter-Latitude-E7240: ~/$ caput det1.MONCH 0 Old : det1.MONCH 5 New : det1.MONCH 0 peter@peter-Latitude-E7240: ~/$ caget det1.SPCT[1:20] det1.SPCT[1:20] 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 peter@peter-Latitude-E7240: ~/$ caput det1.MONCH 5 Old : det1.MONCH 0 New : det1.MONCH 5 peter@peter-Latitude-E7240:~/$ caget det1.SPCT[1:20] det1.SPCT[1:20] 20 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 I guess I'm doing something dumb, but I can't see it. Pete. ________________________________ From: Mark Rivers <rivers at cars.uchicago.edu> Sent: Wednesday, March 18, 2020 2:25 PM To: Siddons, David <siddons at bnl.gov>; Michael Davidsaver <mdavidsaver at gmail.com> Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov> Subject: Re: monitors on array variables Can you put some debugging to be sure db_post_events is actually being called, while at the same time running camonitor to see if gets an update? ________________________________ From: Siddons, David <siddons at bnl.gov> Sent: Wednesday, March 18, 2020 1:09 PM To: Michael Davidsaver; Mark Rivers Cc: EPICS Tech-Talk Subject: Re: monitors on array variables .....and I have, in cvt_dbaddr(): case zDDMRecordSPCT:{ paddr->pfield = (void *)(pzDDM->pspct); paddr->no_elements = 4096; /* One spectrum for real-time display */ paddr->field_type = DBF_LONG; paddr->field_size = sizeof(int); paddr->dbr_field_type = DBR_LONG; break; Pete. ________________________________ From: Michael Davidsaver <mdavidsaver at gmail.com> Sent: Wednesday, March 18, 2020 12:54 PM To: Mark Rivers <rivers at cars.uchicago.edu>; Siddons, David <siddons at bnl.gov> Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov> Subject: Re: monitors on array variables On 3/18/20 9:47 AM, Mark Rivers wrote:by analogy waveformRecord hasdb_post_events(prec, &prec->val, monitor_mask);note 'val' not 'bptr'.The mca record has worked with no changes in 3.14, 3.15, and 7.0.3 with these lines: mcaRecord.dbd: recordtype(mca) { include "dbCommon.dbd" field(VERS,DBF_DOUBLE) { prompt("Code Version") special(SPC_NOMOD) initial("1") } field(VAL,DBF_NOACCESS) { prompt("Value") special(SPC_DBADDR) pp(TRUE) size(4) extra("void *val") } field(BPTR,DBF_NOACCESS) { prompt("Buffer Pointer") special(SPC_NOMOD) interest(4) size(4) extra("void *bptr") } mcaRecord.c: if (MARKED(M_VAL)) db_post_events(pmca,pmca->bptr,monitor_mask); So it is posting monitors on the bptr field, not the val field, and it seems to work fine. It looks like Pete is doing what the mca record does, but it is not working. Why?Ah, there is a second piece to the puzzle. db_post_events() must be called with whatever address is in DBADDR::pfield which by default in this case is '&val' but this can be changed in the cvt_dbaddr callback. Indeed waveformRecord used to do this. https://github.com/epics-base/epics-base/commit/92d52cc415599b7dffa7df1f23d5ba8227fb4d3a ACKS: NO_ALARM ACKT: YES ASG: ASP: (nil) BKPT: 00 CALF: CARD: 0 CHAN: 0 CHEN: (nil) CHIP: 0 CNT: Done CONT: OneShot COUT:CONSTANT COUTP:CONSTANT DESC: DISA: 0 DISP: 0 DISS: NO_ALARM DISV: 1 DLY: 0 DLY1: 0 DPVT: 0x559d9b90d640 DSET: 0x7f3135053280 DTYP: NSLS detector EBLK: Off EGU: counts EVNT: EXSIZE: 4096 EYSIZE: 384 FLNK:CONSTANT 0 FNAM: FREQ: 1000000 FVER: 0 GAIN: 75keV GMON: Off INP:VME_IO #C0 S1 @384 LCNT: 0 LOAO: Pulse LSET: 0x559d9b907640 MCA: (nil) MFS: Off MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MLOK: 70 7c 90 9b 9d 55 00 00 MODE: Framing MONCH: 0 NAME: det1 NCH: 384 NCHIPS: 12 NELM: 384 NSEV: NO_ALARM NSTA: NO_ALARM OFFS: (nil) OUT:CONSTANT PACT: 0 PCHEN: 0x559d9b907ca0 PCNT: Done PHAS: 0 PINI: NO PMCA: 0x7f31316c4010 POFFS: 0x559d9b9085d0 PPN: (nil) PPNR: (nil) PPUTR: 0x559d9b909230 PR1: 1000000 PREC: 0 PRIO: LOW PROC: 0 PSLP: 0x559d9b907fc0 PSPCT: 0x559d9b9093c0 PTDC: 0x7f3131543010 PTHRSH: 0x559d9b9091f0 PTHTR: 0x559d9b908be0 PTSEN: 0x559d9b907e30 PUEN: Disable PUTF: 0 PUTR: (nil) RAT1: 0 RATE: 2 RDES: 0x559d9b895e90 RPRO: 0 RPVT: 0x559d9b90d3d0 RSET: 0x7f3135053300 RUNNO: 0 SCAN: Passive SDIS:CONSTANT SEVR: INVALID SHPT: 0.5us SLP: (nil) SPCT: (nil) SPVT: (nil) SS: 0 STAT: UDF T: 0 TDC: (nil) TDM: Time of arrival TDS: 1us THRSH: (nil) THTR: (nil) TIME: <undefined> TP: 1 TP1: 1 TPAMP: 0 TPCNT: 0 TPENB: Off TPFRQ: 0 TPRO: 0 TSE: 0 TSEL:CONSTANT TSEN: (nil) TXSIZE: 1024 TYSIZE: 384 UDF: 1 UDFS: INVALID US: 0 VAL: 0 VERS: 1
| ||||||||||||||||
ANJ, 19 Mar 2020 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |