Leginon

1) Are you using beam tilt or stage tilt method? If beam tilt method is being used, then it is critical to have a good value for eucentric focus stored to the database for the magnification you are using for Z focus. Usually, we do a manual alpha wobble to get Z to eucentric position, then do manual focus to get objective lens to eucentric focus, then store the value using the beam tilt calibration node. This could be done at a high magnifcation and then simply change mags to the lower mag where Z focus is performed and store the value again. This assumes that the scope is aligned such that we are still at eucentric focus when mag is lowered (parfocal).
Whether you are using beam tilt or stage tilt, the fact that the correlation peak shows up at 0,0 indicates that an identical signal is showing up in both of the two images being correlated. Possible reasons:

a) low signal to noise - try increasing dose (more exposure time or beam instensity)

b) dark/bright reference images are getting old, try acquiring new ones. Be sure to do both channels. Be certain this is done without the sample getting in the way. I have seen a corner of the image accidentally occluded by a grid bar or the edge of a hole during acquisition of the bright image. Then that defect shows up in every image you acquire and causes strong correlation peak at 0,0.

2) This will require some modification to the code. I will think about a solution

3) We have seen this bug before. It happens because the pre-exposure time is less than the time it takes for the screen to lower all the way. When the screen is instructed to go up before is is all the way down, it gets confused. The easiest solution is to make sure the pre-exposure time is greater than the time it takes to lower the screen. But to be sure it will not happen, we should probably add a minimum pre-exposure restriction to the interface. Until this is implemented, there is a quick fix you can make in pyScope to ensure that it will not get stuck, even if someone sets a low pre-exposure time. Edit tecnai.py to force a 2 second sleep time after the screen is lowered. Add this a the end of the setMainScreenPosition function:

  def setMainScreenPosition(self, mode):

if mode == 'up':

self.tecnai.Camera.MainScreen = win32com.client.constants.spUp

elif mode == 'down':

self.tecnai.Camera.MainScreen = win32com.client.constants.spDown

else:

raise ValueError

time.sleep(2)

Or you may be able to use something lower than 2 seconds, but I was being extra safe.

4) We could develop a procedure in Leginon to do such a calibration, but for now, this would have to be done manually and then hard coded into pyScope. You could determine the diameter of the circle on the main viewing screen for a particular mag, then do a beam shift and manually calculate the conversion factor from beam shift value read from the scope and actualy distance shifted. You could then modify tecnai.py. Multiply the scale factor in the setBeamShift function and divide it in the getBeamShift function.

5) This is a good question. Gatan and FEI may have specs on this, but it would be a good idea for someone to do a real test to see how short of an exposure can really be done. I can seen an experiment with a faraday cup stage attached to an oscilloscope, or something like that.

6) This a missing feature in the MSI applications. The Z focus node is not connected to the drift monitoring node. It can be added by editing the application before you start it. In Leginon, before starting the application, go to the menu Application->Edit. Then in the Application dialog, go to the menu Application->Load. Select MSI-Edge, or whatever app you want to edit and "load". Now you need to add two new event bindings. Right click on "Z Focus" and selct "bind event". The event type is "DriftMonitorRequestEvent" and the "to node" is "Drift Monitor". Now you need to bind an event in the opposite direction. Right click on Drift Monitor and bind the event "DriftMonitorResultEvent" to the "Z Focus" node. Now save the application, or "save as" and a new name if you want to make sure you keep the original. Then you can exit the application editor and start the application you just edited.

7) The logging features in Leginon are buggy, unfinished, and not recently tested. However, you can code in a quick hack to log into a file. In leginon/gui/wx/Logging.py, modify the function getNodeLogger as follows. I have commented my changes:

def getNodeLogger(node):

logger = logging.getLogger(node.name)

logger.propagate = False

### CHANGED THE FOLLOWING FROM INFO TO DEBUG

logger.setLevel(logging.DEBUG)

if hasattr(node, 'panel') and node.panel is not None:

logger.window = node.panel

handler = MessageLogHandler(logger.window)

handler.setFormatter(logging.Formatter())

