Cameca stage

[Gseward]

John,

A follow up to our brief discussion on stage precision (and perhaps how it relates to doing stage coordinate to image position calibrations):

I quote from the Cameca SX100 product description 17th Jan 2008 version "A large travel (50mmx80mm) automated specimen stage featuring: -Micro stepping motors (minimum 0.1um)"  and "Closed loop optically encoded specimen positioning (+/_0.5um)"

On my instrument if I go to a relatively high mag (say 30um FOV) I can move the stage with the fine-adjust rollers (such that I see a shift in the electron image) without the stage coordinates updating (as observed in the roller window). Ergo, I conclude that this is consistent with positioning precision, as defined by the motors, better than 1um (probably 0.1um) but accuracy is only guaranteed at +/-0.5um because of the encoder limitations.

From my memory of my old SX50 that I was constantly fixing, the quadrature encoders have 4 bit-states per division on the encoder grating. I don't know what the grating spacing to um conversion is, but if we assume  1um,  it is likely that all 4 states need to change for an update of the position (in um) The changing of the bit states is how Cameca immediately knows if there is a stage movement problem - if the the encoder bits do not change in the correct order, an error has occurred.

But here is where the plot thickens: If I use peaksight to define a stage scan SE image with 0.2um spacing and uncheck the 'continuous' motion button, The image is acquired. Now I can't tell if x is moving in steps, and it may be continuous, but Y cannot be moving continuously. The Y stage position duly updates 1um every 5 lines in X, and the image, although a little distorted in Y, looks similar to the beamscan equivalent (see attached). Hence, it looks like Peaksight can move the motors in steps less than 1um. I speculate wildly that perhaps during ROM based mapping an absolute position is not being used? this would mean that the stage could be moved by one step of the motor, without any positional feedback required? or, the encoder has better than 1um precision?  Perhaps someone with more insight could clarify.

Anyway, not really of any consequence, except that this implies a stage map with 0.1um pixels is perfectly valid (for SE images at least), and very useful for stage/image calibration (assuming no distortions); if only the dwell could be less than 5ms!

Gareth

[Probeman]

But here is where the plot thickens: If I use peaksight to define a stage scan SE image with 0.2um spacing and uncheck the 'continuous' motion button, The image is acquired. Now I can't tell if x is moving in steps, and it may be continuous, but Y cannot be moving continuously. The Y stage position duly updates 1um every 5 lines in X, and the image, although a little distorted in Y, looks similar to the beamscan equivalent (see attached). Hence, it looks like Peaksight can move the motors in steps less than 1um. I speculate wildly that perhaps during ROM based mapping an absolute position is not being used? this would mean that the stage could be moved by one step of the motor, without any positional feedback required? or, the encoder has better than 1um precision?  Perhaps someone with more insight could clarify.

Hi Gareth,
The words in bold are what we need to test.  More specifically, how often does the X position get updated in non-continuous mode stage scanning. If one had a fluorescent sample, one could check if the motion is continuous.

My contention is that the glass linear quadrature encoders are limited to 1 um resolution in discrete stepping mode.  In continuous mode the firmware will interpolate...

[Gseward]

But like I say, Y CANNOT be moving continuously, can it?

I can look with a fluorescent sample, with a long dwell time, but less ambiguous would be to use an oscilloscope to look at the state of the encoder bits (this I used to do regularly on my SX50, but have thus far not needed to on my SX100). Or we could simply ask Cameca!

Gareth

edit: I realize a fluorescent sample won't work with a stage scan!

[Probeman]

but like I say, Y CANNOT be moving continuously, can it?

Exactly.  As you said, it only updated every 5 scan lines in Y, that is 1 um steps.

I can look with a fluorescent sample, with a long dwell time, but less ambiguous would be to use an oscilloscope to look at the state of the encoder bits (this I used to do regularly on my SX50, but have thus far not needed to on my SX100). Or we could simply ask Cameca!

