Pete,
The dbpr output you sent has this:
SEVR: INVALID
STAT: UDF
TIME: <undefined>
This means the record has not yet processed. Can you
send the same output after the record has processed?
Are you saying now that caget and the iocsh command
agree, but you just don't get callbacks? Can you send
the iocsh command and caget command outputs?
Mark
________________________________
From: D. Peter Siddons
<siddons at bnl.gov>
Sent: Thursday, March 19, 2020 12:13 PM
To: Michael Davidsaver
Cc: Mark Rivers; EPICS Tech-Talk
Subject: Re: monitors on array variables
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. 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><mailto: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><mailto:rivers at cars.uchicago.edu>
Sent: Wednesday, March 18, 2020 2:25 PM
To: Siddons, David
<siddons at bnl.gov><mailto:siddons at bnl.gov>;
Michael Davidsaver
<mdavidsaver at gmail.com><mailto:mdavidsaver at gmail.com>
Cc: EPICS Tech-Talk
<tech-talk at aps.anl.gov><mailto: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><mailto: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><mailto:mdavidsaver at gmail.com>
Sent: Wednesday, March 18, 2020 12:54 PM
To: Mark Rivers
<rivers at cars.uchicago.edu><mailto:rivers at cars.uchicago.edu>;
Siddons, David
<siddons at bnl.gov><mailto:siddons at bnl.gov>
Cc: EPICS Tech-Talk
<tech-talk at aps.anl.gov><mailto: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