Re: monitors on array variables

["Mooney, Tim M. via Tech-talk" <tech-talk at aps.anl.gov>]

Are you by any chance handling the arrays internally so that they might be referenced by pointers to different addresses at different times?  I didn't say that very clearly; let me give an example: the sscan record double buffers arrays, so that data from a single detector can be stored in either of two locations.  Ned Arnold found that both locations must be posted every time, because we don't know with what address a PV was associated at the time a CA client subscribed to a monitor on that PV.  Clients actually end up subscribing to an address, rather than a PV name.  So, for each array PV, you must post every address that cvt_dbaddr() has ever associated with it.

Tim Mooney (mooney at anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Siddons, David via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, March 23, 2020 12:32 PM
To: Rivers, Mark L. <rivers at cars.uchicago.edu>; Michael Davidsaver <mdavidsaver at gmail.com>
Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: monitors on array variables

 

Hi Mark, Michael,

   Adding Michaels post-all command at the end of process() and special() made things update properly. Also, replacing that command at the end of special() with scanOnce() had the same effect. I'm afraid I don't understand things deeply enough to know why the individual posts didn't work. I would offer to send the code, but it is long and complicated and I don't want to bother you with it. At least I can move forward with other implementation details still to be done. If you have any further suggestions for things to try I'd be grateful.

Thanks,

Pete.

---

From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Thursday, March 19, 2020 1:53 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

 

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