I believe that Cameca has been asked, and 1 um is what I recall they state for discrete steps.  Only continuous mode can interpolate sub micron steps.

[Probeman]

But here is where the plot thickens: If I use peaksight to define a stage scan SE image with 0.2um spacing and uncheck the 'continuous' motion button, The image is acquired. Now I can't tell if x is moving in steps, and it may be continuous, but Y cannot be moving continuously. The Y stage position duly updates 1um every 5 lines in X, and the image, although a little distorted in Y, looks similar to the beamscan equivalent (see attached). Hence, it looks like Peaksight can move the motors in steps less than 1um. I speculate wildly that perhaps during ROM based mapping an absolute position is not being used? this would mean that the stage could be moved by one step of the motor, without any positional feedback required? or, the encoder has better than 1um precision?  Perhaps someone with more insight could clarify.

Hi Gareth,
The words in bold are what we need to test.  More specifically, how often does the X position get updated in non-continuous mode stage scanning. If one had a fluorescent sample, one could check if the motion is continuous.

My contention is that the glass linear quadrature encoders are limited to 1 um resolution in discrete stepping mode.  In continuous mode the firmware will interpolate...   I think we should move to 0.1 um encoders (using UV LED encoders?).
john

[Gseward]

but like I say, Y CANNOT be moving continuously, can it?

Exactly.  As you said, it only updated every 5 scan lines in Y, that is 1 um steps.

I can look with a fluorescent sample, with a long dwell time, but less ambiguous would be to use an oscilloscope to look at the state of the encoder bits (this I used to do regularly on my SX50, but have thus far not needed to on my SX100). Or we could simply ask Cameca!

I believe that Cameca has been asked, and 1 um is what I recall they state for discrete steps.  Only continuous mode can interpolate sub micron steps.

It only UPDATES the Y position (in um) every 5 lines in X, but Y is clearly moving in steps less than 1um, otherwise the image would be complete garbage. Unless Y is also continuous but the rotation that should be apparent in the image is too small to notice.

[Probeman]

but like I say, Y CANNOT be moving continuously, can it?

Exactly.  As you said, it only updated every 5 scan lines in Y, that is 1 um steps.

I can look with a fluorescent sample, with a long dwell time, but less ambiguous would be to use an oscilloscope to look at the state of the encoder bits (this I used to do regularly on my SX50, but have thus far not needed to on my SX100). Or we could simply ask Cameca!

I believe that Cameca has been asked, and 1 um is what I recall they state for discrete steps.  Only continuous mode can interpolate sub micron steps.

It only UPDATES the Y position (in um) every 5 lines in X, but Y is clearly moving in steps less than 1um, otherwise the image would be complete garbage. Unless Y is also continuous but the rotation that should be apparent in the image is too small to notice.

Interesting that we're seeing significant smearing effects in Y in the stage scan image you posted above, though not in the beam scan image.  Do you agree?   I think your scans make my point for me.

A test on a fluorescent sample would be most interesting...

[Gseward]

I'm inclined to agree in the sense that I always believed that 1um was the limit. I think it is most likely that Peaksight uses continuous motion, despite being told to do otherwise.

Interesting that using Interpretor(sic) 'stage rmove 1 0.1' will move the stage a fraction of a micron as will 'stage rmove 1 -0.1' however both move the stage in the same direction!

[Probeman]

Here is a stage cooling system we added to our Cameca SX100 stage.



We recently had to re-solder all the power resistors on the stage board as they had de-soldered themselves from running too hot for more than 10 years!

This row of fans just plugs into a power strip and works great, but does need to be unplugged when imaging at very high magnification.

If we were really smart we'd have a device that automatically reads the beam FOV and automatically turns it off when we image above 10x or so, and then turns it back on when below 10Kx (or so).   

[sem-geologist]

We recently were having problems with Z axis on our SX100... so while troubleshooting and fixing the problem I was forced to look much closer how SX100/SXFiveFE stage hardware works. There is not much advancement for the stage at SXFive iteration, however some failure sources were addressed in SXFiveFE design, albeith the major problem is left intact.

