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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: monitors on array variables |
From: | "Siddons, David via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu>, Michael Davidsaver <mdavidsaver at gmail.com> |
Cc: | EPICS Tech-Talk <tech-talk at aps.anl.gov> |
Date: | Wed, 18 Mar 2020 19:09:26 +0000 |
Same result. I had it set to a big number to handle the full 384*4096 array of spectra for all the channels (this is for Maia-II). Anyhow, camonitor would complain if that were the case.
Pete.
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, March 18, 2020 3:02 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 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 has >>> db_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 |