Automating Peaking for diagnostic purposes

[Dan MacDonald]

Good morning, everyone:

I have a small question regarding Automated Peaking of spectrometers.  First, some context.  One of my spectrometers has been giving me a severe headache with respect to peak drift over long analytical runs, and this drift leads to degrading analyses.  Part of the problem is related to temperature changes in the lab, which I am able to log using a temperature data logger.  There seems to be a rough correlation between temperature variation and decreasing net intensities over time (measured on standards) for elements in that spectrometer, but I am not convinced that the variation is caused just by temperature variation, given that the variation in net intensities occurs sometimes with only a 2 degree change in temperature.

I would like to be able to have automated peaking of the elements in question run about every 5 minutes for a whole 24 hour period, but without doing any analyses, and being able to record the peak positions over that time.  Maybe this isn't possible - if not, I could run 1 or 2 elements in that spectrometer and do a re-peaking before every analysis (I am not exactly sure how to set the interval with respect to how many analyses go by before re-peaking) in hopes that the new peak positions would get recorded (they should get automatically updated as far as I understand).  I could then see exactly how the peak drift in the spectrometer behaves over a 24 hour period and compare the drift to the changes in temperature recorded by my data logger.

Any help you can provide would be most appreciated.

Thank you very much for your kind help.

Best regards,

Dan MacDonald

[John Donovan]

I have a small question regarding Automated Peaking of spectrometers.  First, some context.  One of my spectrometers has been giving me a severe headache with respect to peak drift over long analytical runs, and this drift leads to degrading analyses.  Part of the problem is related to temperature changes in the lab, which I am able to log using a temperature data logger.  There seems to be a rough correlation between temperature variation and decreasing net intensities over time (measured on standards) for elements in that spectrometer, but I am not convinced that the variation is caused just by temperature variation, given that the variation in net intensities occurs sometimes with only a 2 degree change in temperature.

I would like to be able to have automated peaking of the elements in question run about every 5 minutes for a whole 24 hour period, but without doing any analyses, and being able to record the peak positions over that time.  Maybe this isn't possible - if not, I could run 1 or 2 elements in that spectrometer and do a re-peaking before every analysis (I am not exactly sure how to set the interval with respect to how many analyses go by before re-peaking) in hopes that the new peak positions would get recorded (they should get automatically updated as far as I understand).  I could then see exactly how the peak drift in the spectrometer behaves over a 24 hour period and compare the drift to the changes in temperature recorded by my data logger.

The only automated re-peaking (aside from the automated re-peaking in the Automate! window), is in the Acquire! window Acquisition Options dialog where one can set a flag for specific elements to perform an automated re-peaking on each point acquisition. But the automated re-peaking from the Automate! window is only performed once per run. 

But if you're just testing the peaking itself, just set the re-peaking flag for each element in the Acquisition Options dialog (by clicking on each element in the list), then digitize a bunch of points and let 'er rip.

And yes, each spectrometer peaking is automatically recorded in your MDB file, and can be seen in the Run | Display, Fit and Export Spectrometer Peaking and PHA Scans menu dialog. And the peaking data can be exported also.

This option is a bit more involved, but you can also create a customized script for testing your spectrometer mechanicals. If you are interested you might take a look at the Excel macros provided with the Remote Server interface:

https://probesoftware.com/smf/index.php?board=9.0

The Remote Server interface supports the peaking methods shown here:

Public Sub RemoteStartPeak(motor As Integer, size As Single, npoints as integer,
counttime as single)

Public Sub RemoteWaitPeak(motor As Integer, done As Integer)

Public Sub RemoteReturnROMPHAData(iscal As Integer, npts As Integer, xdata()
As Single, ydata() As Single)

Public Sub RemotePeakGetCentroid(mode As Integer, motor As Integer, npts As
Integer, xdata() As Single, ydata() As Single, pos As Single, ptob As Single, avgdev
As Single, success As Integer)

These Remote Server calls can be implemented in any OLE Active-X container such as Excel, MatLab etc., or one can implement them in code. See the Spectrometer Reproducibility Excel macro for an example of this type of coding. But please note that implementing these calls is not for the faint-hearted (though many of our users have written their own apps using these Remote Server calls for specialized automation of their instruments), as Microsoft has been locking such macros calls down more and more with each new version of Microsoft Office.

I know Dan Ruscitto has written many of these scripts for his own internal use. You can find him on this forum.

However, I should note that this automated re-peaking may not be necessary, if instead you simply want to quantify the extent of your intensity drift using Probe for EPMA.

In that case, just set up repeated standardizations from the Automate! window using the "Automation Actions". For example one can select the first Acquire Standard Samples and also a subsequent Acquire Standard Samples (again) as shown here:



Once you have more than one standardization you can list them easily using the List Standard Intensities button from the Analyze! window as seen here:

Drift array background intensities (cps/30nA) for standards:
ELMXRY:    ca ka   si ka
MOTCRY:  3  LLIF 1   TAP
INTEGR:        0       0
STDASS:      358      14
STDVIR:        0       0
            69.9    42.8
            68.5    43.1
            69.5    43.3

Drift array standard intensities (cps/30nA) (background corrected):
ELMXRY:    ca ka   si ka
MOTCRY:  3  LLIF 1   TAP
STDASS:      358      14
STDVIR:        0       0
          2301.6 23647.0
          2284.6 23657.9
          2304.5 23677.5

One can also utilize the "Re-Standard Interval (hrs)" feature (also from the Automate! window), to re-run standards every N hours during a long unknown acquisition.

Or one could simply acquire many multiple unknown samples on a homogeneous sample (say a grid or traverse) and export the data using one of the many intensity export options in Probe for EPMA.

