Experimental Physics and
Industrial Control System

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