I quote from the Cameca SX100 product description 17th Jan 2008 version "A large travel (50mmx80mm) automated specimen stage featuring: -Micro stepping motors (minimum 0.1um)"  and "Closed loop optically encoded specimen positioning (+/_0.5um)"

bold emphases are mine.

But here is where the plot thickens: If I use peaksight to define a stage scan SE image with 0.2um spacing and uncheck the 'continuous' motion button, The image is acquired. Now I can't tell if x is moving in steps, and it may be continuous, but Y cannot be moving continuously. The Y stage position duly updates 1um every 5 lines in X, and the image, although a little distorted in Y, looks similar to the beamscan equivalent (see attached). Hence, it looks like Peaksight can move the motors in steps less than 1um. I speculate wildly that perhaps during ROM based mapping an absolute position is not being used? this would mean that the stage could be moved by one step of the motor, without any positional feedback required? or, the encoder has better than 1um precision?  Perhaps someone with more insight could clarify.

again, bold emphasis is mine. I don't get what the reason to believe that Y can't go in continuous mode. I also hardly understand what buzzword "continuous" really mean in Cameca vocabulary, and I think also that this buzzword has some imagined meaning by others. I think this wrong statement is due to missing the technical specifics of what  "Micro stepping motors" is and thus "continous" buzzword is understood in some wrong way. Also, the buzzword "Closed loop", without digging-into implementation details, actually tells not much. Capabilities and limitations of such "closed loop" system depends from implementation (maybe that is another source for intial belief Y can't go in continous mode, whatever it would means). On SX100 and SXFiveFE the feedback loop is closed at FPGA's (SX100, or single FPGA on SXFiveFE) on VME WDS electronic board - that "closed loop" means FPGA(s) starts the loop and loop is closed at them. FPGA's sets where motors should go in microsteps and do that in absolute micromanagement fashion. That is: FPGA calculates and sends the digital intensities for 2 motor windings (A and B), or in other words: projects discrete values with relation at finite time step from two A and B sinusoid waves (90 degree shifted). Micro stepping means that phases are not two square wave pulses with 90 degree shift (as commonly seen on stepper motors), but two sinusoid waves and micro steps traverse through those sinusoids in small incremental and detremental intensity steps keeping A and B at right intensity relation, where resolution of intensity at given time for those two waves has 7bit precision (actually it is 8 signed bits as 8th bit is for sign).

Feedback square wave signals (shifted by 90 degrees) from encoders are not directly fed back to microstepper drivers (as is quite common case with closed-loop stepper drivers), but they returns all the way to FPGA(s) (which are the real drivers with all logic implemented by Cameca FPGA programers).

   So a more precise description would be "Closed BIG loop through black-box". So I see no obstacle for Y to move "continuously" as it is just matter of counter in FPGA to check the encoder every nth microstep, or increment the A and B windings of Y motor every nth clock cycle. And so if it is implemented there it is implemented there. Althought as your observation correctly concludes, 0.1 um step for stage is completely legitimate for both axes.

Z axis is a bit different than X,Y, as there despite being powered with microstep motor it will go only in 1um steps no matter what. However, moving stage larger Z distances will create sinusoid waves and the stage will move kind of "continuous". That is obvious in particualrly when sending stage at speed 1 through command line interface (interpretor) of peaksight.

I guess that people think that stage is on constant motion at "continous" mode while acquisition of the mapping is running, which I think is not the case - at least there is no technical reason it simply would not move in microsteps and pause for pixel acquisition, and move to next microstep only after finishing pixel acquisition - in the end what other purpoise those interrupt signals for X and Y and Z would have?. At least It seem to me the most logical if I would do need to program such hardware in FPGA. The observed speed difference ("continuous" vs  not "continuous" set in GUI)  I think arise from jitter with encoders. With relying on microsteps (aka continous mode) the process is much more simple thus much faster: The next microstep intensities of A and B windings are calculated and sent to the DAC which drives the motor: FPGA sends intensity for A → pulls _write signal down → sends intensity for B → pulls _write signal down - and that's it! – motor moves that microstep. With not "continuous" mode (aka discrete) FPGA needs to send more sequences of microsteps and  wait some additional time due to jitter from encoders to make sure the motor moved correctly to the calculated position. The poor grounding strategy in ribbon cable just makes the jitter problem worse.[seems I was wrong, indeed at continuous mode stage travels in small steps in X direction during pixel acquisition]

    As for observing values not changing in the GUI - it wont show sub-micron position, as it use value calculated from counted encoder steps, and I believe properties of those fields are set to show integer values.

Here is a stage cooling system we added to our Cameca SX100 stage.



We recently had to re-solder all the power resistors on the stage board as they had de-soldered themselves from running too hot for more than 10 years!

This row of fans just plugs into a power strip and works great, but does need to be unplugged when imaging at very high magnification.

If we were really smart we'd have a device that automatically reads the beam FOV and automatically turns it off when we image above 10x or so, and then turns it back on when below 10Kx (or so).   

So as for our Z axis problem after few tests I found that stage electronics is overheating (our SX100 has 25 years). I could come to that as running probe with stage electronics cover removed - the stage would function properly and with cover-on Z would start miss the position or move to random position randomly by itself after few days (probably as stage electronics would reach some temperature). I repeated cover uncover test few days to confirm that.

Considerations of active cooling (the plan C)
I was considering to do similar mounting of cooling fans as shared in the photo by probeman. However I think it has some hazardous part: if those fans are powered from wall power, failure of powerstrip, or PSU supplying those fans, any of such unfortunate event would fry everything inside, as fans use the only venting holes. If I would take similar active cooling approach I would make additional 3 holes under "Cameca SX100" sticker for 3 silent and low vibration 40 mm fans, which would push external air inward at the bottom and force heated air out through vents at top. And then there is risk to replicate the vibration induced problem at high magnification. Thus I leave this kind of a fix as the last measure, or plan C.

Improving passive cooling (the plan A)
Looking to and comparing SXFiveFE with SX100 I found that Cameca engineers were aware of the overheating problem and decided to mild up overheating symptoms in a bit different way. A) Power resistors were moved from behind to upfront of the frontal hot board, and placed on turrets mounted on the OPAMP radiators (connections are made to back side of PCB though wires) B) Additional vent holes at the sides and enough space at the bottom of the cover, so that some air could freely enter from the bottom, collect the heat between the two boards, and escape sideways through the vent holes.
       I rather won't move power resistors, as my circuit simulation shows they are not heating so much. Also I am a bit suspecting if those additional wires is not making more bad than good (preventing air circulation).
