|
No, you could periodically process the acalcout records so they update during the scan as well.
Mark
From: Jesse Hopkins <jhopkins1 at illinoistech.edu>
Sent: Friday, March 13, 2026 3:38 PM
To: Mark Rivers <rivers at cars.uchicago.edu>; Matthew Newville <newville at cars.uchicago.edu>; EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: [Ext]Re: Scaler/MCS dark counts?
Hi Mark,
Thanks for the suggestion. Most of the time our scans are long enough that we’re reading out the MCS while it is running. It sounds like this would only work once it finishes?
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
From: Mark Rivers <rivers at cars.uchicago.edu>
Date: Friday, March 13, 2026 at 3:20 PM
To: Matthew Newville <newville at cars.uchicago.edu>, EPICS Tech-Talk <tech-talk at aps.anl.gov>, Jesse Hopkins <jhopkins1 at illinoistech.edu>
Subject: Re: [Ext]Re: Scaler/MCS dark counts?
You should be able to use acalcout records to compute the background subtracted MCS spectra. If you use FLNK from the MCS records then ca_put_callback should wait for the acalcout records to process when acquisition is complete.
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jesse Hopkins via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, March 13, 2026 3:07 PM
To: Matthew Newville <newville at cars.uchicago.edu>; EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: [Ext]Re: Scaler/MCS dark counts?
Hi Matt,
In case it’s of interest to you, I’m testing a variant on what you do. I have a set of ao records as $(PREFIX)Dark1, Dark2, etc. that I generate, one for each scaler. I measure and write dark counts to these aos using a python program. In the scaler IOC start
script I’ve added a set of lines after iocinit for each calc from 2-8 as:
dbpf("$(SCALER_PREFIX)$(SCALER_NAME)_calc2.INPJ", "$(PREFIX)Dark2.OVAL NPP NMS")
dbpf("$(SCALER_PREFIX)$(SCALER_NAME)_calc2.INPK", "$(SCALER_PREFIX)$(SCALER_NAME)_calc1.VAL NPP NMS”)
Here INPJ links to the dark current ao record and INK to the value of calc1, which is the actual measured time (the same as in your example). As far as I can tell from the scaler records, the calc records process in order from 1-8 using FLNKs, so 1 should always
be processed first, making the value used for the time correct. So a user calculation ends up being something like:
B-J*K
which should yield the dark corrected value of scaler 2 in calc2.VAL. This at least somewhat streamlines what we used to do, which was dark correct entirely in python, and means I don’t have to rewrite the actual calc _expression_ every time I update a dark reading.
Alternatively, instead of adding the INPK link you could just have the A/freq value in each calculation, but then if you change the frequency you have to update it everywhere, rather than just in the A _expression_.
I also use the generated Dark records for the dark counts for the MCS (this is a CTR08, so same inputs for both modes). The MCS dark subtraction I still have to do outside of EPICS when it is read out as part of data collection.
I haven’t had a chance to test extensively, but it at least doesn’t break immediately when I use it.
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jesse Hopkins via Tech-talk <tech-talk at aps.anl.gov>
Date: Friday, March 13, 2026 at 1:56 PM
To: Matthew Newville <newville at cars.uchicago.edu>, EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: [Ext]Re: Scaler/MCS dark counts?
Hi Matt and Mark,
Thanks or the responses, as always.
Matt:
I had thought about using the scaler calcs, but wasn’t sure how to get the dark current values in. I guess if I did just explicitly write them in the field as you do then that would work as I want (though of course they wouldn’t be available for other uses).
If my memory serves calc INPX fields are also configurable after loading, so I could hijack some of the input links for each calc field without having to rewrite the scaler dbs, such as through a dbpf in the IOC start script, and then use it that way, which
would be another option.
Mark:
Yes, we mostly use hardware applied offsets to keep the darks close to zero, but there are cases where we like to have an offset present, and having it subtracted automatically is useful. I suppose I think of it more as a detector image, I don’t typically save
raw images without flat field, dark correction, etc, similarly I typically don’t save scaler values without dark counts subtracted if they’re being used.
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
From: Matthew Newville <newville at cars.uchicago.edu>
Date: Friday, March 13, 2026 at 1:23 PM
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>, Jesse Hopkins <jhopkins1 at illinoistech.edu>
Subject: [Ext]Re: Scaler/MCS dark counts?
Hi Jesse,
I have run into this issue too, both with Struck3820 and with the Measurement Computing CTR08 with current amplifiers such as the Stanford Research SR570. For those, I like to run with a non-zero dark current, but also need a large enough dynamic range, including
at the low-end, so having dark-current subtracted intensities is important.
I use the scaler "calc" values to have the dark-current-subtracted values be put to the PVs "XX:scaler1_calc1.VAL” instead of “.S1”, etc. I have a script (python) that collects the offsets and writes the calculations. I should also say that I always use
the 1st channel as Clock and as the “gate”, so that we count for a fixed time range.
With USB CTR08, I use a frequency of 24 MHz, and so the “dark current” script sets the calculations to be something like
XX:scaler1_calc1.CALC = “A/2.4e7” (time in seconds)
XX:scaler1_calc2.CALC = “B-(A*3.445008e-03)” (# the A here would be the raw S1 value).
XX:scaler1_calc3.CALC = “C-(A*1.153665e-02)”
And so forth, so that the value for
XX:scaler1_calc3.VAL will be dark-current corrected for whatever time value is used.
If doing step scans, I will record the “_calcN.VAL” values instead of “.SN” values.
As you see, when doing fly scanning (which is essentially all the data we collect), the MCS arrays “MCA1”, “MCA2”, etc., will have the values without the dark currents subtracted — corresponding to the “.SN” values.
I use the CALC fields from the scaler record and the MCS arrays to apply the dark-current correction to MCS data after the fly scan is done, in Python.
It would be nice if all of this were more automated. I think the idea of the scaler calc values is to be more general than only subtracting dark currents. It does seem reasonable to have the corresponding CALC MCAs that always apply the calculations for the
MCS record.
—Matt
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jesse Hopkins via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, March 13, 2026 11:48 AM
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Scaler/MCS dark counts?
Hi folks,
I wanted to check with the community and see if anyone has a clever way of handing dark counts for scaler and MCS records (e.g. those from a Joerger VSC 8/16 and Struck SIS3820 or measurement computing CTR08). For years we’ve essentially just been creating
ao records, writing our current values dark to these records as cts/time, and then in our data collection software (python based) we manually apply these corrections as needed. I’m working on setting up and testing a new set of scalers and MCS for our beamline
and it seems like there should be a better way.
At least for a scaler, I could imagine setting up a set of calc or scalcout records that take as input the dark cts/time, the counts, and the count time, and does the subtraction. Presumably you could trigger these off the COUT or COUTP links in the scaler
(though that triggers each time it starts or stops). I don’t know if there’s a way to make sure that this happens synchronously enough that you could use these dark subtracted calcs in a scan. For an MCS, I don’t know if there’s a way to do this calculation
on the fly (as we typically read out values as they come in).
Anyways, I suspect this is something that lots of folks have thought about, and maybe someone already has a nice working solution I could just slot in or adapt for our needs. I’d be interested in hearing what folks have done, there doesn’t seem to be a lot
that’s searchable, either on this list or just on the web) about dealing with dark counts for these types of records.
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
|
