JEOL stage shift issue

[Radek_MM]

Hi,

Maybe I can add some stage shifting issues from my experience here at the geological survey of Finland (mineralogical lab). I had issues on both instruments, our CAMECA SX100 and our new JEOL iHP200F:

1.CAMECA
After programming many spots and returning to the first one it was shiftet some tens of microns in x and y direction, but in the lower part of the holder in the opposite x direction. Long story short, after a few investigations I figured out the stage was "rotating" when moved. This is due to the worn out shuttle on which the sample holder is mounted. You can see the worn out groves where the "fork" of the rod is holding the shuttle when inserting into the sample chamber.

Solution: I replaced the shuttle with a less worn out one and reduced a bit the speed of the stage. No shift after that.

2. JEOL
The new iHP200F has a large shuttle, on which the sample holder is mounted. We use the split holder from Boerder and have our standards permanently inside the sample chamber. When moving in x direction, I got a shift in y direction always towards the gate. The longer the x distance traveled, the bigger the shift in y direction up to several 10s of microns. With the JEOL engineer we took a look at it and, long story short, two metal springs on the side of the stage (with the wheels at the end) are too soft for the massive shuttle, so the faster it moves, the more the whole shuttle "wobbles" off the stage towards the gate.

Solution: (Temporary) We stiffened the metal springs by glueing a small metal pin between the spring and the stage, thus making it stiffer. Long term solution would be to use either a thicker metal plate or a more stiffer material for this part. The JEOL engineer is in discussion with Japan about what to do. Since we were the "first" ones to report that, they are waiting to confirm from another instrument if this happens on any instrument or if it is only in our instrument the case.

In my experience if there is some shift in stage movement it is a mechanical issue and not a software issue (since, like you say John, software is often still the same as before the problem occurs). Maybe mapping the shift (like we did in our CAMECA, testing how the shift appeares throughout the whole movement range) might help to realize what the problem is.

Greetings from the cold North (Finland)!

Radek

[sem-geologist]

It is good You could fix your problem with shifting stage for Cameca. To add more, there are such metal pieces which holds the shuttle in place, they tend in long time to loosen up (bend back), thus unintended additional shuttle shifts due to stage movement can be also corrected by bending slightly those plates to hold the shuttle much more tightly.

I want also to point out that stage position reproducibility if checked on electronic image can be sometimes misleading. The "shift" can be introduced by shifting (unintended bending) beam (i.e. old contaminated aperture, where charging will bend the beam after setting new current) while stage would work absolutely perfectly. Thus stage reproducibility should be checked on optical image.

[Rom]

Dear colleagues, thanks you tried to help us.
It was not a PFE issue, it was 8200 stage controller issue. John had repeated this to us several times but our service was refusing to hear it.

The 8200 stage controller board has failed and is sending a motion complete flag immediately after the stage move command. PFE senses this motion complete flag (as it should) and stops the stage (as it should). The reason the problem does not appear in the JEOL software is because the JEOL software completely *ignores* this motion complete flag and instead simply waits for a fixed period of time.

The change John made to the PFE code for us is to ignore the motion complete flag for a fixed amount of time, just as the JEOL software does. The new parameter is in the Probewin.ini file and is called "JEOLMoveStageMilliSecDelayAfter".

Now we can work without being scared of losing part of our results because the system is measuring the composition in wrong positions. For our team it is the best event of this autumn - thank you, John.

[John Donovan]

Dear colleagues, thanks you tried to help us.
It was not a PFE issue, it was 8200 stage controller issue. John had repeated this to us several times but our service was refusing to hear it.

The 8200 stage controller board has failed and is sending a motion complete flag immediately after the stage move command. PFE senses this motion complete flag (as it should) and stops the stage (as it should). The reason the problem does not appear in the JEOL software is because the JEOL software completely *ignores* this motion complete flag and instead simply waits for a fixed period of time.

The change John made to the PFE code for us is to ignore the motion complete flag for a fixed amount of time, just as the JEOL software does. The new parameter is in the Probewin.ini file and is called "JEOLMoveStageMilliSecDelayAfter".

Now we can work without being scared of losing part of our results because the system is measuring the composition in wrong positions. For our team it is the best event of this autumn - thank you, John.

Hi Rom,
Thank-you for your report on this issue.  I'm glad we were able to deal with the situation and get your 8200 instrument back up and running reliably.

Just by coincidence, this comic was in our Sunday newspaper edition today:

[Rom]

Exactly right on target!

[dawncruth]

Hi all,
I'm having stage reproducibility issues. Is it possible to use Stage.exe to test reproducibility over time?

