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  2018  2019  2020  2021  2022  2023  2024  2025  <2026 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  2018  2019  2020  2021  2022  2023  2024  2025  <2026
<== Date ==> <== Thread ==>

Subject: Re: Scaler/MCS dark counts?
From: Matthew Newville via Tech-talk <tech-talk at aps.anl.gov>
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>, Jesse Hopkins <jhopkins1 at illinoistech.edu>
Date: Fri, 13 Mar 2026 18:22:59 +0000
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


Replies:
Re: [Ext]Re: Scaler/MCS dark counts? Jesse Hopkins via Tech-talk
References:
Scaler/MCS dark counts? Jesse Hopkins via Tech-talk

Navigate by Date:
Prev: Re: Scaler/MCS dark counts? Mark Rivers via Tech-talk
Next: Re: [Ext]Re: Scaler/MCS dark counts? Jesse Hopkins via Tech-talk
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  2018  2019  2020  2021  2022  2023  2024  2025  <2026
Navigate by Thread:
Prev: Re: Scaler/MCS dark counts? Mark Rivers via Tech-talk
Next: Re: [Ext]Re: Scaler/MCS dark counts? Jesse Hopkins via Tech-talk
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  2018  2019  2020  2021  2022  2023  2024  2025  <2026
ANJ, 19 Mar 2026 · Home · News · About · Talk · Base · Modules · Extensions ·
· Distributions · Download · Documents · Links · Licensing ·