Wish List for PFE Features

[John Donovan]

Hi Owen,
Is that all?     

I just don't understand why you are seeing these errors, and Julie and I never do...

I'll take a look, thanks for the detailed report- that always helps.
john

[Probeman]

I sent Owen a modified PFE executable and we can confirm that the problems he was having with re-processing data from an old run is due to the fact that I was checking background positions for "out of bounds" even for samples with data, which is unnecessary since the background positions cannot be changed once the sample contains data.

I will roll this fix out tonight.  Just for a sanity check I also loaded a *very* old data file (v. 3.5) and tried to modify the sample element parameters also, and found a couple of minor checks that weren't necessary (from an old run on an ARL SEMQ containing fixed spectrometers!) and that is also fixed! I think v. 3.x was the first Windows version of my software that utilized Microsoft Access database file?

Anyway, there is another way to avoid the problem that Owen found when re-processing data off-line (on a computer with different instrument configuration files), and the procedure described below is especially useful when attempting to create or run probe data files on another computer in "demo" mode. That is, without an EPMA instrument connected to the computer.

1. Create or open a probe database on your on-line computer (the one connected to the instrument), and using the File | Import Probe Configuration Files menu, load the current instrument configuration files into the opened probe database as seen in this post:

http://smf.probesoftware.com/index.php?topic=42.msg659#msg659

2. Then close the probe database and copy the MDB file to your off-line computer and this time using the File | Export Probe Configuration Files menu, click the Export All button to export the selected instrument configuration files to the off-line computer PFE app folder.

It will ask if you want to overwrite the existing configuration files (and automatically back them up) and also offer to set the instrument InterfaceType parameter to zero for "demo" mode operation.

Pretty cool!

[John Donovan]

So it seems like we have a few competing issues here:
1) Default MPB positions are outside spectro range (we'll assume this is operator error on my part, though I can't figure out where).
2) MPB parameters causing errors for samples not acquired using MPB.
3) The values for the MPB positions changing.

Sorry to bring you aggravation so close to quittin' time, but I hope this helps.

Hi Owen,
Ok, what I did was modify the save elements/cations code so that the peak and background positions don't get checked for out of bounds since they can't be updated anyway once the sample contains data.  The fact that you were reprocessing data on an off-line computer with different spectro ranges defined in the config files is what was causing the errors.

But all is well now, so update from the Help | Update menu and all will be good.
john

[Ben Buse]

Two things I've wondered about:

(1) Wavescans with the option of multiple accumulations to allow slow acquistion wavescans of trace elements without having to turn ROM off which is really slow. Also if you can do multiple accumulations over a grid of points you can spread the damage.

(2) Calibration curve for a single element. Let me explain this a bit. What I do when analysing carbon in steels is run a calibration curve for carbon whilst running phi-rho-z for the other elements. Currently PFE only allows you to use a calibration curve if you apply it for all the elements - is there any intrinsic reason for this? I did think alternatively I could analyse carbon using phi-rho-z and using the blank correction to subtract the amount of contamination - has anyone tried this?

Thanks

Ben

[Ben Buse]

And a third thing:

A way of flaging up duff standards - let me explain the other day - on the rare occasion that the peaking failed to locate the peak and it used the previously stored value. This was good in that it let the rest of the elements finish peaking and calibrating. But it also meant the element without a peak was calibrated and then used in quantification of secondary standards. Amittedly it should have been noticed on checking the standard data that for this element the %SD was high as it was calibrated on background. I wondered if there was a was without bailing out of a automated standardization to notify the user at the end when everythings completed that a particulary element used a previously stored peak value and needs checking. This might be a bit complicated as i think most of the time users would prefer it to continue as it did and run the other elements rather than coming back an hour later and finding it hasn't done anything as it did not find the peak for one element.

Thanks

Ben

[John Donovan]

(1) Wavescans with the option of multiple accumulations to allow slow acquisition wavescans of trace elements without having to turn ROM off which is really slow. Also if you can do multiple accumulations over a grid of points you can spread the damage.

For qualitative analysis? I think you mean the ROM scans are fast and count/step scans are slow to very slow depending on the sensitivity you want.

See here:

http://smf.probesoftware.com/index.php?topic=464.msg2537#msg2537

Also, have you tried Multi-Point Backgrounds for traces?