Dawn

[John Donovan]

Hi all,
I'm having stage reproducibility issues. Is it possible to use Stage.exe to test reproducibility over time?

You can, but it's basically a manual check with you sitting there.

See also this post and the option to write a reproducibility Excel test app using the Remote interface, similar to the spectrometer reproducibility test Excel macro:

https://smf.probesoftware.com/index.php?topic=435.msg2358#msg2358

The question is: one can use the x-rays counts to test spectrometer reproducibility, but what does one use to test stage reproducibility?

Perhaps the best idea is what you suggested to begin with. That is, use the Stage app to acquire images and then stack them in a GIF file to see how reproducible they are:

https://smf.probesoftware.com/index.php?topic=44.msg527#msg527

[dawncruth]

Hi all,
I'm having stage reproducibility issues. Is it possible to use Stage.exe to test reproducibility over time?

You can, but it's basically a manual check with you sitting there.

See also this post and the option to write a reproducibility Excel test app using the Remote interface, similar to the spectrometer reproducibility test Excel macro:

https://smf.probesoftware.com/index.php?topic=435.msg2358#msg2358

The question is: one can use the x-rays counts to test spectrometer reproducibility, but what does one use to test stage reproducibility?

Perhaps the best idea is what you suggested to begin with. That is, use the Stage app to acquire images and then stack them in a GIF file to see how reproducible they are:

https://smf.probesoftware.com/index.php?topic=44.msg527#msg527

I ran Stage with confirm points + acquire images 5x for five different positions. It would be great if we could add a feature to run the confirm points + acquire images for a specified number of times, or over a specified time period.

[JonF]

I ran Stage with confirm points + acquire images 5x for five different positions. It would be great if we could add a feature to run the confirm points + acquire images for a specified number of times, or over a specified time period.

You can already do this: I just had to do something similar to test out my stage.

In Stage.exe, open up the Automate! window (Window menu > Digitize Positions), click Digitize as if to create a new position, click on the Positions button to open up the Database Coordinates and Parameters window. From here, make sure Unknowns are selected (assuming you just want to replicate your unknown coordinates) and highlight your five coordinates and press Duplicate as Unknown. Do this a couple of times and you'll very quickly have hundreds of repetitions of the same five coordinates, in sequence.

[John Donovan]

I ran Stage with confirm points + acquire images 5x for five different positions. It would be great if we could add a feature to run the confirm points + acquire images for a specified number of times, or over a specified time period.

You can already do this: I just had to do something similar to test out my stage.

In Stage.exe, open up the Automate! window (Window menu > Digitize Positions), click Digitize as if to create a new position, click on the Positions button to open up the Database Coordinates and Parameters window. From here, make sure Unknowns are selected (assuming you just want to replicate your unknown coordinates) and highlight your five coordinates and press Duplicate as Unknown. Do this a couple of times and you'll very quickly have hundreds of repetitions of the same five coordinates, in sequence.

Jon is exactly correct.

Alternatively if you want to hop between two stage positions, for capturing an image at each stage position, make a Position A sample and a Position B sample and duplicate them when both are selected:



Or maybe 3 stage positions in triplets to stress both X and Y axes.

Note that in Probe for EPMA you can only capture a beam scan image at each position which might be enough, but you could also do something similar in Probe Image using stage scans which would be more demanding of your stage.

[dawncruth]

Here is a quick R script to automate the gif production. I made the following gif with this script. I will make one with the images taken with PfE and edit the post once collected. Make sure your images are .bmp for this script to work


install.packages("magick")
library(magick)

# Folder with bmp, put in your image directory on your computer, e.g. for me it was "C:/Users/druth/OneDrive - DOI/Desktop/2025Jan13_stage/Location2_longdist"
Loc2<- "Your image location"

# 2. List BMP files
bmp_files <- list.files(
  Loc2,
  pattern = "\\.bmp$",
  full.names = TRUE,
  ignore.case = TRUE
)

# 3. NUMERIC SORT (fixes frame order)
bmp_files <- bmp_files[order(
  as.numeric(gsub("\\D+", "", basename(bmp_files)))
)]

# 4. Read BMP images
images <- image_read(bmp_files)

# Optional: force same size
images <- image_scale(images, "800x800!")

# 5. Create animated GIF
gif <- image_animate(images, fps = 0.5, loop = 0)

# 6. Write GIF to disk, rename as needed
image_write(gif, "animated_output_loc2.gif")

[John Donovan]

Very cool.

Check out the images attached to this post:

https://smf.probesoftware.com/index.php?topic=44.msg527#msg527