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  <20182019  2020  2021  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  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Problems with scaler record on epics archiver
From: Mark Rivers <[email protected]>
To: Gabriel de Souza Fedel <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 25 Jan 2018 13:14:25 +0000
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: [email protected] <[email protected]> on behalf of Gabriel de Souza Fedel <[email protected]>
Sent: Thursday, January 25, 2018 4:51 AM
To: [email protected]
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)
[email protected] | +55 (19) 3512 1226
www.lnls.cnpem.br<http://www.lnls.cnpem.br>

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

Navigate by Date:
Prev: Re: CalcOut record update to another record Mark Rivers
Next: Re: Problems with scaler record on epics archiver Mark Rivers
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  2021  2022  2023  2024 
Navigate by Thread:
Prev: Problems with scaler record on epics archiver Gabriel de Souza Fedel
Next: Re: Problems with scaler record on epics archiver Mark Rivers
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  2021  2022  2023  2024 
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 ·