Project

General

Profile

Actions

Bug #1446

closed

navigator multiple move stuck

Added by Anchi Cheng about 13 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Leginon subsystem
Target version:
-
Start date:
09/02/2011
Due date:
% Done:

0%

Estimated time:
Affected Version:
Appion/Leginon 2.1.0
Show in known bugs:
No
Workaround:

Description

email from Nicolas Coudray on Sept 2,2011

As I told you, we had some issues of Leginon being stuck when we use the navigation node. I hope you can help us solving this issue...
Here is what's happening: The green arrow is turning (most of the time in the navigation node itself, sometimes in the Preset_Manager mode), but nothing's happening, nothing's moving any more. As you suggested, I send you in attachment screenshots of the last messages (there is no error or warning) which appear in the navigation node and in the acquisition node which calls this node. In the file, you'll see 2 examples of runs which were stuck, and also the screenshots of the settings used to use the navigation node (maybe I've made a mistake in setting it...). 
In the acquisition node, when I choose "preset manager" instead "navigator" for mover, we don't have any problem. So far, it has only stuck when I choose the navigator node. I should also say that it occurs (it seems) at random moments (the navigator seems to work properly for a few images, sometimes for a few grids, and then it suddenly remains stuck for one of them).
If you have any suggestions on why this is happening and how this could be solved, that would be great,


Files

Navigation_Logger_1.bmp (3.73 MB) Navigation_Logger_1.bmp Navigation logger panel, example 1 Nicolas Coudray, 10/13/2011 10:12 AM
Navigation_Logger_2.bmp (1.97 MB) Navigation_Logger_2.bmp Navigation logger panel, example 2 Nicolas Coudray, 10/13/2011 10:12 AM
Actions #1

Updated by Anchi Cheng about 13 years ago

e-mail from Nicolas on Oct. 12, 2011

I'm contacting you concerning the issue we had with Leginon being sometimes stuck in the navigation node. We did several tests and may have found the reason... It may come from the value chosen for "Acceptable distance" in the navigation settings. We lowered the value, and Leginon hasn't stuck yet since.
Do you think that this is indeed the cause? Can it be problematic for the navigator if the "Acceptable distance" set is too high?

Actions #2

Updated by Anchi Cheng about 13 years ago

  • Category set to Leginon subsystem
  • Status changed from New to Assigned

Hi, Nicolas,

Looking at the navigator.py code, I don't see why a change of "Acceptable distance" would solve your problem, nor where it might have gone wrong in the first place. If you are interested, I am looking at leginon/navigator.py line 344 or so:

344             if dist > accept_precision:
345               status = 'error'
346             else:
347               self._moveback()
348             break

Around those lines of code, a few things got logged in the logger panel. It may help to have a screenshot of the Navigation logger panel when this problem occurs, if you can get that to me. In addition, please give me the numbers you used for "Acceptable Distance" before and after the problem is apparently solved.

You can update this redmine issue as a form of communication. It will inform your and me by e-mail when there are new updates by either of us.

Updated by Nicolas Coudray about 13 years ago

Hi Anchi,

Thanks for the answer... Previously, for "Acceptable distance", we used 1e-03 (ok, it was high). Now, 5e-05.

I attached the Navigation logger panel for 2 examples of runs stuck in the navigation node. I forgot to mention that in the navigator settings window, I checked the "Final Image Shift" option. Since the last message on the logger is related to image shift, maybe that's where the problem came from: we asked to set an image shift value which was too big, didn't we?

Best,
Nciolas

Actions #4

Updated by Anchi Cheng about 13 years ago

  • Assignee changed from Anchi Cheng to Nicolas Coudray

Actually it is a bug on our end. Since JEOL scope does not have a usable "image shift" movement, it could not do it properly. I suspect that the times when it fails, it was out of the range of what JEOL is made to do. We will have to do something to detect that it need to switch to "beam-image shift" movement when it is a JEOL scope.

Does "Final Image Shift" option helps the targeting in general? We only have used it for tomography here at NRAMM.

Actions #5

Updated by Nicolas Coudray about 13 years ago

OK, thanks for the info.

From what I've seen, I think the "Final Image Shift" option generally helps:
We have an important jump between our medium magnification (x5k) and the next mag (x50k), and we need the targeting to be precise. We use the "stage position" movement and to have a precise targeting, we first tried to set the "Move to within" option to a low value, but it looks like "stage position" can rarely reach a good precision, or it takes several iterations and so the run lasts longer. So we lowered the "Move to within" option to about 3um and checked the "Final Image Shift" option; it looks like, in our case, this final Image Shift can compensate quite efficiently up to 3um.

Actions #6

Updated by Anchi Cheng about 13 years ago

Good to know. This does make the bug worth fixing. We will see if we can do some lower level debug (you may want to do the same from pyscope Jeol1230 side as well to find out what the amount of the image shift make it stuck and which part is not giving exception. By the way, please check the text terminal where leginon is launched to see if any exception message is output there.

Actions #7

Updated by Sargis Dallakyan almost 7 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF