Fast Counts and Slow Counts; MCA Status Rate and MCA Read Rate Setting

[1458861693]

Hi, I am using the AmpTek PX5 detector with mca-R7-7 and mca-R7-9 and have encountered some issues:

1. At certain positions, I have observed instances where the Fast Counts are less than the Slow Counts. As I understand it, Fast Counts represent the Input counts, while Slow Counts represent the Output counts; therefore, Fast Counts should not be less than Slow Counts. This issue arises when using the mca module, but it does not occur when using the vendor's software "DppMCA." I have loaded the detector configuration file saved by AmpTek's DppMCA software into the mca module, so the detector configuration files used in both DppMCA and mca are identical.

Here are the screenshots of 1 second data acquisitions using the same configuration file, obtained separately with the mca module in EPICS and the DppMCA software:

mca OPI for AmpTek PX5

Vendor‘s software-DppMCA

In DppMCA, is the “Total Count” is “Slow Counts” and "Input Count" is "Fast Counts"?

2. Why is there a discrepancy in Dead Time between the mca module in EPICS and the vendor's DppMCA software?

3. Regarding the settings for "MCA Status Rate" and "MCA Read Rate," when both are set to Passive, I set the preset acquisition time and start the acquisition, but the process does not stop automatically; instead, I have to manually stop the acquisition. Based on my previous experience, if both settings are set to Passive, the MCA and MCA Status should be read at the end of the acquisition. However, currently, the acquisition does not stop automatically and requires manual stopping when both use passive setting. This behavior is inconsistent with the use of DXP and MCA with Ketek DPP2, where this issue does not occur.

These issues are very important to me, and I hope to receive some assistance. Looking forward to your reply. Thank you very much!

[MarkRivers]

I noticed that the readback fields for enums in your EPICS screenshot are incorrect. They are displaying the integer index number, rather than the string. This is due to an error in the medm screen from which this was converted. It was using "Decimal" rather than "String" format for those widgets. I have fixed the problem, done new autoconversions of the screens and pushed to Github.

I don't have a good explanation for why Slow Counts is sometimes larger than Fast Counts. I do see that in EPICS you have set the Fast Peaking Time to 100 ns. But I don't see the equivalent setting in the vendor software screen?

In DppMCA, is the “Total Count” is “Slow Counts” and "Input Count" is "Fast Counts"?

Yes, I believe that is the case.

The code to read the fast and slow counts and put them in EPICS PVs is very simple. It is here:

mca/mcaApp/AmptekSrc/drvAmptek.cpp

Line 874 in 46848fd

if ((status = sendCommand(XMTPT_SEND_STATUS)) == asynSuccess) {

EPICS just reads a structure using the vendor library that contains the fast and slow counts. It just copies those values to the EPICS parameters. I don't see how that could have an error.

Why is there a discrepancy in Dead Time between the mca module in EPICS and the vendor's DppMCA software?

EPICS computes the deadtime from the elapsed Realtime and Livetime here:

mca/mcaApp/mcaSrc/mcaRecord.c

Line 712 in 46848fd

if (pmca->ertm > .001) {

In the EPICS screen the elapsed realtime=1.01 and the elapsed live time=1.00. That means the deadtime is 1% within the 2 digit precision of the screen. The underlying precision is higher, so the EPICS deadtime is 0.75%.

There is an alternative way to compute deadtime, from FastCounts and SlowCounts. That calculation would be

Deadtime = 100*(1 - SlowCounts/FastCounts).  

For the vendor statistics that is

>>> 100*(1-3788./3891)
2.647134412747365

That is consistent with the 2.65% in the vendor screen. However, the Realtime of 1.01 seconds in the vendor screen is not consistent with this deadtime.

If we use this second formula with the EPICS Fastcounts and Slowcounts it would result in a negative deadtime, which is meaningless.

Regarding the settings for "MCA Status Rate" and "MCA Read Rate," when both are set to Passive, I set the preset acquisition time and start the acquisition, but the process does not stop automatically; instead, I have to manually stop the acquisition. Based on my previous experience, if both settings are set to Passive, the MCA and MCA Status should be read at the end of the acquisition. However, currently, the acquisition does not stop automatically and requires manual stopping when both use passive setting. This behavior is inconsistent with the use of DXP and MCA with Ketek DPP2, where this issue does not occur.

The Ketek DPP2 uses the EPICS dxp module. That driver has a separate thread that is constantly polling the vendor software, and so it does not need the ReadStatus record to be periodically scanned. The Amptek driver does not use a polling thread, so it requires that the ReadStatus record be set to continuously poll. The ReadData record can be Passive, and the spectrum will still be read when the run is complete. The AmptekStatus record is only used to read detector information when acquisition is not running, i.e. things like temperature, etc. So it can be set to a slow rate like 2 or 5 seconds.