Beam Deflection Acquisition

[Dan R]

Hi,
I was hoping that someone can explain beam deflection mode during acquisition to me. I am imagining that I can take a BSE image at a relatively high mag, and then use beam deflection to analyze specific points within that field of view? Is this correct?
Is there a sequence of steps that will ensure this works correctly?
Thanks.
-Dan

[John Donovan]

Hi Dan,
Sorry no one was able to get back to you until now.

The answer is yes, absolutely. It's actually pretty sweet.

First, make a new position sample from the Digitize! window and click the Digitize Image button:



Then set the scan speed and acquire an analog signal (SE, BSE, etc) image of the area of interest and save it to the database (images are the only data that are not automatically saved to the PFE database!).  Now using the mouse just click on the pixels you want to acquire data from. The software will automatically record the stage positions to the position database (see the Automate! window).



Both random selected points and traverses can be digitized.



You can also digitize grids based on polygon areas as seen here:



Now, from the Automate! window simply select the position samples, and acquire using normal stage moves or, for high resolution features, one can instead select the Use Beam Deflection option in the Automate! window.

Attached is a screenshot of this digitizing technique used to acquire a traverse on minerals in Martian meteorite EETA00079. The acquired traverse points shown can be displayed right on the BSE image or not, along with analysis line labels, etc.

[Dan R]

Thanks for the detailed reply John. Do I have to explicitly click the 'beam deflection' button, or will the software be smart enough to realize that it doesn't need to move the stage when I click on points at high magnification?
-Dan

[John Donovan]

Hi Dan,
No, the software can't read your mind (if that's what you mean!) 

You need to select the samples you want to run, then select the Use Beam Deflection For Position option and finally select which types of samples (stds, unks, wavs) you want to apply the beam deflection to.

[John Donovan]

I should explain better!

There are two methods to using digital beam deflection in PFE for point acquisition.

1. Manual beam deflection. In this mode the user acquires an image in the Imaging window from the Acquire! window and then selects the Beam Deflection button as seen here and clicks a spot on the image to move the beam spot to that position as seen here:



This method assumes that the stage position is in the center of the acquired image.  When the point is manually acquired from the Acquire! window, the current beam deflection position is shown on the progress display as seen here:



Note that the stage position recorded for this analysis position is based on the beam calibration.

2. One may also run manually digitized points using automated beam deflection. In this method, the user generally utilizes the Digitize Image feature in the Digitize! window to specify analysis points using the mouse.  The stage positions recorded are again, based on the beam scan calibration as seen in the post above:

http://probesoftware.com/smf/index.php?topic=70.msg263#msg263

When the position samples containing digitized positions are acquired, the program automatically moves the stage to the digitized stage positions, but if the user clicked the Use Beam Deflection For Position checkbox, then the program will instead move to the image center of each position sample and then utilize beam deflection for the point acquisitions as seen here:

[Ben Buse]

Hi John,

I've been looking at using beam deflection to do quantified line scans across crystals 1um in size. Beam deflection is ideal because I want to position the line scan accurately. So I'm using digitize-digitize image-draw traverse on image-then from automate use beam deflection.

But there are two issues the stage does a backlash before starting the analysis which defeats the point of what I'm trying to do - can I stop this - I've suppress ROM based backlash but this is the spectrometers rather than the stage I guess.

Secondly would it be possible to disable Faraday cup measurement for this adds a large amount of time to the analysis. With it just measuring the cup at the beginning and end of the traverse.

Also because it sets the beam current before analysis - this also shifts the image.

I guess the easiest way would be to do it as a 1-d map in probe image and run it through ProbeImage. But you'd need to be able to do a 1-d beam map. Also surfer can't open 1-d grid files as it does contouring on them.

Thanks

Ben

[John Donovan]

I've been looking at using beam deflection to do quantified line scans across crystals 1um in size. Beam deflection is ideal because I want to position the line scan accurately. So I'm using digitize-digitize image-draw traverse on image-then from automate use beam deflection.

But there are two issues the stage does a backlash before starting the analysis which defeats the point of what I'm trying to do - can I stop this - I've suppress rom based backlash but this is the spectrometers rather than the stage I guess.

Hi Ben,
I have information on turning on/off the spectrometer backlash modes from JEOL, but nothing for the stage backlash, though with some experimentation it might be implemented.  Would you be willing to run some tests for us?   In the meantime the easiest thing might be to just turn off the automatic stage backlash using the JEOL PC software before your PFE run and then turn it back on again afterwards.

Secondly would it be possible to disable Faraday cup measurement for this adds a large amount of time to the analysis. With it just measuring the cup at the beginning and end of the traverse.  Also because it sets the beam current before analysis - this also shifts the image.

You can turn off beam current measurements and skip setting column conditions from the Acquisition Options dialog from Acquire!   There is no option for just measuring the beginning and end points for beam current.

I guess the easiest way would be to do it as a 1-d map in probe image and run it through ProbeImage. But you'd need to be able to do a 1-d beam map. Also surfer can't open 1-d grid files as it does contouring on them.

I would do it as a 1-d scan in Probe Image for sure.  I know Philippe Pinard did lots of very tiny carbide grains using Probe Image and CalcImage. There's no need to use Surfer, though it should be able to handle a 1-d array...

There another possibility which I've tested on the Cameca Sx100, but I'm not sure if anyone has tested on a JEOL instrument, and that is the new stage reproducibility command in Probe for EPMA in the Automate! window as described here:

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

If I were you I would first test it on a fluorescent material to check if it works as advertised.  On the Cameca one cannot test it by tweaking the stage a little because of an oddity with the Cameca instrument- the system tracks the beam if the stage is moved manually!  But it worked fine for normal stage reproducibility issues on the Cameca.
john

