[Halld-online] question about scalers in the EPICS archiver

Fri Jan 12 15:40:16 EST 2018

Hi Richard,

  EPICS variables are written into the data stream by an external processed launched by CODA when the run is started.
The program is epics2et and is my program (not a CODA product). The list of variables along with the frequency in
which they are written can be seen here:

https://halldsvn.jlab.org/repos/trunk/online/daq/config/monitoring/epics2et.conf <https://halldsvn.jlab.org/repos/trunk/online/daq/config/monitoring/epics2et.conf>

There do not appear to be any TAGGER values that are being written to these events.

There are also some scalers written into special sync events by the ROL in the DAQ. Sasha has
implemented that and I’m not 100% sure of the status. This looks to be  f250 scalers. For 
reference, the ROL has a call to “fa250_scalers()” that can be seen here:

https://halldsvn.jlab.org/repos/trunk/online/daq/vme/src/rol_1/vme_list.c <https://halldsvn.jlab.org/repos/trunk/online/daq/vme/src/rol_1/vme_list.c>

which looks to be defined here:

https://halldsvn.jlab.org/repos/trunk/online/daq/vme/src/rol_1/conf_utils.c <https://halldsvn.jlab.org/repos/trunk/online/daq/vme/src/rol_1/conf_utils.c>

The parsing code looks like it was setup to eventually handle this, but has yet to be filled in. See the 
Parsef250ScalerBank() routine here:

https://github.com/JeffersonLab/sim-recon/blob/master/src/libraries/DAQ/DEVIOWorkerThread.cc <https://github.com/JeffersonLab/sim-recon/blob/master/src/libraries/DAQ/DEVIOWorkerThread.cc>

Sasha will need to comment on whether this feature has been fully implemented and working
and whether it will be suitable for your needs. If so, I can help with getting it put into the parser
to copy the info into an appropriate object.

Regards,
-David

-------------------------------------------------------------
David Lawrence Ph.D.
Staff Scientist, Thomas Jefferson National Accelerator Facility
Newport News, VA
davidl at jlab.org
(757) 269-5567 W
(757) 746-6697 C

> On Jan 12, 2018, at 5:21 AM, Richard Jones <richard.t.jones at uconn.edu> wrote:
> 
> Hovanes,
> 
> Yes, that is the place where it should be done. I will speak with Sasha about it, as I think he has set this up for some subset of the scalers. I don't know of any single document where one can go to answer the question, where do I go to get a record of the scalers in GlueX. 
> 
> -Richard Jones
> 
> On Fri, Jan 12, 2018 at 12:00 AM, Hovanes Egiyan <hovanes.egiyan at gmail.com <mailto:hovanes.egiyan at gmail.com>> wrote:
> Hi Richard,
> In other halls this kind of data is writen to data files usind CODA DAQ.
> I believe we also have that capability.
> Hovanes
> 
> 
> 
> Sent from my Samsung Galaxy Tab® S
> 
> 
> -------- Original message --------
> From: Richard Jones <richard.t.jones at uconn.edu <mailto:richard.t.jones at uconn.edu>> 
> Date: 1/11/18 1:39 PM (GMT-05:00) 
> To: Hovanes Egiyan <hovanes.egiyan at gmail.com <mailto:hovanes.egiyan at gmail.com>> 
> Cc: halld-online at jlab.org <mailto:halld-online at jlab.org> 
> Subject: Re: [Halld-online] question about scalers in the EPICS archiver 
> 
> Hello Hovanes and all,
> 
> This entails a serious loss of precision for long-running tallies. Essentially it means that all we have in EPICS are one-second snapshots every once in a while, between which the values can wander by 3% without any record of having done so. This makes them useless for any kind of normalization, which is what I was hoping to get from them. Suppose I wanted to get the total number of counts accummulated by a scaler over a several hour period, is there any way to get that information from anywhere in our online system right now?
> 
> -Richard
> 
> On Thu, Jan 11, 2018 at 1:28 PM, Hovanes Egiyan <hovanes.egiyan at gmail.com <mailto:hovanes.egiyan at gmail.com>> wrote:
> Richard, 
> 
> The discriminator scalers are latched every second and the units are Hz. Sergey Furletov 
> runs the server that reads the values out into shared memory, so I do not know the details. I believe 
> that the value is non-integral because it gets normalized to a clock to get rates more precisely in Hz. So 
> the square root of the value in the DB for the scaler should be a good estimate of the statistical error. 
> 
> Archiving of the scalers in MYA (or other PVs) has a deadband (for this particular variable it is 
> 3*sqrt(value)+0.03*value), which means that if the next reading (which is indicated by a change in 
> the value of the EPICS variable) is within that deadband of the latest recorded value then it does not get 
> recorded. So, if you stripchart an EPICS variable live, you will see a lot more frequent value changes 
> compared to what you see when you look at the archive chart of the same variable. 
> This is done to reduce the update rate in the DB, otherwise it would cost a lot more money to keep all 
> variables in the DB without any deadbands. The deadbnads are adjustable though, I can request smaller 
> deadbands for a small subset of variables. 
> 
> Hovanes 
> 
> 
> 
> On 01/11/2018 12:41 PM, Richard Jones wrote:
>> Hello Hovanes and all,
>> 
>> I am accessing the GlueX scalers in the EPICS archive using the MYA interface, and have run into a question. I am looking at a variable like TAGM:T:8:scaler_t1 whose name suggests that it is the discriminator scaler for TAGM column 8. When I look at the numbers in that variable, they are obviously not scalers. They are non-integer values in the range of 3000-8000 for the runs that I am looking at. Are they rates? In what units? kHZ? What is the sampling interval? This matters because of statistical error. I see entries in there sometimes separated by tens of seconds during a run. In the time between the samples, were the scalers free-running so that I have the full statistical information in the one reading at the end of the interval, or are all of the statistics during the seconds in between the records in the DB lost?
>> 
>> -Richard J.
>> 
>> 
>> _______________________________________________
>> Halld-online mailing list
>> Halld-online at jlab.org <mailto:Halld-online at jlab.org>
>> https://mailman.jlab.org/mailman/listinfo/halld-online <https://mailman.jlab.org/mailman/listinfo/halld-online>
> 
> 
> _______________________________________________
> Halld-online mailing list
> Halld-online at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-online

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-online/attachments/20180112/ea2080fc/attachment-0001.html>