logger.addHandler(handler)

### JUST ADDED THE FOLLOWING 4 LINES

logfile = open('test.log', 'a')

handler = logging.StreamHandler(logfile)

handler.setFormatter(logging.Formatter())

logger.addHandler(handler)

return logger

Actually, that could be a disaster due to the multithreading nature of Leginon. Each node will open that same file. It might be better to use the node name to open a unique log file for each node, for instance:

logfile = open(node.name+'.log', 'a')

It could be made more useful, but that is a start.

Thanks for the reply!

"pulokas" wrote:
6) This a missing feature in the MSI applications. The Z focus node is not connected to the drift monitoring node. It can be added by editing the application before you start it. In Leginon, before starting the application, go to the menu Application->Edit. Then in the Application dialog, go to the menu Application->Load. Select MSI-Edge, or whatever app you want to edit and "load". Now you need to add two new event bindings. Right click on "Z Focus" and selct "bind event". The event type is "DriftMonitorRequestEvent" and the "to node" is "Drift Monitor". Now you need to bind an event in the opposite direction. Right click on Drift Monitor and bind the event "DriftMonitorResultEvent" to the "Z Focus" node. Now save the application, or "save as" and a new name if you want to make sure you keep the original. Then you can exit the application editor and start the application you just edited.

I did this (and I also had to bind AcquisitionImagePublish event to node z focus in Drift Monitor). The problem is that the focus goes into an endless loop:

Received drift result status: drifted, final drift: 2.5e-10

(or a very similar value)

It repeats the focus sequence after this although I do not see why it should - I set the drift threshold to 3e-10. (the DriftMonitor stops correctly after it is below the threshold, but the acquisition state is set to repeat).

The endless loop that you are reporting indicates that there is not really a specimen drift, but rather another problem. Each time drift is measured, the preset is first sent to scope. This includes image shift, which in some cases takes a few seconds to reach a stable position. This is a problem that we need to study more and has some bad effects throughout Leginon. In the future, there will probably be a calibration procedure added to Leginon that measures this settling time, then introduces the required pause any time it is necessary. For now, there are scattered settings throughout Leginon where you manually enter a pause time. For the problem you are currently experiencing, there is a setting in Drift Monitor: "Wait at least ... seconds between images. More importantly here, it also means the pause time before the first image is acquired. This gives the image shift (from the preset change) some extra time to settle. The default may not be enough for some TEMs. One TEM that I just measured took the image shift 8 seconds to drop below 3e-10. Play around with that value to see if it helps. Also note: if this slow settling time is a problem here in the drift measurement, then it will probably also be present when you change presets to your final exposure preset. Be sure to enter a useful value of "Wait ... seconds" in the Exposure node. The pause configured in each acquisition node is applied after the preset change and immediately before the exposure is taken.

Another issue to consider is whether it is necessary for you to measure and/or correct for drift in the Z focus node. If you can ever get it to work at 4700x, then you definitely can disable this drift check. For the higher mag you are working with, your cross correlations can be inaccurate, so you do need to be aware of drift. If the problem really is the image shift settling time as I described above, then this is predictable and you just configure the pause time and skip the drift check. If there really is a prolonged specimen drift (such as happens with cryo specimen holders), then you should do a drift check.

Regarding why status = "repeat":
Note the distinction between the setting "Wait for drift...", which measures and waits for drift to stop, and the setting "Adjust target for..." which causes the current target to be adjusted for previously measured drifts. When "wait for drift" is enabled, and the drift measurement is finally complete, you see the message: "final drift: 2.5e-10". This does not show you all the details. If you look in Drift Monitor messages, you will see that the drift at least once was above your threshold of 3e-10. Although it is now below your threshold, we are very strict about recording that a significant drift was measured at one point. This is what leads to the target repeat status. If a significant drift is measured, then we no longer trust that we are actually on our target (could have drifted over an empty hole, or over a grid bar). The target is repeated to ensure that a valid focus measurement can be made. If the infinite loop discussed above can be fixed, then normally this repeat would only happen once. A "real" drift eventually stops and does not come back just because you change presets.