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. SO
>>
>>> db_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 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
>>>
- Replies:
- Re: monitors on array variables D. Peter Siddons via Tech-talk
- References:
- monitors on array variables Siddons, David via Tech-talk
- Re: monitors on array variables Michael Davidsaver via Tech-talk
- Re: monitors on array variables Michael Davidsaver via Tech-talk
- Re: monitors on array variables Siddons, David via Tech-talk
- Re: monitors on array variables Mark Rivers via Tech-talk
- Re: monitors on array variables Siddons, David via Tech-talk
- Re: monitors on array variables Mark Rivers via Tech-talk
- Re: monitors on array variables Michael Davidsaver via Tech-talk
- Re: monitors on array variables D. Peter Siddons via Tech-talk
- Navigate by Date:
- Prev:
Re: monitors on array variables D. Peter Siddons via Tech-talk
- Next:
Re: error calling dbGetLinkValue in EPICS base-3.15.6 Johnson, Andrew N. via Tech-talk
- 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: monitors on array variables D. Peter Siddons via Tech-talk
- Next:
Re: monitors on array variables D. Peter Siddons via Tech-talk
- 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
|