Note also that Probe for EPMA automatically applies a standard intensity drift correction (which can be turned off from the Analytical | Analysis Options menu dialog), which means that it will apply a linear drift correction between each standardization for any samples in between those standardizations.

This automatic standard intensity drift correction feature is great for labs that have temperature fluctuations or mechanical issues on one or another spectrometer, because it performs this drift correction on an element by element basis!

I hope this helps.

[Dan MacDonald]

Good afternoon, John:

Thank you very much for all your helpful advice, I am most grateful to have it.

I have a question arising from some trials with the method of having the spectrometer peak before every analysis and 'letting it rip'.  When I did this for a small batch of points, I manually updated the on-peak value (MgKa in CH3TAPH)  by doing a manual peaking.  When I ran the points with the automatic peaking, the first point had an L-value I had put in, i.e., 107.314 from a manual peaking, and when it did the automated peaking, it displayed the centroid value at 107.3119 but used the L-value 108.1088 which is way over on the flank of the peak.  That first analysis gave a 'correct' net intensity vale of about 46,994 counts (i.e., extremely close to what I had thought it would be based on the manual peaking).  The second and third points of the run gave similar peaking results and in each case but the centroid value was ignored and the program used the 108.109 L-value and didn't update the on-peak value to that of the centroid.  Also, the second and third points yielded net intensity values of 1720 counts and 1689 counts, respectively, compared with the first point at 46994 counts.  These 2 lower net intensities make perfect sense when looking at the peaking graph, as they are the intensities taken at the L-value of108.109.  Also, when I did a re-peaking of MgKa after the run had completed, the following error message showed up:

Starting spectrometer peaking procedure for Mg ka on spectro 3...
Mg ka Spectro 3, StartPk:  108.109, StartI:     1772.5, HiPeak:     63.5, LoPeak:     21.5, StartP/B:    41.71
ROM Scan completed on spectro  3 with 50 total points
Spectro 3 Fine Scan FAILED- Calculated peak centroid at 107.3095, is too far offset from original peak position of 108.1088
ROM Scan completed on spectro  3 with 150 total points
Spectro 3 Coarse Scan FAILED- Calculated peak centroid at 107.314, is too far offset from original peak position of 108.1088
Spectro 3 FAILED- Coarse peaking did not succeed, will use initial position of 108.1088
Mg ka Spectro 3, StopPk:   108.109, StopI:      1675.0, HiPeak:     63.5, LoPeak:     21.5, StopP/B:     39.41

ROM Gaussian Peak Center Results (cps):
 Element  Spectr  Peaked   StartPk    StopPk  Offset    StartI     StopI StartPB  StopPB
   Mg ka   3 TAPH   No      108.109   108.109    -.31    1772.5    1675.0   41.71   39.41

 My questions are as follows: 1. What is this L-value 108.109 supposed to be, i.e., where did the program get this number?  It seems to be close to the theoretical value of 107.7985 in your periodic table (107.513 in JEOL's L-value table). 2. Is the automatically determined L-value supposed to update to that of the calculated centroid, and if not, why not, as it yields the 'correct' net intensities. 3. Regarding the error message that showed up, I see that the peaking procedure started at the incorrect 108.109 L-value (as expected), found the correct centroid and rejected it because it was too far off from the initial (but wrong) peak position.  The centroid is the correct position, however.  So I am not sure how to get around this issue, because my whole aim is to see how the peak position and associated intensities drift over time, but that will be (almost?) impossible if the on-peak position isn't correct, as the wrong intensities will be collected at that default L-value of 108.109 every single time, because the software will reject the centroid value which is correct, even if it is offset by what is an unacceptable amount to the peaking software. How can I get around this and what am I doing wrong?

Thank you very much for all your kind help and patience.

Best regards,

Dan

[John Donovan]

Hi Dan,
The peaking procedure obtains the default peak position from the current sample.

The current sample obtains its parameters from the sample basis, which is usually the last unknown sample or the specified sample setup, if using sample setups from the Acquire! or Automate! windows.

So maybe you didn't perform your initial peaking on the last unknown or the sample you utilized as the sample basis?

[Dan MacDonald]

Hi John:

I'm sorry for not having gotten back to you sooner, as I have been very busy the last several days.  The sample basis I used was the specified sample setup from the Automate! window, and I did check that the initial peaking was done on that same sample basis, which is part of why I am so confused about the whole thing.

If you think of anything else that might be going wrong here, please let me know, I greatly appreciate it.

Best regards,

Dan

[John Donovan]

I'm sorry for not having gotten back to you sooner, as I have been very busy the last several days.  The sample basis I used was the specified sample setup from the Automate! window, and I did check that the initial peaking was done on that same sample basis, which is part of why I am so confused about the whole thing.

If you think of anything else that might be going wrong here, please let me know, I greatly appreciate it.

Hi Dan,
I just ran some peaking automation tests using "digitized sample setups" from the Automate! window and everything ran as it should.  Specifically, I:

1. Created an unknown sample and peaked the element as usual from the Acquire! window (or use the Automate! window).

2. Then specified that the element be peaked for each new sample from the Acquisition Options dialog (the "Peak On Acquisition" flag has to be specified the sample when it is the current sample!).

3. Then from the Analyze! window I saved the peaked sample to the sample setups list using the Add To Sample Setups button.

4. I then created a new sample from the Acquire! window, and edited the peak position to be significantly different (just as a test to be sure it utilized the already peaked position).

5. Then from the Automate! window I assigned the saved sample setup (with the peaked element) to an unknown position sample.

6. Then I ran the unknown position sample from the Automate! window. 

I observed that it utilized the specified sample setup (with the peaked position), it then re-peaked the element using that peaked position, and then acquired the sample as usual.

So not sure what you're doing wrong, but maybe this helps?