EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20202021  2022  2023  2024  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  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: monitors on array variables
From: "D. Peter Siddons via Tech-talk" <tech-talk at aps.anl.gov>
To: Michael Davidsaver <mdavidsaver at gmail.com>
Cc: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Date: Thu, 19 Mar 2020 13:13:13 -0400

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>
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


ACKS: NO_ALARM      ACKT: YES           ASG:                ASP: (nil)          
BKPT: 00            CALF:               CARD: 0             CHAN: 0             
CHEN: (nil)         CHIP: 0             CNT: Done           CONT: OneShot       
COUT:CONSTANT       COUTP:CONSTANT      DESC:               DISA: 0             
DISP: 0             DISS: NO_ALARM      DISV: 1             DLY: 0              
DLY1: 0             DPVT: 0x559d9b90d640                    DSET: 0x7f3135053280
DTYP: NSLS detector EBLK: Off           EGU: counts         EVNT:               
EXSIZE: 4096        EYSIZE: 384         FLNK:CONSTANT 0     FNAM:               
FREQ: 1000000       FVER: 0             GAIN: 75keV         GMON: Off           
INP:VME_IO #C0 S1 @384                  LCNT: 0             LOAO: Pulse         
LSET: 0x559d9b907640                    MCA: (nil)          MFS: Off            
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00               
MLOK: 70 7c 90 9b 9d 55 00 00           MODE: Framing       MONCH: 0            
NAME: det1          NCH: 384            NCHIPS: 12          NELM: 384           
NSEV: NO_ALARM      NSTA: NO_ALARM      OFFS: (nil)         OUT:CONSTANT        
PACT: 0             PCHEN: 0x559d9b907ca0                   PCNT: Done          
PHAS: 0             PINI: NO            PMCA: 0x7f31316c4010                    
POFFS: 0x559d9b9085d0                   PPN: (nil)          PPNR: (nil)         
PPUTR: 0x559d9b909230                   PR1: 1000000        PREC: 0             
PRIO: LOW           PROC: 0             PSLP: 0x559d9b907fc0                    
PSPCT: 0x559d9b9093c0                   PTDC: 0x7f3131543010                    
PTHRSH: 0x559d9b9091f0                  PTHTR: 0x559d9b908be0                   
PTSEN: 0x559d9b907e30                   PUEN: Disable       PUTF: 0             
PUTR: (nil)         RAT1: 0             RATE: 2             RDES: 0x559d9b895e90
RPRO: 0             RPVT: 0x559d9b90d3d0                    RSET: 0x7f3135053300
RUNNO: 0            SCAN: Passive       SDIS:CONSTANT       SEVR: INVALID       
SHPT: 0.5us         SLP: (nil)          SPCT: (nil)         SPVT: (nil)         
SS: 0               STAT: UDF           T: 0                TDC: (nil)          
TDM: Time of arrival                    TDS: 1us            THRSH: (nil)        
THTR: (nil)         TIME: <undefined>   TP: 1               TP1: 1              
TPAMP: 0            TPCNT: 0            TPENB: Off          TPFRQ: 0            
TPRO: 0             TSE: 0              TSEL:CONSTANT       TSEN: (nil)         
TXSIZE: 1024        TYSIZE: 384         UDF: 1              UDFS: INVALID       
US: 0               VAL: 0              VERS: 1             

Replies:
Re: monitors on array variables Mark Rivers 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
Re: monitors on array variables Michael Davidsaver via Tech-talk

Navigate by Date:
Prev: Re: error calling dbGetLinkValue in EPICS base-3.15.6 Johnson, Andrew N. via Tech-talk
Next: Re: monitors on array variables Mark Rivers 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  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: monitors on array variables Michael Davidsaver via Tech-talk
Next: Re: monitors on array variables Mark Rivers 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  <20202021  2022  2023  2024 
ANJ, 19 Mar 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·