New Features in CalcImage

[John Donovan]

I have a data acquisition request for our JEOL ProbeImage/CalcImage colleagues...  but first some background.

As many of you already know, Probe for EPMA contains a very robust drift correction not only for beam current drift, but also for standard intensity drift.  This beam current drift correction is commonly performed by other softwares, but the automatic standard intensity drift correction is unique to PFE, and allows the software to correct for changes in the measured standard intensities over time, on an element by element basis. That is, assuming that you acquired your standard(s) both before *and* after your unknown point acquisitions!

Now I have fully implemented this beam current and standard intensity drift correction in CalcImage for our x-ray mapping quantification. The beam current drift correction was already implemented in CalcImage but now, the standard intensity drift correction is also implemented. This standard intensity drift correction is a totally unique feature in both PFE and now, CalcImage, and it works amazingly well.

And because the standard intensity drift correction is performed on an element by element basis, it can deal with temperature related drift issues such as the thermal sensitivity of the PET crystals.

I also implemented the new CalcImage drift correction code so it automatically handles the situation where there is more than one x-ray map acquisition set for the quantification. That is, more than one element per spectrometer were acquired in Probe Image, using multiple sample acquisitions on the same area.

Cool.

So now I would like to obtain a small test dataset (MDB and PrbImg files) from a JEOL instrument (you'll see why in a second), on a homogeneous standard sample, for both a beam scan and a stage scan.  Just 3 to 5 elements, and no need to acquire off-peak maps as I would like to test the MAN drift correction as well, so please also acquire the primary standards and the MAN stds in PFE, both *before* the x-ray maps are run, and again *after* the x-ray maps are acquired.

Ideally this would be an overnight mapping run where you observe significant drift in either or both the beam current and/or the standard intensities. A lab with significant temperature variation would be ideal.

Hopefully the beam current and standard intensity drifts are linear because all we can do is interpolate linearly between standardizations...

Now, why do I want only JEOL MDB and map data?  Well because I'm calculating the drift by assuming the first pixel acquired is in the upper left of the map and the last pixel acquired is in the lower right.  This exactly the case for all Cameca beam and stage scans, but is only the case for the JEOL beams scans.  As you may know, JEOL stage scans start in the upper right and end in the lower left. It's an interesting story:

http://probesoftware.com/smf/index.php?topic=101.0

I will need to add a case to handle beam current and standard intensity drift for JEOL stage scans, but right now I'd like to test the beam scan drift and use the stage scan for testing the next coding effort, that is once I figure a method for determining if the x-ray map was a JEOL beam or stage scan!

So here's the test acquisition protocol if you are interested:

1. Create a sample setup in Probe for EPMA with 3 to 5 elements (or more if you want to do a two pass acquisition with more than one element per spectrometer). Karsten has excellent documentation for this here:

http://probesoftware.com/smf/index.php?topic=106.0

2. Acquire your primary and MAN standards in PFE. They are automatically saved to your MDB file.

3. Acquire both a beam scan and a scan scan using this setup in Probe Image.  Please name the beam scan sample "Beam scan..." and the stage scan "Stage scan...". The x-ray map PrbImg files are automatically saved.

4. Now acquire the primary and MAN standards in Probe for EPMA *again*, for the drift correction.

Hopefully even if the beam current and/or standard intensity drift was significant, we can now correct for this in CalcImage.

Feel free to play the the latest version of CalcImage yourself and test the new drift correction code, but please do send me a ZIP with the MDB and the PrbImag files acquired so I can try it myself.

Thank-you!
john

[John Donovan]

Paul Carpenter had a good idea: display the before and after beam currents in the raw intensity map output.   The intensity data is therefore displayed in cps/actual beam current without any correction.  Of course when these intensities are quantified, beam drift and standard intensity drift corrections are applied to the map intensity data (along with dead time, background, matrix and interference corrections as well!).

[Probeman]

I have a data acquisition request for our JEOL ProbeImage/CalcImage colleagues...  but first some background.

As many of you already know, Probe for EPMA contains a very robust drift correction not only for beam current drift, but also for standard intensity drift.  This beam current drift correction is commonly performed by other softwares, but the automatic standard intensity drift correction is unique to PFE, and allows the software to correct for changes in the measured standard intensities over time, on an element by element basis. That is, assuming that you acquired your standard(s) both before *and* after your unknown point acquisitions!

Now I have fully implemented this beam current and standard intensity drift correction in CalcImage for our x-ray mapping quantification. The beam current drift correction was already implemented in CalcImage but now, the standard intensity drift correction is also implemented. This standard intensity drift correction is a totally unique feature in both PFE and now, CalcImage, and it works amazingly well.

And because the standard intensity drift correction is performed on an element by element basis, it can deal with temperature related drift issues such as the thermal sensitivity of the PET crystals.

I also implemented the new CalcImage drift correction code so it automatically handles the situation where there is more than one x-ray map acquisition set for the quantification. That is, more than one element per spectrometer were acquired in Probe Image, using multiple sample acquisitions on the same area.

I should mention that so far as I know neither Cameca nor JEOL perform this standard intensity drift correction in their x-ray map quantifications, though Cameca does allow the user to re-measure the beam current at the end of N scan lines.  But if your beam is stable and your spectrometer crystal is warming up and therefore your peak position is changing, this won't help you. I believe that JEOL only averages the beam current before and after the map acquisition for a crude beam drift correction.

So OK, I thought of a method to induce a crude roughly linear intensity drift in the instrument during a x-ray map acquisition to test the above standard intensity drift correction.

In this test I acquired a standard intensity set, then ran a short x-ray map acquisition, and then re-acquired the standard intensities again to provide the drift correction. What I did was tune the Si ka peak position just to the high side of the peak. That is, still on the peak but just about to drop off down the side of the peak.

Then I opened an SX command line interpreter window and typed the "spec" command to move the spectrometer position one 10^-5 sintheta unit manually every 30 seconds or so during the x-ray map acquisition (one can use the up cursor to get the previous command in this window which is nice). This forced the Si Ka intensities to drop from around 18,000 counts to around 13,000 counts on the LTAP crystal during the map acquisition.

Note that the beam was absolutely stable during the standards and x-ray map acquisitions. Here is the raw data:



Note the enormous change in Si ka intensities due to the spectrometer peak position changing during the map acquisition. This intensity drift corresponds to a change from about 21 wt% Si to about 10 % Si. Now here is the quantification with the drift correction:



The correction isn't perfect because the x-ray map acquisition was so short (~10 minutes) and I wasn't perfect in running the standards with such a manually induced drift, but it certainly demonstrates the principle of the standard drift correction for x-ray map acquisitions.

Now I have a request.  This x-ray map drift correction in CalcImage currently assumes a normal scan method for beam and stage scans. That is, the scan starts in the upper left, fast scans in X, and finishes in the lower right.

This standard drift correction method will therefore work just fine on Cameca beam and stage scans and JEOL beam scans, which are all normal scans (assuming the intensity drift in roughly linear).  However, the JEOL stage scan is a completely different animal as it starts in the *upper right*, fast scans in Y, and finishes in the *lower left*.  If you are interested why JEOL does this, here is a discussion:

http://probesoftware.com/smf/index.php?topic=101.0

So, to avoid over heating my brain in trying to implement a standard drift correction for JEOL stage scans it would be most helpful if someone out there in "JEOL land" would acquire a stage scan where there is significant, but linear standard intensity drift over time. The method is simply to acquire your standards in PFE, run ProbeImage to acquire a stage scan with just a few elements, and then re-acquire your standards in PFE again to "bracket" the intensity change over time. 

One can do the initial standard acquisition and Probe Image map acquisition automatically from the new "Run Probe Image" option in the PFE Automate! window, as seen here:

http://probesoftware.com/smf/index.php?topic=600.msg3446#msg3446

But you'll need to run the standards again in PFE once the map finishes.  I'll probably add an option for re-running the standards automatically after the Probe Image acquisition completes.

And although CalcImage performs nice beam drift correction based on the pixel acquisition order based on the before and after beam currents, I would only like to test the standard intensity drift correction, so one method might be to start the PFE/PI acquisition and turn off the room temperature control to allow the room temp to slowly change during this acquisition.  Once the 2nd standard intensities are acquired you can turn the room temperature control back on and send me the data.

First person to do this gets a big wet kiss from me...  ok, no. The first person to do this *won't* get a big wet kiss from me!  How about that?   

Thanks in advance.
john

[Probeman]

I just wanted to show some of the many data types that are automatically output in CalcImage when performing an image quantification:



Just a few mouse clicks and bang, right into Surfer presentation quality output...

[John Donovan]

I just added code to automatically add elements specified as Formula By Difference elements (if not already present) in CalcImage (and CalcZAF), when indicated, as as seen here:



Otherwise one would have to add the elements one at a time in the Elements/Cations dialog(!). This code was already in PFE for point analyses, but I had forgotten to add it to CalcImage!   

Then again- nobody had complained about it!   
john

[John Donovan]

I'm not sure how useful this will be but now there are options to output analog signal images along with your quant maps in CalcImage as seen here in the Quant dialog:



Note that the output image controls are labeled as they are declared in your probewin.ini file in the [imaging] section. But you can edit them as necessary for however you want them labeled.

Here is an example of the output for some trace elements in zircon (at 10 keV, 100 nA) when the Surfer script is run:

[John Donovan]

To utilize this new analog signal output feature with old CalcImage projects that do not show the desired analog images as available, simply re-create the project using the Create (new) Project Wizard menu.

[Probeman]

Here is an example of the output for some trace elements in zircon (at 10 keV, 100 nA) when the Surfer script is run:

Because the x-ray map area contained a small apatite inclusion, it is difficult to see the phosphorus variation in the previous output (see P map in upper right).  However, using the log weight percent output option, we can see the phosphorus concentrations much more clearly in the output below (see P map in lower left):

[John Donovan]

As many of you know we have long enjoyed the TDI (time dependent intensity) correction in Probe for EPMA to deal with beam sensitive samples, e.g., alkali and/or hydrous glasses as described here :

http://probesoftware.com/smf/index.php?topic=11.0

A few years ago it occurred to Philippe Pinard and Sylvia Richter that a CPQ (Correlated Pixel Quantification) method (where one acquires an x-ray map on both the unknown *and* the standard), might be applied to deal with carbon contamination when measuring trace carbon, e.g., in steel as described here:

http://probesoftware.com/smf/index.php?topic=114.msg423#msg423

Unfortunately, the CPQ method, while perhaps useful for correction of Bragg defocusing at low magnification beam scans, doesn't work well enough on the carbon contamination problem as the rate of carbon contamination isn't reproducible enough when dwelling on each pixel for the time required for reasonable precision, e.g., 10 seconds per pixel.

Then I thought perhaps we could apply the TDI method to quantitative mapping by acquiring a series of replicate scans, where instead of sitting on each pixel for the full counting time and then moving to the next pixel, we divide up the map acquisition into a series of fast replicate maps.  The idea being that the carbon contamination is "smeared out" evenly over the entire analytical area.  Then perhaps we could apply a TDI correction on each pixel using the replicate maps and extrapolate the carbon intensity back to zero time, before the contamination began. 

Originally I performed a simple test a few years ago by acquiring a 32 pixel scan on pure Fe metal using 10 replicates at 1 second per replicate. I then plotting up the quantified replicate maps and it does appear that the carbon quant trend intersects zero as seen here:

http://probesoftware.com/smf/index.php?topic=48.msg3416#msg3416

So with that in mind, I spent the last few weeks working on implementing a TDI correction for each pixel in a replicate series of x-ray maps and I am pleased to say that we now have a full TDI correction in CalcImage for x-ray maps. This method utilizes replicate scans acquired in Probe Image and performs a full TDI correction for each pixel as seen here for carbon on pure Fe metal:



and here for nitrogen (no obvious trend in the data)



Here are the raw x-ray maps before quantification (a line scan of 32 pixels at 10 keV, 50 nA and 1 sec per pixel per replicate for a total of 10 seconds for the replicate series), which by the way was performed using the MAN background correction so no off-peak images were necessary:



The carbon map is in the lower right quadrant. Here are the quantified maps *without* a TDI correction:



And here are the quantified maps *with* a full TDI correction applied to each map pixel:



It is perhaps better to see the numerical output in the CalcImage log window, here first *without* the TDI correction:

Without TDI image correction:
                       C       N      Mo      Fe      Si   Total
Weight %:  1 (1,1)  .453321 -.03180 -.03053 100.101 .002954 100.494
Weight %:  2 (2,1)  .519024 .003435 -.00806 99.9945 -.00598 100.503
Weight %:  3 (3,1)  .434480 -.04739 -.05933 100.038 .007308 100.373
Weight %:  4 (4,1)  .464101 -.00715 -.00333 99.3005 -.00385 99.7502
Weight %:  5 (5,1)  .490581 -.03396 -.01931 100.912 .005218 101.354
Weight %:  6 (6,1)  .467664 -.05276 .001430 98.8739 .005178 99.2954
Weight %:  7 (7,1)  .840907 -.05204 -.02373 100.159 .014814 100.938
Weight %:  8 (8,1)  .855509 -.01140 -.02686 99.8534 .022579 100.693
Weight %:  9 (9,1)  .363398 -.01886 -.04819 99.8299 .004917 100.131
Weight %:  10 (10,1)  .354097 -.07100 -.02269 98.6863 .001746 98.9484
Weight %:  11 (11,1)  .372812 -.04317 .007723 99.4145 .005505 99.7574
Weight %:  12 (12,1)  .385476 -.01239 .012560 99.8808 .003351 100.270
Weight %:  13 (13,1)  .427612 -.05989 -.01780 100.015 .012153 100.377
Weight %:  14 (14,1)  .406739 .046412 -.01132 99.0875 .006155 99.5355
Weight %:  15 (15,1)  .416387 .006948 -.02733 99.7070 .004553 100.108
Weight %:  16 (16,1)  .737594 -.02365 -.02859 99.5029 .029309 100.218
Weight %:  17 (17,1)  .863599 -.02339 -.05725 100.204 .028362 101.015
Weight %:  18 (18,1)  .347543 -.03762 -.03225 100.589 .011480 100.879
Weight %:  19 (19,1)  .328581 -.01993 -.00668 100.478 .010791 100.791
Weight %:  20 (20,1)  .343103 -.06226 -.01151 101.075 .011064 101.356
Weight %:  21 (21,1)  .447505 -.02560 -.04810 100.395 .018343 100.787
Weight %:  22 (22,1)  .405794 .018765 -.02095 100.378 .005015 100.786
Weight %:  23 (23,1)  .448499 -.04090 -.01296 99.3157 .014807 99.7252
Weight %:  24 (24,1)  .451467 -.07769 .004583 100.042 .014862 100.435
Weight %:  25 (25,1)  .791023 -.08682 -.04619 100.041 .036205 100.736
Weight %:  26 (26,1)  .845943 -.03899 -.02848 99.5872 .045949 100.412
Weight %:  27 (27,1)  .357682 -.04655 -.01307 100.110 .010420 100.419
Weight %:  28 (28,1)  .384053 -.08231 -.04663 99.7039 .010831 99.9699
Weight %:  29 (29,1)  .375092 -.12850 -.00195 98.4028 .006886 98.6543
Weight %:  30 (30,1)  .384347 -.06711 .004524 99.4623 .017853 99.8019
Weight %:  31 (31,1)  .332556 -.11764 .005993 101.817 .007518 102.045
Weight %:  32 (32,1)  .509899 -.04511 -.03046 99.3339 .028529 99.7968

And here with the TDI image correction:
                       C       N      Mo      Fe      Si   Total
Weight %:  1 (1,1)  .110519 -.01585 -.06678 100.082 -.01152 100.098
Weight %:  2 (2,1)  .063757 -.02377 -.01238 100.486 -.01004 100.504
Weight %:  3 (3,1)  .049959 -.23617 -.04097 101.709 .005234 101.487
Weight %:  4 (4,1)  .100714 -.03186 -.02337 98.6615 -.01990 98.6870
Weight %:  5 (5,1)  .198686 -.12025 .000016 102.630 -.00862 102.700
Weight %:  6 (6,1)  .106266 .002536 -.00652 100.026 -.00306 100.125
Weight %:  7 (7,1)  .522448 .042382 -.01003 100.399 .000076 100.954
Weight %:  8 (8,1)  .518256 .018884 -.02240 100.441 .012291 100.968
Weight %:  9 (9,1)  .073143 .112474 -.06401 102.516 -.00340 102.634
Weight %:  10 (10,1)  .111063 -.01682 -.01427 96.6596 -.00719 96.7324
Weight %:  11 (11,1)  .024760 -.07442 .009346 98.7109 .005805 98.6763
Weight %:  12 (12,1)  .034188 -.01473 .045469 100.241 -.00225 100.304
Weight %:  13 (13,1)  .112153 -.05364 -.04499 101.245 .002164 101.261
Weight %:  14 (14,1)  .052089 -.04881 -.01312 99.5550 .000969 99.5462
Weight %:  15 (15,1)  .066157 -.01249 -.04216 100.298 -.01288 100.297
Weight %:  16 (16,1)  .448711 -.03055 -.07451 100.850 .021595 101.215
Weight %:  17 (17,1)  .611663 .004584 -.04216 101.064 .024894 101.663
Weight %:  18 (18,1)  .073242 .061129 .017657 101.921 -.00767 102.066
Weight %:  19 (19,1)  -.03482 -.08892 -.03202 101.861 .004212 101.710
Weight %:  20 (20,1)  -.00799 -.00954 -.05652 99.9741 -.00715 99.8929
Weight %:  21 (21,1)  .109334 .002265 .008306 100.201 -.00414 100.317
Weight %:  22 (22,1)  .066635 -.01768 .054906 100.131 .000971 100.236
Weight %:  23 (23,1)  .017554 -.06436 .123012 97.7513 -.00060 97.8269
Weight %:  24 (24,1)  .132921 -.17412 -.00153 98.8648 .007539 98.8296
Weight %:  25 (25,1)  .518753 -.03771 -.01474 100.421 .028878 100.916
Weight %:  26 (26,1)  .434910 -.05500 -.03045 97.2691 .028320 97.6469
Weight %:  27 (27,1)  .075951 -.12082 -.02824 99.2273 .008542 99.1628
Weight %:  28 (28,1)  .005009 .016857 -.04798 101.226 .003904 101.204
Weight %:  29 (29,1)  .041551 -.13717 -.03206 99.5807 -.00418 99.4488
Weight %:  30 (30,1)  -.01026 -.12391 .017750 100.399 -.00393 100.279
Weight %:  31 (31,1)  -.00543 -.09645 -.01502 101.243 .006624 101.133
Weight %:  32 (32,1)  .139376 -.01928 -.04601 99.3611 .008726 99.4439


Please note that the carbon column quant values now are around zero (with no blank correction), as measured on pure Fe metal, and note that this acquisition was performed on a oil diffusion pumped system...

DataType (32):    C Wt.%   N Wt.%   Mo Wt.%   Fe Wt.%   Si Wt.%
Average:          0.15     -0.04    -0.02     100.16       0.00
Std Devs:         0.18      0.07     0.04       1.39       0.01
Std Error:        0.03      0.01     0.01       0.25       0.00
Rel %:          121.48   -164.09  -248.82       1.39     579.67
Minimums:        -0.03     -0.24    -0.07      96.66      -0.02
Maximums:         0.61      0.11     0.12     102.63       0.03

The scanning TDI method is applied exactly the same as one would for the point TDI correction in PFE (all the TDI options operate as before), but the only extra step is that one must first convert the replicate maps acquired in Probe Image into "TDI" maps by using a menu in the CalcImage log window as seen here:



Next I'd like to try a replicate scan acquisition on a beam sensitive sample such as a alkali glass melt inclusion. 

I've attached the complete CalcImage project below as a ZIP file if any of you would like to play around with it.  This scanning TDI feature is now available in PFE v. 11.8.3.  Please feel free to let me know if you have any questions.

john

[John Donovan]

So in looking at this scanning TDI data on some of the other elements in this pure Fe std, I was surprised to see that silicon shows a somewhat similar behavior to carbon.  Here is the TDI plot for each of the 32 pixels for Si ka:



This is silicon intensity as a function of time for each of the 10 replicate scans...  Now what could be causing the Si to increase over time- we're using a hydro-carbon based diffusion pump oil so it can't be from the carbon deposition, right?    We probably polished the sample with colloidal silica it's true, but that would all have been cleaned off I think... but in any event, why would the Si intensity increase over time?

Just for your curiosity here is the quantified silicon concentrations (background and matrix corrected) and without and with the TDI correction plotted as a function of distance:



I'm stumped. Any of you have any hypotheses on what's causing the increase of silicon signal over time in these replicate scans?
john

[John Donovan]

I have, on occasion, been accused of "spoiling" our users.     But seriously, I don't think so because one of my internal criteria for judging whether a requested feature is worth implementing is simply: would I find the requested feature in question, useful and/or fun?   And this feature request is something my students and I would use in our own lab.

As you know there is an enormous number of x-ray map data types that can be output from the CalcImage quantitative mapping software.  e.g, elemental wt%, oxide wt.%, atomic %, formula basis, detection limits, analytical sensitivity, net intensities, bgd intensities, k-ratios, log wt.% and many, many more quantitative x-ray map data types.  A few examples are shown here in our latest brochure:

http://probesoftware.com/download/probesoftware%208-30-2016%20single%20pages_reduc.pdf

Anyway, at EMAS last month a bunch of us were brainstorming and Anette von der Handt asked (and was echoed by Paul Carpenter) if we could add a new menu to CalcImage, which would output all calculated data types (previously specified by the user), to the Surfer application for presentation quality output. So, one mouse click for everything output, instead of two mouses click for each data type...

This feature has now been implemented in the latest Probe for EPMA version, now available for download, as seen here:

[John Donovan]

As many of you know, Cameca instrument stages have a "Cartesian" orientation.   Because Golden Software's Surfer application was originally designed for GIS work, it always assumed a Cartesian coordinate system with the upper right being the X and Y maxima.   But as we know, JEOL, for some reason:

http://probesoftware.com/smf/index.php?topic=101.0

utilizes an "anti-Cartesian" stage orientation!  Originally Surfer did not handle this different stage orientation internally, and therefore I had to re-write all the JEOL stage coordinates "on the fly" to use inverted coordinates (by multiplying by -1) and then the quantitative plots would be oriented properly.  However, the slice, polygon and strip scripts still displayed the mirror image in their output.

A while ago, I asked Golden Software if they could add a reverse orientation flag to their scripting and eventually, starting in version 13 of Surfer, they added this capability.  So this weekend I finally got around to implementing this new flag for all scripts.  I think it is backwards compatible with Surfer versions prior to 13, but let me know.

Here are some JEOL CalcImage script quant output with the new reverse axes flags. First for the slice script output:



And here the polygon extraction script output:



And here the strip extraction script output:



Note that your existing default scripts will be updated automatically when you update PFE, but the "custom" scripts will not be automatically updated. But if you haven't manually edited your "custom" scripts, I've attached them below in a ZIP so you can extract them and overwrite your existing "custom" scripts in the ProgramData\Probe Software\Probe for EPMA folder.

If you have modified your "custom" scripts you will need to make the changes yourself manually by editing them.  The key change is the addition of these lines:

' If Surfer v. 13 or higher, check for JEOL axis invert
If Val(Left$(SurferApp.Version, 2)) >= Val("13") Then
If XInvert% <> 0 then SurferAxes.Item("Bottom Axis").Reverse = True
If YInvert% <> 0 then SurferAxes.Item("Left Axis").Reverse = True
End If

But there are some additional parameters being passed (the XInvert and YInvert variables), so check the custom examples attached below and contact us if you need any help.
john

Edit by John: Updated custom scripts in ZIP attached below, for v.15 Surfer color palette location changes 06/06/2019

[John Donovan]

We decided to create a new Surfer options dialog in CalcImage for specifying various Surfer output options such as plots per page, default vs. custom plot templates and other Surfer output parameters.

This change allows us to get rid of a large number of menus in the main CalcImage window for better efficiency. The new Surfer options looks like this:



Once that was done we realized that we could now implement a new menu as requested by Philipp Poeml for creating virtual standard intensities for quantification, just as we already have in Probe for EPMA. Here is the new virtual standard intensity menu:



This should be useful for mapping of nuclear materials and other elements for which we do not have readily available standards, e.g., argon... see this topic for more on using virtual standard intensities. This post shows Philipp's virtual standard calculation for Am Ma using Pu Ma and Cm Ma as calibration points:

http://probesoftware.com/smf/index.php?topic=179.msg6743#msg6743

[John Donovan]

We remapped some of the menus in CalcImage to make things easier for users.  Basically we moved the file conversion and help menus to the main CalcImage menu.  First here is the new Convert menu in CalcImage:



and here is the new Help menu in CalcImage:



I also updated the CalcImage Help file to include a detailed explanation of the .CIP file format.  Note that one can always get the help file by typing <ctrl> h from the main CalcImage window.

[John Donovan]

We fixed some minor issues in the strip and modal presentation output scripts. The latest version of Probe for EPMA will update your default scripts, but because the custom scripts are not automatically overwritten, if you haven't modified your custom output scripts you can grab a ZIP file of the updated custom scripts and manually overwrite the existing ones in your ProgramData\Probe Software\Probe for EPMA folder.  The updated custom script zip file is attached to this post:

http://probesoftware.com/smf/index.php?topic=41.msg6488#msg6488

If you have modified your custom strip output scripts you can just compare the default strip and custom strip output scripts to see what was changed.  Basically we fixed an issue with the increment value text output in the strip output scripts. A file compare of stripxy1.bas and stripxy1_Custom1.bas will reveal all. 

Basically these two lines were modified to add the InStr function:

      If InStr(XLabel$, "um") > 0  Then MicronUnits$ = Format$(Round(StripIncrement! ,0)) & "um"
      If InStr(XLabel$, "mm") > 0  Then MicronUnits$ = Format$(Round(1000 * StripIncrement! ,0)) & "um"

There are no custom modal output scripts so we just turned off "hill shading" if v13 or higher of Surfer in the default modalxy.bas script.