(2) Calibration curve for a single element. Let me explain this a bit. What I do when analysing carbon in steels is run a calibration curve for carbon whilst running phi-rho-z for the other elements. Currently PFE only allows you to use a calibration curve if you apply it for all the elements - is there any intrinsic reason for this? I did think alternatively I could analyse carbon using phi-rho-z and using the blank correction to subtract the amount of contamination - has anyone tried this?

I should have known that once I offered multiple matrix corrections, some people would want to "mix and match" matrix corrections, but I worry about data self consistency, not to mention it would be a coding nightmare!

Here's my suggestion: just make another copy of your probe data file and run it each way in each file.  Then output to Excel and "mix and match" there all you want!

[John Donovan]

And a third thing:

A way of flaging up duff standards - let me explain the other day - on the rare occasion that the peaking failed to locate the peak and it used the previously stored value. This was good in that it let the rest of the elements finish peaking and calibrating. But it also meant the element without a peak was calibrated and then used in quantification of secondary standards. Amittedly it should have been noticed on checking the standard data that for this element the %SD was high as it was calibrated on background. I wondered if there was a was without bailing out of a automated standardization to notify the user at the end when everythings completed that a particulary element used a previously stored peak value and needs checking. This might be a bit complicated as i think most of the time users would prefer it to continue as it did and run the other elements rather than coming back an hour later and finding it hasn't done anything as it did not find the peak for one element.

Thanks

Ben

I don't think I understand.

If you select peaking and also acquisition from Automate!, then it won't proceed with the acquisition if there any problems with the peaking.

Note the output here from the log window during automated peaking:

Starting spectrometer peaking procedure for na ka on spectro 1 (TAP)...
Na ka Spectro 1, StartPk:  46227.3, StartI:      292.0, HiPeak:     13.7, LoPeak:     13.7, StartP/B:    21.29
ROM Scan completed on spectro  1 with 30 total points
Na ka Spectro 1, StopPk:   46221.6, StopI:       292.4, HiPeak:     13.7, LoPeak:     13.7, StopP/B:     21.32

ROM Brent's Maxima Peak Center Results (cps):
Element  Spectr  Peaked   StartPk    StopPk     Std  Offset    StartI     StopI StartPB  StopPB
   na ka    1 TAP   Yes     46227.3   46221.6     336    141.     292.0     292.4   21.29   21.32
   si ka   2 LPET   *No     .000000   .000000     162    18.4        .0        .0     .00     .00
    k ka   3 LPET   *No     .000000   .000000     374    151.        .0        .0     .00     .00
   al ka    4 TAP   *No     .000000   .000000     160    49.9        .0        .0     .00     .00
   mg ka    1 TAP   *No     .000000   .000000     162    141.        .0        .0     .00     .00
   ca ka   2 LPET   *No     .000000   .000000     162    32.7        .0        .0     .00     .00
    s ka   2 LPET   No      .000000   .000000     730    38.8        .0        .0     .00     .00
   fe ka    5 LIF   No      .000000   .000000     162    7.47        .0        .0     .00     .00
   cl ka   3 LPET   No      .000000   .000000     285    118.        .0        .0     .00     .00
   ti ka    5 LIF   No      .000000   .000000      22   -127.        .0        .0     .00     .00
    p ka    4 TAP   No      .000000   .000000     285    6.00        .0        .0     .00     .00
    f ka    1 TAP   No      .000000   .000000     284    95.0        .0        .0     .00     .00


The No, means the element was *not* selected for peaking. The *No, mean the element was selected for peaking but has not been acquired yet, or it failed. The Yes, means the element selected for peaking did peak properly. In this case Na.

Here is after the K spectrometer was peaked on the assigned standard:

Starting spectrometer peaking procedure for k ka on spectro 3 (LPET)...
K ka Spectro 3, StartPk:  42625.8, StartI:     1367.1, HiPeak:     43.7, LoPeak:     45.6, StartP/B:    30.62
ROM Scan completed on spectro  3 with 30 total points
K ka Spectro 3, StopPk:   42539.5, StopI:      1368.7, HiPeak:     43.7, LoPeak:     45.6, StopP/B:     30.66

