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  <20182019  2020  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  <20182019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Problems with scaler record on epics archiver
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Gabriel de Souza Fedel <gabriel.fedel@lnls.br>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Thu, 25 Jan 2018 13:23:15 +0000
Note that if you can configure the archiver to also archive the Sn fields whenever it receives a monitor callback on the VAL field then you will get the final values of the Sn fields, not the initial value.


Mark



________________________________
From: Mark Rivers
Sent: Thursday, January 25, 2018 7:14 AM
To: Gabriel de Souza Fedel; tech-talk@aps.anl.gov
Cc: Tim Mooney
Subject: Re: Problems with scaler record on epics archiver


Hi Gabriel,

I don't use the archiver, but I just tested the timestamp behavior using camonitor.

The problem is that record timestamp is set when the scaler finishes counting.  But at that time it has already posted the monitors on most fields before it updates the timestamp.  The only field it posts after updating the timestamp is the VAL field, which is the same as the .T (elapsed count time) field.

Here is the output of camonitor on the .S1 and .VAL fields for 2 count cycles separated by about 18 seconds.  Note that at the end of the first count cycle VAL has a timestamp of 2018-01-25 07:05:48.177187.  This is the same timestamp that the .S1 field has in the next count cycle, including the final count.  At the end of the second count cycle the VAL timestamp changes to 2018-01-25 07:05:54.660520.

13BMD:scaler2.S1               2018-01-25 07:05:30.493854 1693
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 4.65572e+06
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 9.65038e+06
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 1.465e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 1.96535e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 2.46506e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 2.96553e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 3.46507e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 3.96508e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 4.46644e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 4.96498e+07
13BMD:scaler2.S1               2018-01-25 07:05:30.493854 5e+07
13BMD:scaler2.VAL              2018-01-25 07:05:48.177187 1

13BMD:scaler2.S1               2018-01-25 07:05:48.177187 2608
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 4.83973e+06
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 9.83988e+06
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 1.48423e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 1.98382e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 2.48422e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 2.9838e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 3.48383e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 3.984e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 4.4837e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 4.90021e+07
13BMD:scaler2.S1               2018-01-25 07:05:48.177187 5e+07
13BMD:scaler2.VAL              2018-01-25 07:05:54.660520 1


This is the code in the scaler record process() function:

/* done counting? */
if (pscal->ss == SCALER_STATE_IDLE) {
recGblGetTimeStamp(pscal);
do_alarm(pscal);
monitor(pscal);
if ((pscal->pcnt==0) && (pscal->us == USER_STATE_IDLE)) {
if (prev_scaler_state == SCALER_STATE_COUNTING) {
pscal->val = pscal->t;
db_post_events(pscal,&(pscal->val),DBE_VALUE);
}
recGblFwdLink(pscal);
}
}

It seems like it would be better to wait to post the final count values until after the timestamp has been updated.  Perhaps Tim Mooney can comment, since it might be a bit complicated to do that.

Mark





________________________________
From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Gabriel de Souza Fedel <gabriel.fedel@lnls.br>
Sent: Thursday, January 25, 2018 4:51 AM
To: tech-talk@aps.anl.gov
Subject: Problems with scaler record on epics archiver

Hi,

I'm having problems with scaler record on epics archiver.
Archiver doesn't record values from this PVs, just the first value (when
start archiving).
I tried to change to scan mode and didn't work too.

I'm think the problem is related to scaler timestamp behavior (the
timestamp doesn't change when PV is counting).

Has anyone had problems like this?


Regards

--
Gabriel Fedel
Software de Operação das Linhas de Luz
Laboratório Nacional de Luz Síncrotron - (LNLS)
Centro Nacional de Pesquisa em Energia e Materiais (CNPEM)
gabriel.fedel@lnls.br | +55 (19) 3512 1226
www.lnls.cnpem.br<http://www.lnls.cnpem.br>

References:
Problems with scaler record on epics archiver Gabriel de Souza Fedel
Re: Problems with scaler record on epics archiver Mark Rivers

Navigate by Date:
Prev: Re: Problems with scaler record on epics archiver Mark Rivers
Next: IOC error Thomas, Patrick
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  <20182019  2020 
Navigate by Thread:
Prev: Re: Problems with scaler record on epics archiver Mark Rivers
Next: Re: Problems with scaler record on epics archiver Mooney, Tim M.
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  <20182019  2020 
ANJ, 25 Jan 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·