JEOL stage error -206, sulking stages, and a bowed surface?

[orlandin]

Hi all, has anyone ever encountered a PI error window stating "Probe returned JEOL error -206: stage floating point  Occurred during on-peak SampleGroup() processing"? This error occurs somewhat unpredictably when starting a new map just after the faraday cup is removed (which is charming, because if it happens at 1 am on the 3rd or 4th map of a series then the beam just sits on your sample at full power until someone shows up to click 'okay').

Something about changing pixel dimensions seems to resolve it, even when pixel dimensions are well below the 1024x1024 maximum that the 8200 allows. For instance, today (thanks for the fun fact about Henry Moseley, John!) I tried running a 400x500ish pixel map at 50 micron step, 4 ms dwell, and encountered this error. JEOL and I have previously speculated that maybe I'm running some maps too close to the 15 mm/s stage speed limit, so even though I was only asking it to go 12.5 mm/s I changed the dwell to 5, 10, and 20 ms. All of these dwell times produced this same error on starting the maps. However, when I changed my pixel size from 50 microns to 49 microns, the map started! Weird, but typical of my experience with this particular error so far. All did not turn out well, however...

It's unclear to me that this is necessarily related to this error, but that map only made it about 2/3rds of the way through. At that point, the stage apparently decided to hurl itself into the far front corner of the chamber, where it sits currently and beeps annoyedly at me if I ask it to move anywhere else. Peering at it through my little sample exchange porthole, everything with the sample (it was a billet centered on a universal mount) and stage looks perfectly fine. I've gotten this -206 error before and worked around it by futzing with the acquisition properties randomly, but this temper tantrum from the stage is totally new.

I've attached the map data that was collected prior to the stage wigging out in case that's helpful to anyone, and as an aside maybe someone can also explain to me what's up with the high-signal stripe - spectrometers 2 and 4 are 30-40 degrees from one another, but they show the same orientation of tapered stripe (but not the same widths - related to peak sharpness on the crystals?). So did he just manage to curve his surface along that weird diagonal somehow during polishing? The stage was set to a single value of Z the whole time (center of map).

Anyways, I've asked JEOL several times about this in the past few weeks and they seem unable to look up what this error means. They now have a fresh request to look into this, but I was curious if anyone on here has ever encountered something similar. I am guessing that the 'Occurred during on-peak SampleGroup() processing' part of the error might be PI language, and maybe someone here could gain some insight from that? Unfortunately I did not think to have a log file set up before this mapping session, but I sure do now.

Thank you in advance to everyone for taking the time to share your thoughts!

[Probeman]

Hi Phil,
Yes, I am almost positive that 4 ms per pixel dwell time is just too fast for the JEOL 8200 stage. Especially an old stage that might be starting to wear out.  The Cameca EPMA requires a minimum of 18 ms per pixel for stage maps!

I hope you're not planning on trying to quant these maps! 4 ms per pixel is just too short a dwell time. I usually use 200 to 1000 msec per pixel for quant work. Gotta have at least a few dozen photons to work with!   
john

[orlandin]

Hello... John! I hadn't actually thought through the counting statistics of this sort of map. I qualitatively compensated by running the map at 150 nA, but was planning on just looking at the analytical uncertainty maps to get a sense for whether or not it was even worth attempting at these speeds.

However! You inspired me to try harder, and so I have, a little, since it's Saturday night. Here are the .grd versions of the .prbimg files as seen through QGIS (another tip from Julien when our lab couldn't afford Surfer this year). I love working with the .grd files for finally being able to sidestep 8-bit color binning in my maps, but I'm actually not sure what the units are for a .prbimg file - cps? Net counts? If one of these pixels reports 20k, and that unit is cps, then with a speed of 4 ms (assuming that the stage actually ran at that speed) I guess the actual X-rays observed in that pixel is... 80? I guess I see your point, because a pixel value of 20k is sort of typical for the Al and Si maps. The P and Zr are dealing with far fewer X-rays than that, even. So, maybe enough to tell you that you're above background, and with the Ti map at least that there is some real intermediate value between rutile and feldspar.

