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

[Richard Jones]

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>
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>
> Date: 1/11/18 1:39 PM (GMT-05:00)
> To: Hovanes Egiyan <hovanes.egiyan at gmail.com>
> Cc: 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>
> 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 listHalld-online at jlab.orghttps://mailman.jlab.org/mailman/listinfo/halld-online
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-online/attachments/20180112/75bd06d3/attachment.html>