[Ben Buse]

Hi John,

Thanks that looks very promising. I need to give it a try. I hadn't noticed you could turn of beam measurement. I'd prefer to do it through PFE rather than putting it into calcimage.

One thing though is if you use 'do not set conditions during acquisition'. How do you set up the beam beforehand. For in doing a beam deflection traverse it needs to move the beam. Maybe I need to try stage reproduciblitiy instead.

Thanks

Ben

[John Donovan]

One thing though is if you use 'do not set conditions during acquisition'. How do you set up the beam beforehand. For in doing a beam deflection traverse it needs to move the beam. Maybe I need to try stage reproduciblitiy instead.

It will deflect the beam in the appropriate mode, just not set the keV, beam current, beam size...
john

[Ben Buse]

Hi John,

The other thing I realised is that it should not need jog turning off as the stage is not moved. Like when you run an acquisition from the Acquire! window. But I guess when using automate its always assuming the stage is moving. Would it be difficult and of interest to anyone else - if when beam deflection selected it checked if the stage was at the analysis coordinates before calling stage move?

Thanks

Ben

[Probeman]

The other thing I realised is that it should not need jog turning off as the stage is not moved. Like when you run an acquisition from the Acquire! window. But I guess when using automate its always assuming the stage is moving. Would it be difficult and of interest to anyone else - if when beam deflection selected it checked if the stage was at the analysis coordinates before calling stage move?

Hi Ben,
Interestingly I used to check to see if the current stage position was already close to the target position when I supported a number of old instrument interfaces using direct control of stepper and servo motors.  I never added such a test for the Cameca interface because the stage position is defined in integer microns and so if you move to a Cameca stage position, that is where you are, and so if you send a command to move to the same stage position, the instrument will simply ignore the command!

I realize that the JEOL is different because it returns fractional millimeters, but I guess I assumed there was something similar in the JEOL firmware (was there on the 8900/8200/8500?), that checked to see if the current stage position is "close enough".  However, I can see that it might initiate a stage jog even if it is close enough to the actual target position.

I also guess that you can turn off the firmware stage jog from the JEOL software?  Also since you mentioned acquisition from the Acquire! window, did you know that you can use the Imaging window in Probe for EPMA to manually deflect the beam position and acquire manual data from the Acquire! window on that deflected beam position?  Try it on a fluorescent sample and see for yourself.  Note that the deflected beam position is displayed in the Acquire window with a little circle and cross... this same beam deflection display is also utilized for automated beam deflection from the Automate! window.

Finally there is also a parameter in the MOTORS.DAT file called "backlash tolerance" which is used to decide if a software (not hardware) backlash is necessary based on the current and target position (and motion direction).  So this parameter could also be utilized for deciding if a stage move is necessary at all...

The "MotBacklashTolerances" are defined in fractional units where 0.002 is 0.2%.  For the software backlash feature the code compares the motion distance, to the backlash tolerance fraction of the total stage axis range, to avoid issues where the position is close to 0,0 (as can be the case for Cameca instruments!).

For example if "pos" is the stage position to move to, and "RealTimeMotorPositions" is the current stage position:

If Abs(pos! - RealTimeMotorPositions!(motor%)) < Abs(MotHiLimits!(motor%) - MotLoLimits!(motor%)) * MotBacklashTolerances!(motor%) Then

So I could implement a check like this for a normal stage move, but we need to think about this carefully.  Do we want this behavior for all stage moves, or just stage moves from the Automate! window?  For example, someone might be depending on the current behavior to be sure that a stage jog is *always* performed before each acquisition, even if it's in the same position. Or we could only perform this stage move check if we are using beam deflection from the Automate! window...

What do you (and everyone else) think about this?
john

[Ben Buse]

Hi John,

I just looked further into it

On the jeol its rounded to 4 decimal places e.g. 2.7085 mm and if you change it by 0.0001 it jogs (i.e. 100 nm).

By testing it in PFE using Move window - it seems to be all to do with rounding on the Y - which is expressed to 5 decimal places. So sometimes PFE and PI will jog it and sometimes it won't. Although to all purposes the stage is areadly in the correct position it is just the rounding which triggers jog. This is important for 10 um FOV beam map or beam line scan where the stage is already in the correct position.

I think therefore your suggestion of checking whether the stage is already in the correct possible before instructing the stage to move is a good idea

Thanks

Ben

[Probeman]

I think therefore your suggestion of checking whether the stage is already in the correct possible before instructing the stage to move is a good idea

You think therefore I am!   

Seriously, it might be better to add some new keywords to the Probewin.ini file such as:

MoveStageToleranceX
MoveStageToleranceY
MoveStageToleranceZ

So what units should these above keywords be in?  Fractional units?  Microns?  Nanometers?

Also please consider the following questions from my last post:

So I could implement a check like this for a normal stage move, but we need to think about this carefully.  Do we want this behavior for all stage moves, or just stage moves from the Automate! window?  For example, someone might be depending on the current behavior to be sure that a stage jog is *always* performed before each acquisition, even if it's in the same position. Or we could only perform this stage move check if we are using beam deflection from the Automate! window...

And welcome back to school (I assume)!
john

[John Donovan]

I think therefore your suggestion of checking whether the stage is already in the correct possible before instructing the stage to move is a good idea

Hi Ben,
The latest version of PFE (11.6.4) has new keywords in the Probewin.ini that you can use to define if a stage move should be initiated or not. See the [hardware] section:

MoveStageToleranceX="0.1"
MoveStageToleranceY="0.1"
MoveStageToleranceZ="0.1"

The default is 0.1 um difference before a move is attempted. You can edit these to whatever you require for your automation purposes.
john

[Ben Buse]

That's great, can't wait to give it a go!

Ben