Hi everyone,
may be somebody heard about uncontrolled stage position shift when next unknown or standard measurement starts.
For instance, I set table positions X,Y,Z = A,B,C. Sometimes, absolutely randomly my system use constant shift (mainly 0.5mm) X or Y or both of them in all points of unknown or standard. As result, measurements are in points X,Y,Z = A+0.5mm,B,C or A,B+0.5mm,C etc.
This shift happens randomly and only at the moment when system go to new group of point.
Is this problem source:
-soft Probe for EPMA
-soft Jeol
-softs connecting
-other
Thank you
I've heard of stage problems like this on JEOL instruments because they are not using linear encoders for positioning. Maybe hardware/electronics problem?
What does your JEOL service engineer think?
Service engineer gave us just a suggestion to disconnect the internet during the measurements. We done it. The likelihood of issue is decreased but problem is not disappeared.
This is an old JEOL 8200, yes? It is very likely the stage is quite worn and needs servicing.
Yes, this is an old JEOL 8200. But everyone who use it hasn't this issue because use it through JEOl soft. Just several persons who use Probe for EPMA met the shift problem. It is why I ask to your team.
It makes no sense that this would be a software issue, first because the code for the 8200/8500 hasn't changed in 10 years and also because any stage problems like this have always turned out to have problems in the hardware.
Let's take this discussion off-line and if we obtain a solution we can summarize it here once we learn something. I'll contact you by email.
With our JEOL 8200 we have had several isolated incidents with stage issues. Any behavior that appears and is variable in magnitude and direction is likely to be mechanical and/or electrical.
Because the Y-axis stage drive gets used extensively for stage mapping, there is more wear on the mechanism. You should check the following in general but especially the Y mechanism:
Wear or possible looseness of the feedthrough, gearing, and bearings for the stage.
Lubricant contamination or particles on any of the mechanism.
Because the stage uses LED encoders for stage movement, there can be problems from contamination on the LED sensor. There is a procedure for inspecting the signal from the LED system to ensure good signal to noise level, and monitoring of the system with drives to different positions in the stage range.
We use the JEOL stage and spectrometer jog settings so that the JEOL and PFE software can be run interchangeably. I have discovered that if the JEOL 8200 X and Y stage jog values are set to zero, then the JEOL stage mapping routine will acquire one mapping strip, then stop. So it is best to use the hardware jog settings for the JEOL and to not use software jogs in PFE.
Cheers,
Paul
Quote from: Paul Carpenter on September 01, 2021, 12:29:25 PM
With our JEOL 8200 we have had several isolated incidents with stage issues. Any behavior that appears and is variable in magnitude and direction is likely to be mechanical and/or electrical.
Because the Y-axis stage drive gets used extensively for stage mapping, there is more wear on the mechanism. You should check the following in general but especially the Y mechanism:
Wear or possible looseness of the feedthrough, gearing, and bearings for the stage.
Lubricant contamination or particles on any of the mechanism.
Because the stage uses LED encoders for stage movement, there can be problems from contamination on the LED sensor. There is a procedure for inspecting the signal from the LED system to ensure good signal to noise level, and monitoring of the system with drives to different positions in the stage range.
We use the JEOL stage and spectrometer jog settings so that the JEOL and PFE software can be run interchangeably. I have discovered that if the JEOL 8200 X and Y stage jog values are set to zero, then the JEOL stage mapping routine will acquire one mapping strip, then stop. So it is best to use the hardware jog settings for the JEOL and to not use software jogs in PFE.
Cheers,
Paul
A shift of 0.5 mm seems much too large to be caused by wear on the y-axis stage gear and/or bearing unless the wear is extreme. When I've seen this problem occur during X-ray mapping (and then had the gear replaced), it was essentially invisible if the pixel size was about 2 microns or greater. Since we haven't been on a service contract for years, I do much less X-ray mapping than I used to. This makes me sad :'(, but I know it is for the good of the instrument.
Wear on the y-axis stage gear should be easy to detect by collecting a stage scan BSE image using the X-ray mapping function in PC-EPMA on a material (such as brass with scratches in it) that has very fine linear features parallel to the x-axis. Smooth linear or curvilinear features will appear "jittery" on a ~1-micron scale if the gear is worn excessively (through "normal" use).
I've had reports of all sorts of different size shifts from worn out stages. Not Cameca stages though which use optical linear encoders. The most common stage error you see on Cameca stages is that it fails to "home" on a specified position when the friction adjustment is too loose, and then times out giving a "motion not completed" error.
Brian and Paul are correct that it's the JEOL Y stage axis that takes a beating because of mapping. See this topic which has some replicate stage scan images showing the sorts of reproducibility issues:
https://smf.probesoftware.com/index.php?topic=44.0
Be sure to log in to see the animated GIF attachments.
Quote from: John Donovan on September 02, 2021, 07:54:42 AM
I've had reports of all sorts of different size shifts from worn out stages. Not Cameca stages though which use optical linear encoders. The most common stage error you see on Cameca stages is that it fails to "home" on a specified position when the friction adjustment is too loose, and then times out giving a "motion not completed" error.
Brian and Paul are correct that it's the JEOL Y stage axis that takes a beating because of mapping. See this topic which has some replicate stage scan images showing the sorts of reproducibility issues:
https://smf.probesoftware.com/index.php?topic=44.0
Be sure to log in to see the animated GIF attachments.
Hi John,
But how much time have you actually spent using a JEOL microprobe? I get amazing stage reproducibility in a ten-year-old instrument that has no optical encoders. Furthermore, failure of an optical encoder within the Cameca stage assembly can thrust one into a world of misery (and this is from personal experience). Ask Edgar if you don't believe me -- he'll know what I'm talking about. A JEOL stage is pragmatically simple in design.
Brian
Quote from: Brian Joy on September 02, 2021, 12:55:30 PM
Quote from: John Donovan on September 02, 2021, 07:54:42 AM
I've had reports of all sorts of different size shifts from worn out stages. Not Cameca stages though which use optical linear encoders. The most common stage error you see on Cameca stages is that it fails to "home" on a specified position when the friction adjustment is too loose, and then times out giving a "motion not completed" error.
Brian and Paul are correct that it's the JEOL Y stage axis that takes a beating because of mapping. See this topic which has some replicate stage scan images showing the sorts of reproducibility issues:
https://smf.probesoftware.com/index.php?topic=44.0
Be sure to log in to see the animated GIF attachments.
Hi John,
But how much time have you actually spent using a JEOL microprobe? I get amazing stage reproducibility in a ten-year-old instrument that has no optical encoders. Furthermore, failure of an optical encoder within the Cameca stage assembly can thrust one into a world of misery (and this is from personal experience). Ask Edgar if you don't believe me -- he'll know what I'm talking about. A JEOL stage is pragmatically simple in design.
Brian
Hi Brian,
Yet you hesitate to run stage mapping... ???
About 80% of our customers are JEOL instrument users, so I am mainly speaking of experience in our working with them.
I'll just say this: the Cameca stage is reproducible to 1 um *without* a stage backlash operation being performed with every move.
Quote from: John Donovan on September 02, 2021, 01:55:06 PM
Quote from: Brian Joy on September 02, 2021, 12:55:30 PM
Quote from: John Donovan on September 02, 2021, 07:54:42 AM
I've had reports of all sorts of different size shifts from worn out stages. Not Cameca stages though which use optical linear encoders. The most common stage error you see on Cameca stages is that it fails to "home" on a specified position when the friction adjustment is too loose, and then times out giving a "motion not completed" error.
Brian and Paul are correct that it's the JEOL Y stage axis that takes a beating because of mapping. See this topic which has some replicate stage scan images showing the sorts of reproducibility issues:
https://smf.probesoftware.com/index.php?topic=44.0
Be sure to log in to see the animated GIF attachments.
Hi John,
But how much time have you actually spent using a JEOL microprobe? I get amazing stage reproducibility in a ten-year-old instrument that has no optical encoders. Furthermore, failure of an optical encoder within the Cameca stage assembly can thrust one into a world of misery (and this is from personal experience). Ask Edgar if you don't believe me -- he'll know what I'm talking about. A JEOL stage is pragmatically simple in design.
Brian
Hi Brian,
Yet you hesitate to run stage mapping... ???
About 80% of our customers are JEOL instrument users, so I am mainly speaking of experience in our working with them.
I'll just say this: the Cameca stage is reproducible to 1 um *without* a stage backlash operation being performed with every move.
Hi John,
That's a mischaracterization of what I wrote. I do plenty of X-ray mapping, I just don't do it excessively (as I might have been accused of doing in the past, just because I like pretty pictures). I have plenty of experience with both JEOL and Cameca stages, and I much prefer the former.
Brian
Would you like me to unleash "other Brian" upon you?? ;D
Greetings,
Thought I'd chime in with my experience with JEOL stage issues (8500F), though I'm not sure it's relevant to the OP's issue. Also, this happened ~1.5 years ago, so a little fuzzy on details.
I had intermittent reproducibility issues, with a somewhat "randomly occurring, but fixed magnitude" behavior. It was particularly weird, because it seemed to only occur in certain regions of the stage. We serviced the stage, and cleaned the mirrors, checked gears and bearings, etc without curing it.
We finally figured out it was an issue with the stage controller boards. I don't know the details or reason, but the fix involved an oscilloscope and lissajous figures. :o
Cheers,
Scott B.
Greetings,
Our service engineer checked, cleaned etc. our JEOL, including stage.
The shift problem was not disappeared.
Engineer Sergiy discussed this issue with JEOL USA colleagues, but they could not confirm that the similar problem is experienced by many other 8200 instruments.
I hope to link our JEOL engineer with entoptics (Scott B.)'s JEOL engineer (sent him a mail).
But may be somebody could recommend us some test for understanding the source our problem of huge scene shift which happens absolutely unpredictably.
Thank you!
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
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.
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.
Quote from: Rom on November 27, 2022, 07:43:50 PM
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:
(https://smf.probesoftware.com/gallery/1_27_11_22_9_32_09.png)
Exactly right on target!
:'(
Hi all,
I'm having stage reproducibility issues. Is it possible to use Stage.exe to test reproducibility over time?
Dawn
Quote from: dawncruth on December 01, 2025, 03:35:18 PMHi 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
Quote from: John Donovan on December 01, 2025, 06:39:49 PMQuote from: dawncruth on December 01, 2025, 03:35:18 PMHi 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.
Quote from: dawncruth on December 01, 2025, 03:35:18 PMI 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.
Quote from: JonF on December 04, 2025, 02:15:50 AMQuote from: dawncruth on December 01, 2025, 03:35:18 PMI 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:
(https://smf.probesoftware.com/gallery/1_04_12_25_8_03_13.png)
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.
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")
Very cool.
Check out the images attached to this post:
https://smf.probesoftware.com/index.php?topic=44.msg527#msg527