The B part however seemed to me proper improvement. To assess in numbers, how much implementing passive cooling part would improve the situation, I placed the thermometer (1-wire interface Dallas the legendary DS18B20) near Z axis resistors with metal case on. It measured 40 degrees C after 1 hour before making any improvement.
       Then I cut out at the bottom of case excessive metal part (to make it similar as on SXFive model), and made some vent holes at the sides (it is not so beautiful as on SXFive, but functionally it works). The same thermometer at same position in half hour stopped rising at 34.5 degrees C (I had continued measurements up to full hour, but temperature stayed the same for the other half of hour). BTW, without mounted case at that same position near Z-axis resistors the thermometer was sensing ~28.5 degrees C.

Plan B - Stop the heat
I consider to pursue this despite if plan A will work or not (If there will be no more Z malfunctions in next few weeks), as I see at least few benefits of keeping things cooler: (1) lower energy bill – stage wastes about ~3kWh/day, and energy prices are more and more suffocating; (2) Reducing stage temperature from 40 C to 25 C could (probably a bit) improve situations with volatile escape during analysis. So instead of looking how to fight with symptoms I looked why it is heating. I found out that stage engines are powered at maximum power despite if it is moving or not! All axes are at full power, constantly. The proper solution would be to reduce power when stage is not moving, and that could had been implemented with no additional hardware in FPGAs, but it was not addressed with SXFive design and I think it wont be ever by Cameca. So the only way I see currently achievable for me is to make some small additional hardware which would intercept digital control signals at ribbon cable and would send reduced digital 7-bit values to stage power electronics if no stage movement on any axis is being detected. The full power also should be applied during sample exchange (tapping and using the signal of "the airlock-chamber door open" sensor would be sufficient). The digital communication in ribbon cable also produce enormous loops, as there is no return path for digital signals (digital ground present in ribbon cable is coupled (blocked) with capacitor at stage power PCB)! due to that EMI interference under the stage is absolutely enormous. The stage power electronics design and in particularly how communication is designed is treating electricity like hydraulics, ignoring part that there are electric fields – smells and dances like true beast straight from 70'ies. It probably was made like that to prevent ground loops, but actually it makes situation much worse - I don't blame Cameca here, it is simply relic from the past, everyone was teached and was making those kind of mistakes. I am looking forward if such intercepting device also would not improve that aspect as well, at least it could stop part of ribbon cable emitting and being susceptible to electromagnetic interference by closing and tightening the digital signal loops.