[Probeman]

150 nA is perfect for trace elements. Even more depending on the beam sensitivity.  But definitely use a longer dwell time to avoid stage errors and get even better statistics.

Another short cut for trace elements is to utilize multiple WDS spectrometers for each trace element. Another option (which may not be possible), is to specify the matrix by difference (see the Formula By Difference checkbox in the Calculation Options dialog). The idea being that the matrix corrections are a minimal effect on the trace element concentrations, while the background correction is the major effect. However, if these phases are two very different average Z values, then of course MAN might not work for mapping. Depends on the specific phases in question.

For example, Mike Jercinovic, Julien Allaz and I found that one can simply measure U, Th, Pb and Y (for the interference correction) using WDS for monazite samples, and then simply specify CePO4 by difference as the matrix. Works great for monazite, but it depends on the specific matrices in question.

[orlandin]

Hi all, here is an update to this -206 error issue after spending all day with our amazing JEOL engineer Rayland. Long story short, the problem seems to be entirely with 2-point stage maps. We can run center-point stage maps no problem. Here is a log file for a failed 2-point map, a successful center-point map, and then a failed 2-point map made from the UL and LR corners of the successful center-point map using the same pixel dimensions and dwell. One of the things we were speculating about was that sometimes the stage coordinates sent to our 8200 by PI have an extra digit of precision - maybe that makes the probe reject the map? It does not seem like a more detailed explanation of what error -206 means will be forthcoming from JEOL, beyond what is displayed in the original message I attached.

On the plus side, the stage isn't sulking any more and I learned all about manual stage movements + full vents to stick your paws into the chamber. It's still pretty unclear what exactly happened to cause it to abandon the map to go run and hide. Rayland suggested that maybe the sample charged during mapping, resulting in a small discharge sending the stage into hiding. That would sort of make sense for failure part of the way through a map being run at high current on a sample in a universal holder that may not be well grounded... but wouldn't you see evidence for intensifying charging as the map progressed? I don't think I see anything in the maps that suggest a charge was building up on the sample. The sample was still totally secure when we retrieved it, and I had driven over all of the mapped positions when setting up the map so it isn't like the stage touched something.

[John Donovan]

Hi Phil,
I don't see anything in the log you sent except that it seems a few minutes after you start the scan your stage reports a floating point error. I also don't see how it can be too many digits of precision because these command are all sent using single precision floating point and 4 bytes is 4 bytes!

Did you try running the scan using longer pixel dwell times?
john

[orlandin]

Hi John! Yes, for the original project I tried changing the dwell times from 4 ms to 5, 10, and 20ms. All produced the exact same -206 error. This map wouldn't run until I changed the pixel dimensions from 50x50 to 49x49. For the most recent example maps in the log file, I would even drive around randomly and change the corner positions after getting a -206 error, always obeying the pixel and speed limits, but still get the same error on the 2-point maps. So if anything, it seems like the problem is worsening from 'some' 2-point maps, to 'most/all' 2-point maps.

[John Donovan]

I don't know what to say except that you've probably got a bad electronics somewhere. There are literally dozens of 8200/8500 instruments running maps, so I have to suspect it's a hardware issue of some kind. Good luck and do let us know if you learn anything else new.

I did find this in our source code but that is all I have on this stage error:

Private Const JEOL_ERROR_CODE_STAGE_FLOATING_ERROR& = 1206      ' Stage floating point error error

So you're doing maps with different Z positions at each corner?  I could see how that might cause the JEOL firmware to have problems depending on the details. Try running these 2 point maps but with the Z positions all the same. I'll bet you don't get any errors.
john

[orlandin]

Hi John! An update on this problem : switching to center-point stage maps seems to avoid this problem, even when setting a different Z value for all four corners.