ROM Brent's Maxima Peak Center Results (cps):
Element  Spectr  Peaked   StartPk    StopPk     Std  Offset    StartI     StopI StartPB  StopPB
   na ka    1 TAP   Yes     46227.3   46221.6     336    141.     292.0     292.4   21.29   21.32
   si ka   2 LPET   *No     .000000   .000000     162    18.4        .0        .0     .00     .00
    k ka   3 LPET   Yes     42625.8   42539.5     374    237.    1367.1    1368.7   30.62   30.66
   al ka    4 TAP   *No     .000000   .000000     160    49.9        .0        .0     .00     .00
   mg ka    1 TAP   *No     .000000   .000000     162    141.        .0        .0     .00     .00
   ca ka   2 LPET   *No     .000000   .000000     162    32.7        .0        .0     .00     .00
    s ka   2 LPET   No      .000000   .000000     730    38.8        .0        .0     .00     .00
   fe ka    5 LIF   No      .000000   .000000     162    7.47        .0        .0     .00     .00
   cl ka   3 LPET   No      .000000   .000000     285    118.        .0        .0     .00     .00
   ti ka    5 LIF   No      .000000   .000000      22   -127.        .0        .0     .00     .00
    p ka    4 TAP   No      .000000   .000000     285    6.00        .0        .0     .00     .00
    f ka    1 TAP   No      .000000   .000000     284    95.0        .0        .0     .00     .00

Calibrate Peak Positions Automation Action is Completed
Warning: si ka on spectrometer  2 LPET could not be peak centered
Warning: al ka on spectrometer  4 TAP could not be peak centered
Warning: mg ka on spectrometer  1 TAP could not be peak centered
Warning: ca ka on spectrometer  2 LPET could not be peak centered


Since elements selected for peaking (Si, Al, Mg, Ca), were not able to be peaked (in this instance because the assigned standard for those elements were not selected in the Automate position list), the run did not proceed to the acquisition step.

Am I missing your question?

[Ben Buse]

Yes I thought it would say no and abort. But in this case it did the fine peak scan with the centre of the peak just outside the window, then it did the course peak scan with the centre of the peak just outside the window. Then it said peak failed (can't remember wording), but that it would use previous peak position and changed peaked to yes. It may well be because the coarse scan was set up wrong looking at it now the range had been set to small - I will change this

Thanks

Ben

[Probeman]

Yes I thought it would say no and abort. But in this case it did the fine peak scan with the centre of the peak just outside the window, then it did the course peak scan with the centre of the peak just outside the window. Then it said peak failed (can't remember wording), but that it would use previous peak position and changed peaked to yes. It may well be because the coarse scan was set up wrong looking at it now the range had been set to small - I will change this

Thanks

Ben

Hmmm, still it should not proceed with the standard acquisition if there was an error with the peaking.  I'll look into this  as well.
john

[John Donovan]

Yes I thought it would say no and abort. But in this case it did the fine peak scan with the centre of the peak just outside the window, then it did the course peak scan with the centre of the peak just outside the window. Then it said peak failed (can't remember wording), but that it would use previous peak position and changed peaked to yes. It may well be because the coarse scan was set up wrong looking at it now the range had been set to small - I will change this

Thanks

Ben

Hmmm, still it should not proceed with the standard acquisition if there was an error with the peaking.  I'll look into this  as well.
john

Hi Ben,
The automation "trap" for unpeaked elements seems to be working.  Here is what I get when one or more WDS elements fails to peak:



In the log window you should see something such as this:

ROM Brent's Maxima Peak Center Results (cps):
Element  Spectr  Peaked   StartPk    StopPk     Std  Offset    StartI     StopI StartPB  StopPB
   rb la   2 LPET   *No     83850.4   .000000    1023   -201.     445.8        .0    3.56     .00
   sr la    1 PET   Yes     78575.2   78508.5     251    -65.    4975.2    5033.8  178.76  180.86

This may be a subtle issue, so let me know if you are still seeing a problem.
john

[Malcolm Roberts]

Hey John
How's about a drag and job capability for opening an analysis file?
Cheers,
malc.

[John Donovan]

Hey John
How's about a drag and job capability for opening an analysis file?
Cheers,
malc.

Did you try?   
john

[Malcolm Roberts]

Of course....... It didn't......

[John Donovan]

Of course....... It didn't......

Hmmm, it works just fine for me.

So you have a shortcut for PFE on your desktop, and you found a probe MDB file in Windows Explorer and using the mouse you dragged the MDB file to the PFE shortcut and dropped the MDB file on the PFE shortcut and it didn't open PFE and load the file?

[Gseward]

Hey, why drag and drop when you can associate .mdb files with the Probewin.exe and then just double click on any .mdb you like? OK, so if you also use MS Access/.mdb files for other stuff this might not work so well!, but if you double click on a non-PROBE database .mdb, John is smart enough to know about it and warn you accordingly  Try dragging and dropping xray.mdb or standard.mdb or position.mdb onto your probewin.exe shortcut and see what happens.