[sem-geologist]

I hanged the oscilloscope to see what are the differences between continuous-checked, and continuous-unchecked modes. By looking into that I also had found the answer why smallest dwell time is 5 ms.
Applicable to Hardware: old and new VME stage control boards for SX100 and SXFive.

• Axis X for stage mapping moves always in 0.1µm steps independently if continuous option is checked or unchecked. If it needs to go 0.2µm between pixels, it will make 2 steps, for 1µm it will make 10 steps, and for 2.0µm pixel it will make 20 steps (and so on).
  
  
  
  • Continuous mode will make those steps during pixel acquisition, the time between those microsteps will be total dwell time divided by number of steps needed. I.e. 1µm pixel size and 5ms dwell time result in 10 microsteps every 500µs during the acquisition; 1µm pixel size and 500ms pixel dwell time results in 10 microsteps separated with 50ms between... and so on.
  • not-continuous mode can be divided into 2 cases: pixel size <=1µm and pixel size >=1µm
    
    
    
    • when pixel size is below 1µm for every 0.1µm microstep 5ms will be appended. I.e. 0.5 µm pixel size will cause to do four 5ms-separated 0.1µm steps, and on 5 step the pixel acquisition would start. As 0.1µm is smallest step thus 5ms is the smallest dwell time. 1µm pixel will need 10 steps *5ms = 50ms
    • when pixel size is more than 1µm the time between 0.1µm microsteps starts to be shrunken so that total between pixel move time would fit into 50ms. Miraculously, there is no more obstacle to move stage faster.
• Axis Y before line of acquisition begins, moves to position in one go with 0.1µm precision (amount the pixel size is set); be it 0.8µm, be it 2µm, be it 0.1µm - it will move in one precise step and keep it there during whole acquisition of line independently if continuous option is checked or unchecked. I cant understand why X axis could not just go in single step like Y axis do.

I would not be surprised to find that for mapping mode encoders would be just simply ignored and not used at all and so would have absolutely nothing to do with continuous or not-continuous mode.

More findings:
X and Y motors are much more powerful, compared to Z motor. XY goes at slow mode up to 10V  (for Z its 5V). Also in some sense there is power reduction made already when stage motors needs less power. When moving faster the sinusoids grow out from -15V/+15V power rails and are capped at those - whole thing on oscilloscope then looks like square waves. The speed which still produce nice sinusoids is 4000. Speed 5000 already introduce some distortions. Thus indeed my initial circuit simulation was wrong, and resistors of X and Y could self-desolder as OPAMPs of X Y are producing much more heat there and resistors as well. The passive cooling I guess will prevent X and Z axis electronics from overheating, but I am worried plan A could be not enought for Y (situated in the middle).